fix(ci): grant actions: read so the security workflow can start

[WomB0ComB0]

What

This repo's security workflow has never run. Every invocation ends in startup_failure — GitHub rejects the run at creation, so no job starts and no logs are produced. That is why it was invisible in normal triage: startup_failure is not in the default status set most tooling scans for, and there is nothing to read even when you find it.

Root cause

security.yml is a thin caller for the org-wide reusable workflow resq-software/.github/.github/workflows/security-scan.yml. That workflow's CodeQL and SARIF-upload jobs declare actions: read.

An explicit permissions: block sets every unlisted scope to none. Since the caller listed only contents, security-events and pull-requests, the nested jobs requested a permission the caller did not grant — and GitHub refuses to create the run.

Evidence

The correlation across the org is exact, with no exceptions:

repo	actions: read	last security run
npm	✅	success
dotnet-sdk	✅	success
landing	✅	success
research	✅	success
programs	✅	success
crates	❌	startup_failure
dev	❌	startup_failure
docs	❌	startup_failure
viz	❌	startup_failure

Ruled out along the way: the pinned reusable-workflow SHA resolves and the file exists at it; the languages/submodules inputs are declared and correctly typed; the reusable workflow's own permissions block matches the caller's other three scopes; resq-software/.github is public, so repo access policy does not apply. Notably the working and broken repos pin the same SHA — so it is the caller, not the callee.

Fix

One line, plus the rationale comment copied verbatim from the repos that already had it — this was diagnosed once before and simply never propagated to the other four.

permissions:
  actions: read      # <- added
  contents: read
  security-events: write
  pull-requests: read

Read-only. Grants no write capability.

Verification

• actionlint clean
• YAML parses; permissions.actions == "read"
• The real check is this PR itself: security should now actually start and run instead of startup_failure

Companion PRs opened against crates, dev, docs and viz — all four carry the identical change.

Summary by CodeRabbit

• Chores
  • Updated security workflow permissions to support CodeQL and SARIF processing with read-only access.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[coderabbitai]

Warning

Review limit reached

@WomB0ComB0, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 56 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: a441123b-8489-49a5-9cf3-95f16d54d416

📥 Commits

Reviewing files that changed from the base of the PR and between f6bc3c3 and aefbca6.

📒 Files selected for processing (1)

• .github/workflows/security.yml

📝 Walkthrough

Walkthrough

The security workflow now grants actions: read in its explicit permissions block. Comments document the reusable workflow requirement and the read-only permission scope.

Changes

Security workflow permissions

Layer / File(s)	Summary
Configure read-only Actions permission .github/workflows/security.yml	The workflow adds actions: read and documents that unlisted permissions remain disabled and no write capability is granted.

Estimated code review effort: 1 (Trivial) | ~2 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: granting the security workflow the required read permission.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/security-workflow-actions-read

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[WomB0ComB0]

This repo needed a second change

actions: read alone was necessary but not sufficient here, and the first push to this branch still produced startup_failure.

dev was the only repo in the org pinned to security-scan.yml@94363a6a — an intermediate version whose vet job declared:

  vet:
    permissions:
      contents: read
      pull-requests: write   # inline PR comments on changed deps
      issues: write

A called workflow may not request scopes the caller has not granted, and that is validated when the run is created — a job-level if does not exempt it. So the run was rejected before any job started, even though vet would have been skipped.

The obvious fix would have been to grant those write scopes. That is the wrong move, and upstream already decided so. At .github@44987ffd the write perms were deliberately removed, with this note:

write perms (pull-requests/issues) are intentionally omitted. vet runs warn-only (continue-on-error) and reports to the step summary, so it doesn't need to comment/open issues — and keeping security-scan's footprint read-only is what lets required.yml call it cross-repo without forcing every consumer's gate to grant write scopes.

So instead of escalating this repo's permissions, this branch repins to 44987ffd. landing already pins that ref with only actions: read and its scan passes, which is the working reference.

Verified at 44987ffd before repinning: the languages and enable-semgrep inputs are declared, SEMGREP_APP_TOKEN and SNYK_TOKEN are declared, and no job requests anything beyond contents / security-events / pull-requests / actions.

Result: security on this branch is now completed success. No write scopes were added.

[github-actions]

Audit passed: The addition of actions: read permission is a necessary and safe fix for the security workflow to correctly initialize telemetry for CodeQL and SARIF-upload jobs within the reusable workflow. No security vulnerabilities, logic bugs, or performance issues were identified.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• localhost

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "localhost"

See Network Configuration for more information.

Generated by ai-auditor for issue #35 · ◷