The zizmor upload still skips a Dependabot head, on the ground #312 refuted for the other two uploads

[iderex]

Scope: .github/workflows

Split: none

#312 removed a Dependabot exclusion from two SARIF upload conditions on this board, on the reading that a Dependabot head runs with a token that can write security events. There are three uploads on this board, and the third still carries the exclusion on the ground the other two dropped.

What is wrong

The upload step of the workflow auditor skips a pull request Dependabot opened, by author name, and the comment beside it says such a run holds a read-only token:

git show origin/main:.github/workflows/zizmor.yml | grep -n "dependabot\[bot\]"
90:        if: (github.event_name == 'push' && github.ref == 'refs/heads/main') || (github.event.pull_request.head.repo.full_name == github.repository && github.event.pull_request.user.login != 'dependabot[bot]')

The evidence

Read on the head of #317, the newest proposal Dependabot opened here. The workflow ran on it, the job's own grant carried the write, and the upload step was the one step skipped:

gh run list --repo Flowfin/core --workflow zizmor.yml --commit 23ed4aedb072837a37386cae5eaad8d84040b5e7 --limit 3 --json databaseId,conclusion,event --jq '.[] | "\(.databaseId) \(.conclusion) \(.event)"'
34809323213 success pull_request

gh run view 34809323213 --repo Flowfin/core --log | grep -oE 'SecurityEvents: (write|read)|Contents: read|Metadata: read' | sort -u
Contents: read
Metadata: read
SecurityEvents: write

gh api repos/Flowfin/core/actions/runs/34809323213/jobs --jq '.jobs[] | .steps[] | "\(.name)\t\(.conclusion)"'
Set up job	success
Checkout Repository	success
Install uv	success
Audit workflows (SARIF for code scanning)	success
Upload SARIF	skipped
Fail on actionable findings	success
Post Install uv	success
Post Checkout Repository	success
Complete job	success

So the gate judged the head and the surface never received what it examined, which is the shape #312 corrected in .github/workflows/codeql.yml and .github/workflows/shell-analysis.yml. The comment of 2026-09-07 on #311 counted both uploads on this board; there are three, and this one was not in the count. I found it while comparing the check-runs of #317's head against a person's head for #108: the only name absent on the proposal is the code-scanning application's zizmor context, which exists only when this step runs.

Done when

• The upload condition in .github/workflows/zizmor.yml excludes a fork's pull request and nothing else, and the paragraph beside it carries the reading above rather than the sentence it refutes.
• The fork half stays a claim and the paragraph says so, as the two corrected files do.
• Whether the upload succeeds on a Dependabot head is not claimed by this issue; the next proposal Dependabot opens after the change lands is where that is read. In this file the upload runs BEFORE the gating step, so what bounds a failed upload is continue-on-error: true on the step and not the ordering the other two files rely on: a red upload cannot skip the verdict, and the change leaves that line alone.

THE LAST BULLET SAID THE GATING STEP RUNS AFTER THE UPLOAD IN THIS FILE, AND IT RUNS BEFORE IT. I found that by re-reading the step order while writing the change, minutes after opening this; .github/workflows/shell-analysis.yml already says the same of this file in the paragraph at its own upload step.