CI/CD Pipeline Hardening: Lessons from the Axios Compromise

In March 2026, compromised npm publishing credentials let an attacker ship malicious versions of axios — a package with 70–100M weekly downloads — for a three-hour window before detection. The root cause was not a zero-day. It was a CI/CD pipeline running on static credentials, no provenance, and no egress restriction. Every Zero Trust programme that treats the identity perimeter as “humans and workloads” and leaves the build system outside that perimeter is one credential away from being the next axios.

This is Phase 3, Chapter 2 of the 90-Day Zero Trust Playbook. Phase 3’s other chapter, Graduated Enforcement, hardens the runtime. This chapter hardens the path code takes to get to that runtime.

Key Takeaways

• The 2024–2026 supply-chain incident curve is exponential: Ultralytics PyPI (Dec 2024), reviewdog/tj-actions (early 2025), the 18-package npm compromise affecting 2.6B downloads (Sep 2025), Nx “s1ngularity” (Aug 2025), axios (Mar 2026), Trivy (Mar 2026)
• Only ~21% of organisations report full dependency visibility; 48% lag on SBOM generation; 60% admit skipping security scans to meet deadlines (CD Foundation 2024, OX Security)
• OIDC federation — replacing static cloud/npm credentials with short-lived workload identity tokens — is the single highest-leverage control. Typical migration: 6–12 weeks for a mid-size estate
• npm provenance passed 3,800+ projects and 500M+ downloads during beta — package consumers can now verify the exact repo, commit, and workflow that produced a release
• CI/CD ZTA maturity progresses Traditional → Initial → Advanced → Optimal across four control layers (identity, secrets, dependencies, egress). Most teams are stuck at Initial

Why CI/CD Is the Perimeter Now

CrowdStrike’s observation that 79% of attacks are now malware-free, relying on valid credentials, applies to machines as well as humans. Your build system holds production deploy keys, npm publishing tokens, cloud service credentials, and signing keys. If those are static, stored in environment variables, and shared across jobs, the build system is a higher-value target than any single workstation — and historically a softer one.

The axios case study is the reference incident for the cost of leaving it soft. The 2024–2026 timeline shows the trend is accelerating, not reverting.

The Four Controls

Hardening this isn’t a platform purchase. It is four distinct controls, applied in sequence.

Control 1 — OIDC Federation (Static Secret Elimination)

Replace every static secret used by CI with a short-lived OIDC-federated token. GitHub Actions, GitLab CI, Buildkite, and CircleCI all support OIDC federation to AWS, GCP, Azure, HashiCorp Vault, and (as of 2024) npm. The workflow exchanges an identity token, scoped to the repo and workflow, for a cloud credential valid for minutes.

The axios compromise would have been impossible under OIDC. A stolen static npm token had 30+ days of validity; a federated token has 15 minutes.

Migration reality: GitHub’s OIDC documentation lists the cloud-provider configuration as “minutes”; the org reality is 6–12 weeks for a mid-size estate because you have to find and replace every static credential, including ones nobody has touched in years.

Control 2 — Least-Privilege, Per-Job Secrets

Secrets that survive OIDC migration (third-party API keys, pre-federation integrations) live in the CI platform’s secret manager, scoped per-job — not per-repo, not per-org. The job that builds the container does not see the secret that publishes it. A compromised build step cannot escalate to a compromised publish step.

HashiCorp Vault, AWS Secrets Manager, or the native secret managers in GitHub/GitLab all support this. The architecture is not the problem; the policy is. Default postures are usually org-wide secrets because it’s easier to configure. Make the explicit decision: every secret scoped to one job.

Control 3 — Dependency Verification

Two layers:

• Lockfile discipline. package-lock.json, pnpm-lock.yaml, poetry.lock, Gemfile.lock, go.sum committed and enforced. No floating versions in production builds.
• Provenance. npm provenance (GA in 2023, 3,800+ projects and 500M+ downloads as of beta close) attaches a signed attestation to every release, tying it to a specific GitHub Actions workflow, repo, and commit. Consumers can verify the attestation before install. PyPI launched Trusted Publishing with the same model. Maven Central supports Sigstore-based signing.

For a dependency with provenance, a stolen publishing credential is no longer sufficient — the attacker would need to compromise the actual source repo and workflow. This is the single most effective supply-chain defence shipped in the last three years.

Control 4 — Egress Restriction on Build Jobs

Most CI jobs have unrestricted internet egress by default. They don’t need it. A hardened build job can reach: (1) your artifact registries, (2) the package registries it pulls from, (3) the cloud APIs it deploys to. Everything else — random endpoints the build might phone home to if compromised — should be blocked at the network layer.

GitHub Actions supports this via step-level network policies in self-hosted runners. GitLab Runners with Kubernetes executors inherit the cluster’s NetworkPolicy. Jenkins inside a segmented VPC with egress rules is the same pattern. This is the Chapter P6 micro-segmentation design applied to the build environment.

The Maturity Model

Use this to self-assess and to scope the work:

• Traditional — Static credentials in CI environment variables. No SBOM. Floating dependency versions. Unrestricted egress. This is where the axios victims were.
• Initial — Secrets in a manager (not env vars) but shared org-wide. Lockfiles committed. SBOM generated but not enforced at install. Some egress logging. Most teams live here.
• Advanced — OIDC federation for cloud and registry credentials. Per-job secret scoping. Provenance published on releases. Egress restricted on production-deploying jobs. This is the 90-day target.
• Optimal — OIDC everywhere. Zero long-lived credentials in the build system. Provenance verified on every install (not just published). Egress allow-listed per job. Signed, reproducible builds. Year-Two territory.

Most organisations move from Initial to Advanced in a single 90-day phase. Optimal is a 12–18 month programme.

The Cost Line That Blocks This

The state-of-practice numbers are sobering: only ~21% of organisations report full dependency visibility, 48% lag on SBOM, 60% admit skipping security scans to meet deadlines. The blocker is almost never tooling cost. The blockers are (1) the OIDC migration eating a quarter of engineering capacity, and (2) provenance being perceived as “for open-source maintainers, not us.”

Both are solvable. The OIDC migration ships faster than it looks because most repos converge on a small number of credential patterns — once the first three are migrated, the rest scale. Provenance is a single GitHub Actions step for npm/PyPI publishers and attaches to every release thereafter.

What You Hand to Year Two

By the end of this chapter, you should have:

• OIDC federation live for all cloud and registry credentials used by production-deploying workflows
• Per-job secret scoping for any secret that could not be federated
• Lockfiles enforced in CI; release publishing emits provenance where the ecosystem supports it (npm, PyPI, Maven)
• Egress restriction live on production-deploying jobs; logging on all other jobs
• A self-assessment against the four-level maturity model, reviewed at the steering committee, with a Year-Two plan to close remaining gaps

For the governance cadence that keeps this alive in Year Two, see Governance Structure. Return to the 90-Day Playbook hub for the cross-cutting operations chapters.