💡 Workflow Dependency Integrity Verification

[github-actions[bot]]

Summary

Extend the compliance audit to verify not just that Actions are SHA-pinned, but that each pinned SHA corresponds to the expected tag version. Introduce a workflow-deps.lock file that maps action@tag to verified SHAs, checked on every CI run, catching tag-mutation attacks that syntactic pinning alone misses.

Market Signal

GitHub's 2026 security roadmap includes a native dependency locking feature that will add a dependencies section to workflows, locking direct and transitive dependencies to SHAs with verification before job execution. This is not yet shipped and has no firm release date. Meanwhile, tag-mutation supply chain attacks continue — most recently demonstrated by incidents where trusted, widely-used actions were compromised via force-pushed tags, affecting thousands of downstream repositories.

User Signal

The org has multiple open compliance issues for unpinned actions (#106, #105, #104, #239). Merged PR #277 (secret-scan job + SHA pin) shows active SHA pinning work. But syntactic pinning (checking "does this line contain a SHA?") does not verify semantic integrity ("does this SHA match the tag we expect?"). A compromised upstream action with a force-pushed tag would pass the current compliance check because the captured SHA — even if it was captured at the moment of compromise — is syntactically valid.

Technical Opportunity

compliance-audit.sh already checks for SHA pinning across all org workflow files. Extending it to verify SHAs against a lockfile is a natural evolution:

1. generate-workflow-deps-lock.sh: New script that scans all *.yml in .github/workflows/, extracts uses: action@sha # tag references, resolves each action@tag to its expected SHA via the GitHub API, and writes a workflow-deps.lock JSON file
2. Lockfile verification: compliance-audit.sh gains a check that compares each workflow's pinned SHA against the lockfile, flagging mismatches
3. Dependabot integration: Dependabot SHA bumps automatically update the lockfile via a post-merge hook or CI step

The lockfile is intentionally simple (one JSON file, auto-generated) and will be trivially replaceable when GitHub ships native dependency locking.

Assessment

Dimension	Score	Rationale
Feasibility	high	Builds directly on existing compliance-audit.sh; ~50 lines of shell for the lockfile generator
Impact	med	Strengthens an existing security practice (SHA pinning) from syntactic to semantic verification
Urgency	high	GitHub's native solution is not shipped; every week without integrity verification is a window for supply chain attacks

Adversarial Review

Strongest objection: GitHub is building native dependency locking. Why build a bridge solution that will be superseded? And maintaining a lockfile adds friction to dependency updates.

Rebuttal: GitHub's dependency locking has no firm release date. The org runs 20+ workflows with 50+ action references — every week without integrity verification is a window for supply chain attacks. The lockfile approach is intentionally simple and auto-generated (no manual maintenance). Dependabot bumps would auto-update it. The cost of the bridge is approximately 50 lines of shell; the cost of a supply chain compromise is unbounded. When GitHub ships native locking, the bridge retires gracefully.

Suggested Next Step

Write generate-workflow-deps-lock.sh that resolves all action@tag references to SHAs via GitHub API, add a lockfile verification step to compliance-audit.sh, and document the process in ci-standards.md.