💡 GitHub Actions Allowlist Compliance Standard

[github-actions[bot]]

Summary

Define an org-wide standard for GitHub Actions action allowlisting — specifying which actions and reusable workflows are permitted — and add automated compliance checks to detect repos without allowlists enabled. Leverages GitHub's newly GA action allowlisting feature to create a preventive supply chain security layer that complements existing SHA pinning enforcement.

Market Signal

GitHub shipped action allowlisting GA across all plans in 2026, and their security roadmap explicitly targets "secure-by-default, verifiable automation." The Clinejection attack (February 2026) — the first confirmed real-world prompt injection → CI/CD → supply chain compromise — demonstrated how compromised or malicious actions can cascade through pipelines when unrestricted action usage is permitted. The attack chain exploited an AI agent's ability to run arbitrary actions, ultimately poisoning the npm publish pipeline. Action allowlisting is the industry's response to this class of threat.

User Signal

The org has extensive compliance audit infrastructure (dozens of closed compliance issues in the last 30 days), active SHA pinning checks (Issue #360 — Action SHA Pinning with 3 findings), and open Scorecard issues for Pinned-Dependencies (#316, 7/10) and Token-Permissions (#318, 7/10). Issue #35 (automate remediation of recurring compliance findings) and the existing compliance-audit-and-improvement.yml workflow provide the enforcement backbone. Action allowlisting is the natural next layer on top of SHA pinning — pinning ensures you get the exact version you intended, while allowlisting ensures only vetted actions can run at all.

Technical Opportunity

The existing compliance-audit-and-improvement.yml workflow already checks SHA pinning and repository settings via the GitHub API. Adding an allowlist check is a natural extension — a new check function that verifies the allowed_actions org/repo setting via gh api /repos/{owner}/{repo}/actions/permissions. The apply-repo-settings.sh script can be extended to configure allowlists programmatically. A canonical allowlist file (e.g., standards/actions-allowlist.json) would serve as the single source of truth, listing permitted action owners (e.g., actions/*, anthropics/*, github/*) and specific third-party actions with their pinned SHAs.

Assessment

Dimension	Score	Rationale
Feasibility	high	Leverages existing compliance infrastructure; GitHub API support is GA; implementation is a new check function + a JSON config file
Impact	high	Prevents an entire class of supply chain attacks org-wide; directly addresses Scorecard Pinned-Dependencies and Token-Permissions findings
Urgency	high	Clinejection proved the threat is real and actively exploited; GitHub shipped the mitigation feature; the org's compliance tooling can adopt it immediately

Adversarial Review

Strongest objection: An overly restrictive allowlist could block legitimate new actions and slow down developer velocity, creating friction every time someone wants to adopt a new GitHub Action or community tool.

Rebuttal: The standard should include a lightweight request process for adding new actions (e.g., a PR to the canonical standards/actions-allowlist.json reviewed by the dev-lead). This mirrors how the org already handles SHA pinning — actions are vetted once, then used freely. The compliance check flags repos with missing or disabled allowlists, not specific action choices within a properly configured allowlist. The allowlist itself should start permissive (all actions from trusted owners like actions/*, github/*, anthropics/*) and tighten over time based on actual usage patterns.

Suggested Next Step

Draft the allowlist policy section in ci-standards.md, define the canonical action allowlist for petry-projects in standards/actions-allowlist.json, and add a compliance check function to the audit workflow that verifies every repo has action allowlisting enabled and configured to reference the org-level list.