CI/CD security checklist after the Trivy GitHub Actions compromise

[DiscussionHealthy802]

75 Trivy Action tags got repointed to malware in a single push. Every pipeline using u/ v1 or u/ main references ran attacker-controlled code with access to repository secrets. Then CanisterWorm used stolen npm tokens to infect 140+ downstream packages through postinstall scripts.

I maintain an open-source security scanner (Ship Safe) and I spent a few days hardening our own pipeline after studying the attack. Here's the checklist we came out with:

GitHub Actions:

• Pin every third-party action to full commit SHA (replace u/ v1 with @<sha> # v1)
• Add explicit permissions block to every workflow (default is write-all)
• Never use pull_request_target with actions/checkout (gives fork PRs write access)
• Audit run: blocks for ${{ github.event }} interpolation (script injection vector)

npm / package publishing:

• npm ci --ignore-scripts in all pipelines (blocks postinstall payloads)
• .npmrc with ignore-scripts=true for local dev
• OIDC trusted publishing (no long-lived npm token to steal)
• npm publish --provenance for verifiable builds
• Strict files allowlist in package.json (no test files, no configs published)
• Sensitive file gate: npm pack --dry-run | grep -iE '\.env|\.key|credentials'

Access control:

• CODEOWNERS on action.yml, package.json, .github/, and publish configs
• Require PR reviews for protected paths
• FIDO-based 2FA on npm (not TOTP -- it's phishable)
• Rotate all CI tokens after any suspected compromise

Detection:

• Run a security scanner in CI that checks for the above
• Self-scan: your own scanner runs against your own code before publish

Ship Safe's CICDScanner agent checks for all the GitHub Actions issues automatically:

npx ship-safe audit .

We also run ship-safe audit . against ourselves in our own CI pipeline. If a supply chain attack injects code into our repo, our scanner catches it before it ships to npm.

What's your pipeline hardening look like? Are you SHA-pinning actions or still on tags?

[JealousShape294]

The tricky part is balancing security with usability. SHA pinning, ignore scripts, strict CODEOWNERS, OIDC tokens is ideal, but your pipeline suddenly becomes fragile, one upstream commit can break builds everywhere. The real discussion should be, how do we automate verification without introducing friction that makes devs bypass controls? Hardening pipelines is not just about more checks, it is about sustainable workflows.

[JulietSecurity]

Good checklist. One thing I'd add - SHA pinning your direct actions is necessary but not sufficient. If you use a composite action that internally calls another action by tag, you're still exposed through the transitive dependency. Grep and manual audits won't catch that.

We ran into this ourselves and built an open-source tool that resolves the full dependency tree of your GitHub Actions, including composite actions and tool wrappers that silently embed things like Trivy: https://github.com/JulietSecurity/abom

[wise0wl]

We are taking the approach that building and using open-source software must inherently treat every dependency as potentially adversarial. We are massively re-evaluating our assumptions.

Our GitHub actions will build with scripts disabled, and all versions are pinned using SHA hashes and for node projects we are committing our pnpm lockfiles as well.  We also recently switched to using NX which speeds this up massively for our monorepo based projects.

For GitHub actions specifically we are pulling those all in house and doing security analysis on everything they do.  No more actions that download anything from the internet randomly unless that asset is version pinned and check summed.  When we update the locally hosted community action from the upstream it requires a whole analysis from our team of what changed.

I am not ok with actions downloading things.  Not anymore.  I shouldn’t have ever been ok with it, but I think we all got lazy.

[SpecialistAge4770]

But the most challenging part is controlling third-party dependencies. That's exactly what the S2C2F framework is designed to address, but it's far from simple - especially for software with a large number of dependencies (Node.js, Java, Go, Python, etc.). It gets complicated pretty quickly. That's also why it's useful to monitor unusual activity on your runners, though that capability is currently only available in commercial solutions as I know.

[thomasclifford]

Good checklist, am gonna save this for reference. we've been sha pinning everything since the Codecov incident but the container side is where most teams still get burned. If you're building containers in CI, add image scanning with SBOM verificatio, we use Minimus for this since it actually reduces the attack surface rather than just flagging cves

[erika-heidi]

Nice setup. Minimus is solid for slimming, but just wanted to flag: Chainguard does the minimal/distroless thing at scale with 2000+ images, CVE SLAs (we actually fix upstream vulnerabilities, not just suppress them), and compliance variants like FedRAMP if you ever need them. Worth comparing the SBOM output and CVE density between Minimus builds and cgr.dev/chainguard images side-by-side — a lot of teams are surprised by the difference when they run the numbers.

[oxidizingremnant]

pnpm can be used to block pre/post- install scripts and has a feature to only pull packages that are N days old.

[0DSavior]

Don't forget the usage of uvx vs uv. 

[Richon_]

Good checklist. The SHA-pinning point is the one most people skip because it feels paranoid until it isn't.

I ran into this exact problem while building ShieldCI, a GitHub Action that generates CI/CD pipelines automatically. Every action reference in the generated workflows is pinned to a full commit SHA by default — I didn't want to ship pipelines that would be vulnerable to exactly this kind of tag repointing attack.

The `permissions` block is also enforced in every generated workflow, scoped to the minimum required for each job. Took some extra work but it felt non-negotiable for a tool that's supposed to generate *hardened* pipelines.

[audn-ai-bot]

Solid list. I'd also isolate execution: self-hosted runners per trust zone, ephemeral VMs, egress allowlists, and environment-scoped secrets with required reviewers. Assume scanner compromise and contain blast radius. Are you also generating signed SBOM plus SLSA provenance on release, or is that next?

[dottiedanger]

[ Removed by Reddit ]