ci: the weekly advisory scan could not report what it found (#782)

[raeq]

Closes #782. Refs #762.

The failure, from the run log

Run cargo audit
  ...
  No vulnerabilities were found
  ##[warning]2 warnings found!
  [@octokit/request] "POST https://api.github.com/repos/raeq/disarm/issues" is deprecated...
  ##[error]Resource not accessible by integration - https://docs.github.com/rest/issues/issues#create-an-issue

On schedule there is no pull request to annotate, so rustsec/audit-check reports by opening an issue. ci.yml grants contents: read, so that call is refused and the job fails — after a clean audit.

Why this is worth a gate, not just a line

The job passed every week it had nothing to say and failed every week it did.

$ gh run list --workflow ci.yml --event schedule --limit 8
2026-08-31 failure
2026-08-24 failure
...
2026-07-13 failure

Twelve consecutive red Mondays, each one a security report nobody received. And none of it shows on the pull_request path — the only path that gates a merge — so a workflow's non-PR triggers rot indefinitely with nothing going red anywhere anyone looks. That is the same shape as #832 (a push path broken for 13 straight runs while PRs stayed green).

For the record, the audit itself is fine: no vulnerabilities, two unmaintained informational warnings (bincode, proc-macro-error2, both transitive).

The fix

Job-scoped, so the write reaches this job alone:

    permissions:
      contents: read
      issues: write

contents: read is restated deliberately — job permissions replace the workflow's rather than adding to them, so omitting it would leave the job unable to check out.

The gate

Added to tests/test_workflow_baselines.py, which already exists for this class rather than a new file. It is anchored to the action (rustsec/audit-check), not to the job name, so renaming or moving the job keeps it covered — and a companion test fails if no scheduled issue-opening job is found at all, because a gate that silently matches nothing is how this kind of thing gets missed twice.

Mutation-checked — removing the permissions block fails it by name:

ci.yml: job 'cargo-audit' runs an issue-opening action on a schedule with no job-level permissions; it inherits the workflow's and cannot report

pytest 6,274 green.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The new gate has a robustness bug around non-mapping permissions, and the CI job permissions likely still don’t cover the check-run reporting path referenced by the closing issue (#782).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Fixes a long-running CI failure where the scheduled RustSec advisory scan could not publish findings because the workflow token lacked the permissions required to open issues, and adds a regression gate to prevent the same class of failure recurring.

Changes:

• Grant job-scoped issues: write to the cargo-audit job so rustsec/audit-check can open issues on scheduled runs.
• Add a workflow-baseline test gate that asserts scheduled issue-opening actions have appropriate job-level permissions.
• Document the failure mode and fix in the changelog.

File summaries

File	Description
tests/test_workflow_baselines.py	Adds a new regression gate for scheduled workflows using issue-opening actions.
CHANGELOG.md	Records the scheduled advisory-scan failure mode and the permissions-based fix.
.github/workflows/ci.yml	Adds job-level permissions to allow scheduled RustSec reporting via issue creation.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.