Block only the vulnerabilities a merge adds

Merged
JS
14h ago
+1012-82

cargo-audit ran inside the portable lane against the whole lockfile, so an advisory published against a crate main already used failed every open pull request until main was fixed, and nothing tracked the repair. A separate audit job now scans the tested merge and fails only on findings its base did not have; an unchanged lockfile gets an informational scan. Main still needs a clean full audit before build and release publish anything.

A daily workflow keeps one bot-authored tracking issue. It reopens the same issue when findings return, comments only when they change (and not twice after a failed update), and closes it after a clean scan, so subscribers hear about each change once. Only that trusted main job has issues: write.

Verified: scripts/test.sh portable and rust lanes pass locally (one CLI server startup test timed out under load and passes on rerun). tests/test_audit.py drives the tracking step under bash -euo pipefail against real jq and a gh stand-in that refuses --slurp with --jq the way gh does. scripts/audit.py was also run against the real cargo-audit 0.22.2 in diff mode, and its JSON schema was checked against a real report carrying RUSTSEC-2026-0385. actionlint is clean on both workflows. The browser lane timed out locally under heavy load and is left to CI.

Left out: the stale_base classifier in the codetrial-verify skill now only applies to runs from before this change; removing it belongs in a separate cleanup.

Summary by cubic

PR security checks now fail only when a tested merge adds vulnerable dependencies; advisories already present on its base no longer block unrelated pull requests. Main still requires a clean full audit before builds and releases can publish.

  • Pull requests with unchanged lockfiles get an informational scan; findings or incomplete scans block when dependencies change.
  • A daily main workflow updates one tracking issue, notifying subscribers only when the set of findings changes and counting only comments newer than the issue's last close, so a retry after a failed update does not notify twice; it closes or reopens the issue as findings are fixed or return.