Overview
Securing the GitHub Actions platform itself — not what workflows scan, but how workflows are written, permissioned, and governed. This is a distinct layer from the scanner workflows (#4–#24): those define what runs inside CI; this parent defines the security of the CI platform.
Source references: GitHub Docs — Secure use of GitHub Actions · Wiz GitHub Actions Security Guide · GitGuardian Cheat Sheet · StepSecurity Best Practices · GitHub 2026 Security Roadmap
Six pillars
| # |
Pillar |
Track |
Sub-issue |
| 1 |
Workflow authoring standards + actionlint/zizmor gate |
A — Applied to every workflow in this repo |
#25 |
| 2 |
Supply chain hardening — SHA pinning, allowlists, dependency locking |
B — Org/infra governance |
#26 |
| 3 |
OIDC federation and secret management |
B — Org/infra governance |
#27 |
| 4 |
Runner egress control and isolation |
B — Org/infra governance |
#28 |
| 5 |
Enterprise governance, rulesets, and observability |
B — Org/infra governance |
#29 |
Two tracks
Track A (#25) — standards applied directly to every workflow authored in this repo. #25 is a prerequisite for all other workflow implementation issues: every workflow merged here must pass actionlint and zizmor and comply with the authoring checklist.
Track B (#26–#29) — org-level and infrastructure controls that operate above the individual workflow. These require GitHub org admin access and, in some cases, AWS/GCP configuration changes.
How this relates to the scanner workflow issues
Scanner workflow issues (#4–#24) Platform security issues (#25–#29)
───────────────────────────────── ──────────────────────────────────
What the CI pipeline checks How the CI pipeline itself is secured
(secrets, deps, containers, SAST) (supply chain, tokens, egress, governance)
Both layers are required. A perfectly hardened workflow that runs an insecure scanner is still exposed; a perfectly scoped scanner that runs in an overpermissioned workflow is still a risk.
Partial coverage already in place
| Control |
Where |
| Short-lived tokens (no static PAT) |
#8 — Renovate GitHub App |
| Keyless OIDC signing |
#15 — cosign Sigstore |
persist-credentials: false pattern |
Referenced in workflow examples throughout #4–#24 |
Task list
Overview
Securing the GitHub Actions platform itself — not what workflows scan, but how workflows are written, permissioned, and governed. This is a distinct layer from the scanner workflows (#4–#24): those define what runs inside CI; this parent defines the security of the CI platform.
Six pillars
actionlint/zizmorgateTwo tracks
Track A (#25) — standards applied directly to every workflow authored in this repo. #25 is a prerequisite for all other workflow implementation issues: every workflow merged here must pass
actionlintandzizmorand comply with the authoring checklist.Track B (#26–#29) — org-level and infrastructure controls that operate above the individual workflow. These require GitHub org admin access and, in some cases, AWS/GCP configuration changes.
How this relates to the scanner workflow issues
Both layers are required. A perfectly hardened workflow that runs an insecure scanner is still exposed; a perfectly scoped scanner that runs in an overpermissioned workflow is still a risk.
Partial coverage already in place
persist-credentials: falsepatternTask list
actionlint/zizmorgate (prerequisite for all workflow PRs)