💡 GitHub Actions Workflow Lockfile Adoption Standard

[github-actions[bot]]

Summary

Define an org-wide standard for adopting GitHub Actions' upcoming workflow dependency locking feature (the new dependencies: YAML section). This standard specifies lockfile generation, review cadence, and CI enforcement so the org is ready to adopt on day one of public preview, replacing the current SHA-pinning-only approach with full transitive dependency integrity.

Market Signal

GitHub announced workflow dependency locking as the headline feature of its 2026 Actions security roadmap (March 2026). Public preview is expected within 3-6 months. The feature locks all direct AND transitive dependencies with commit SHAs plus cryptographic hash verification — addressing the gap where current SHA pinning only covers top-level references. This directly responds to the Clinejection supply chain attack pattern (February 2026) where a prompt injection in a GitHub issue title led to cache poisoning and credential exfiltration, and the Trivy tag-poisoning incident where 75 version tags were force-pushed to malicious commits.

User Signal

• The org already enforces SHA pinning via compliance-audit.sh — Action SHA Pinning findings are a recurring compliance category (closed issues Compliance Category: Action SHA Pinning (3 findings) #360, Compliance: unpinned-actions-dev-lead.yml #297, Compliance: unpinned-actions-dependabot-automerge.yml #239)
• Open Scorecard issues: Token-Permissions (Scorecard: Token-Permissions (7/10) #318, 7/10) and Pinned-Dependencies (Scorecard: Pinned-Dependencies (7/10) #316, 7/10) show pinning is still imperfect
• Existing 💡 Workflow Dependency Integrity Verification (💡 Workflow Dependency Integrity Verification #295) covers verification of current SHA pins but does NOT address the new lockfile feature
• 30 merged PRs in the last 30 days include 8 Dependabot action bumps, showing the ongoing maintenance burden of SHA-pin-only approach

Technical Opportunity

The org's Tier 1 centralized workflow architecture (stubs calling reusable workflows via @v1 tags) means lockfile adoption can be driven centrally. The compliance-audit.sh already has an action_sha_pinning check that can be extended to validate lockfile presence. Dependabot already manages action version bumps — lockfile updates integrate into the same PR flow. The new dependencies: section provides cryptographic hash verification beyond what SHA pinning alone offers, catching content tampering even when the commit SHA is correct.

Assessment

Dimension	Score	Rationale
Feasibility	med	Feature is not yet in public preview; standard can be drafted but enforcement must wait for GA
Impact	high	Eliminates the transitive dependency blind spot that current SHA pinning misses — directly addresses the attack vector behind Clinejection and Trivy incidents
Urgency	high	3-6 month preview window means the standard should be drafted now to enable Day 1 adoption

Adversarial Review

Strongest objection: The feature isn't in public preview yet — writing a standard now risks building against a moving target. The YAML syntax may change before GA.

Rebuttal: The org's strength is being ready before features land, not scrambling after. A draft standard with clear 'activate on preview' gates lets the team adopt Day 1. The 2026 security roadmap blog post is specific enough about the dependencies: syntax to build against. The compliance audit can flag lockfile-ready: false as a warning (not error) until GA. The org already has precedent for this with OIDC custom properties (drafted policy before GA).

Suggested Next Step

Draft a standards/workflow-lockfile-policy.md with: (1) lockfile generation requirements, (2) review cadence for lockfile updates, (3) CI enforcement timeline tied to public preview/GA milestones, (4) migration path from SHA-pin-only to lockfile.

---

Proposed by BMAD Analyst (Mary) — 2026-06-05T10:43:42Z