Workflow guide · Secure delivery

Turn SARIF deltas into a policy decision, not a vanity count

A useful release gate explains which findings are genuinely new, why the chosen risk budget applies, which suppressions remain visible, and what evidence another reviewer can replay.

Worked sample, not a live CI result.This guide uses synthetic SARIF. It does not scan code, query GitHub, upload a check, or approve a release.

Create a fresh release packet Open the paired benchmark Verify receipt + artifact bytes

1. Freeze comparable inputs

Export a baseline from the accepted release or default branch and a candidate from the exact revision under review. Record analyzer name/version, rule configuration, checkout revision, path root, and whether generated/vendor files were included. A delta is not trustworthy when the two scans cover different universes.

2. Treat identity as evidence

Use producer-declared stable fingerprints when available.
Keep rule ID, artifact URI, region, and message evidence alongside the identity.
If identity falls back to mutable location or message data, mark the match confidence and review bulk “fixed/new” churn.
Do not hide accepted suppressions; show who accepted them, why, scope, and expiry.

3. State the risk budget before seeing the answer

Example strict policy

Block on any new unsuppressed error. Review new warnings. This fits some high-assurance workflows but may be inappropriate elsewhere.

Example bounded policy

Block by severity, rule family, ownership, or an explicitly approved exception budget. Keep the budget in version control.

Do not tune thresholds after looking at a candidate merely to obtain PASS. If validation fails, required context is missing, or the comparison is not comparable, use INDETERMINATE.

4. Wrong approaches

Total count only: a flat count cannot separate inherited debt, fixed findings, and new risk.
Line number as identity: harmless code movement can turn one finding into a false fixed/new pair.
PASS equals secure: a policy result covers only supplied reports and scanner visibility.
Invisible waiver: excluding suppressions from the display destroys the audit trail.

5. Reproduce the worked sample

shasum -a 256 \
  app/fixtures/flagship-editorial-20260713/sarif/baseline.sarif \
  app/fixtures/flagship-editorial-20260713/sarif/candidate-block.sarif

baseline.sariffbc18d49e1f35752fce06eadeab57d7af9458db849f68a78a24bfb06f52c7c22

candidate-block.sarifb1c23c9d0b42814927795cb5e7c87c1d7a766c54cd31c00479441bf4c91bff09

The deterministic observation is one shared fingerprint and one candidate-only fingerprint. Under the stated zero-new-error fixture policy, that candidate is BLOCK. Run the workbench for the actual validated delta and receipt.

6. Roll out and retain evidence

Stage	Required evidence	Failure action
Pre-merge	Baseline/candidate hashes, analyzer context, policy revision, delta ledger	INDETERMINATE when comparison is invalid
Review	New/fixed/unchanged rows, suppressions, owner decision	BLOCK or documented exception
Merge	Exact commit, final verdict, artifact bundle and receipt	Stop if artifacts no longer match reviewed bytes
After release	Accepted baseline update and exception expiry follow-up	Reopen stale or expired exceptions

Method, limits, and privacy

Method: validate, fingerprint, classify delta, apply an explicit policy, retain artifacts. Limits: the tool does not scan code, resolve external property files, interact with CI, or prove security. Privacy: SARIF may expose paths, snippets, and vulnerability context; use approved, redacted, or synthetic reports on a trusted device.

Official sources

Correction channel

Send reproducibility, source, or workflow corrections to [email protected]. Include the page URL, exact issue, evidence, and proposed change. FastTool is the accountable publisher; material updates are recorded in the changelog. Reviewed 2026-07-13.