fix(GHA004,GHA006): establish need before reporting, and say what was accepted

[bgard68]

Follow-up to #73, in two parts: finish applying "establish need before reporting" to the rules that needed it, then make the result of that reasoning visible instead of silent.

Part 1 — two more rules named their own exception and ignored it

GHA004 — pull_request_target

Reported the trigger as Critical on its presence alone. But the trigger is not a defect: it exists so a workflow can label a fork's pull request or post a comment — work pull_request cannot do because it has no token worth using. What makes it dangerous is executing the contributor's code in that context, which GHA007 already reports precisely.

So the documented-correct pattern scored the same Critical as a live remote-execution path. A Critical nobody can act on is the one that teaches a reader to stop reading Criticals.

Workflow	Before	After
A job checks out the PR's head	Critical	Critical, unchanged
No job does	Critical	Low — "confirm this boundary"

The untrusted-checkout definition GHA007 carried privately moves into UntrustedPullRequestCheckout, so both rules answer from one list and cannot drift. GHA007's behaviour is unchanged.

GHA006 — persisted credentials

Told a job to remove the credential it pushes with. Its remediation already said "unless a later step needs to push with the job token" while nothing established whether one did, so a release job running git push had a finding it could not close. It now stays quiet when a script after the checkout, in the same job, pushes.

The signal is deliberately narrow, because wrongly suppressing this leaves a real credential exposure unreported. Only git push in script text counts — step names are not searched, since - name: Set up git push credentials would otherwise silence a real finding. A push in another job, or before the checkout, does not excuse it.

Part 2 — silence was the wrong answer

Establishing need removed findings and left nothing behind. A workflow reported clean gave no way to tell "the rule examined this grant and accepted it" from "the rule never looked".

Acknowledgements carry that reasoning without becoming findings, which matters concretely: the client reads any finding as Action required and counts it toward the risk level, so shipping these as findings would push a correct workflow into the state the check just cleared it of.

codeql.yml — Clean · 0 findings

  REVIEWED AND ACCEPTED
  ✓ security-events: write is required, not excessive   GHA002  Line 8
    'github/codeql-action/analyze' in job 'analyze' cannot work without it,
    and the grant is held to this job.

IWorkflowSecurityRule.Acknowledge is a defaulted interface member, so the seven rules that never suppress anything needed no change — and a test pins that their default stays empty.

Also audited, no change needed

GHA003 already worked this way: it skips reusable-workflow-call jobs that cannot carry timeout-minutes, and its comment notes the auto-fix would otherwise emit a broken patch. It was the model for both changes here.

GHA001, GHA005, GHA007, GHA008, GHA009, GHA011 have no equivalent "required" case — each reports something for which a safer alternative always exists.

Verification

314 backend tests and 28 frontend tests pass; both stacks build. Every case that goes quiet is paired with the neighbouring case that must still report, and the acknowledgement tests assert both directions — what is acknowledged is never also reported, and a file carrying one still reads as Clean with zero findings.

Neither this repository's workflows nor the repository that prompted the work change their findings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N7HjzX5e8Wv7PKENDo2Uj7