Software Supply Chain Security: A Risk-Based CI/CD Maturity Framework

In twelve days in March 2026, a single threat actor called TeamPCP cascaded through five major open-source projects — starting with the security scanners meant to protect them. Credentials stolen from Trivy’s CI/CD pipeline unlocked PyPI publishing tokens for LiteLLM. Those tokens unlocked the next target, and the next. Meanwhile, North Korean state actors backdoored Axios — 70 million weekly npm downloads — through a single compromised maintainer account. And across the IDE ecosystem, 72 malicious VS Code extensions with 9 million installs were quietly harvesting developer credentials before code ever reached a pipeline.

The software supply chain is no longer a peripheral concern. It is the primary attack surface.

This article presents a risk-based CI/CD security maturity framework — from foundational hygiene to full Zero-Trust attestation — grounded in the real incidents of 2024 through early 2026. Whether you are a CISO building a security roadmap or an engineering lead hardening your pipelines, the framework provides a clear, level-by-level path forward.

If you are looking for a hands-on companion to this framework, see our practical guide to container supply chain security with Sigstore, Cosign, and policy enforcement, which walks through a working implementation of artifact signing and verification.

Key Takeaways

Supply chain attack costs are projected to exceed $80.6 billion by 2026, and Gartner projected 45% of organisations would experience a supply chain attack by 2025.
Attackers now target the protectors first. Security scanners like Trivy and Checkmarx run with the broadest CI/CD permissions — making them high-value pivot points. The Trivy compromise cascaded into a confirmed breach of Cisco’s development environment.
Mutable git tags are a critical security boundary. Tag-repointing attacks silently redirect consumers to poisoned code without altering commit history.
The developer workstation is part of the supply chain. IDE extensions and editor plugins are executable supply chain components that must be governed.
Static credentials are the root cause of cascading breaches. Just-In-Time (JIT) ephemeral credentials (Level 3) prevent a single compromise from unlocking the next target.
EU CRA and NIS2 make this legally mandatory. SBOM enforcement, supplier risk management, and incident reporting are no longer optional for organisations operating in EU markets.
A four-level maturity framework — from baseline hygiene through Zero-Trust attestation — provides a structured roadmap aligned with SLSA and NIST SSDF.

The Escalating CI/CD Threat Landscape

Why Is the Software Supply Chain the Primary Attack Surface?

Adversaries have shifted focus from exploiting endpoint vulnerabilities to compromising the upstream processes that generate trusted software artifacts. A single compromise within a CI/CD pipeline yields code execution across potentially thousands of downstream systems — turning the producer’s trusted infrastructure into a distribution vector for malware.

The SolarWinds and 3CX attacks demonstrated this model. The incidents of 2024–2026 have industrialised it.

What Is the Financial Impact of Supply Chain Attacks?

The financial exposure is accelerating. Cybersecurity Ventures projects the cost of supply chain attacks to exceed $60 billion globally in 2025. A separate Juniper Research study estimates losses rising to over $80.6 billion by 2026 — a 76% increase over 2023 levels. Gartner projected that 45% of organisations would experience a software supply chain attack by 2025 — a three-fold increase from 2021. These metrics make CI/CD pipeline security a fiduciary responsibility, not just a technical one. Preventive measures alone are insufficient — organisations need resilience, rapid detection, and containment.

Signature Supply Chain Incidents: 2024–2026

XZ Utils: The Patient Backdoor (2024)

The XZ Utils backdoor (CVE-2024-3094) campaign demonstrated unprecedented stealth. An attacker operating under the pseudonym “Jia Tan” spent approximately two years building trust as a co-maintainer before embedding an encrypted backdoor into the widely used XZ compression library. The backdoor used glibc IFUNC tricks to hook into OpenSSH’s RSA authentication path, granting unrestricted remote access on affected systems. The backdoor was discovered by Microsoft engineer Andres Freund when he noticed SSH login latency anomalies. The incident confirmed that even foundational open-source components are targets for sophisticated geopolitical operations.

The aftermath revealed a persistent gap in artifact hygiene. Although stable versions were patched quickly, researchers later identified Debian Docker development images on Docker Hub still containing the compromised XZ Utils backdoor. This matters because latent threats in unmanaged registries can reinfect cleaned production systems. Effective security maturity requires continuous artifact integrity verification that extends beyond production into all development and staging registries.

Polyfill.io: Domain Hijack at Scale (2024)

The Polyfill.io CDN domain was acquired by a Chinese company (Funnull) in early 2024. The original creator Andrew Betts immediately warned the community to remove all references to the domain. By June 2024, Sansec confirmed that the script was actively injecting malicious code — redirecting mobile users to scam sites via a fake Google Analytics domain, stealing data, and potentially executing remote code. The attack also extended to related CDNs including BootCDN, Bootcss, and Staticfile, all traced to the same operator.

The industry response was alarmingly slow. Despite extensive notifications, Censys found that over 384,000 hosts were still embedding the malicious script as of July 2, 2024 — months after the compromise was public knowledge. Google responded by blocking ads for sites referencing polyfill.io, and Cloudflare deployed automatic URL rewriting to redirect references to a safe mirror. This gap between disclosure and remediation demonstrates a systemic inability to audit, track, and block compromised external assets. Effective mitigation requires continuous risk scoring for all suppliers and automated Policy-as-Code (PaC) enforcement that can instantly sever connections to compromised third-party resources.

Red Hat GitLab Breach: When the Environment Is the Target (Oct 2025)

The October 2025 breach targeting a Red Hat Consulting GitLab instance — attributed to the Crimson Collective extortion group — demonstrated the strategic value of compromising build and collaboration environments. Red Hat confirmed that attackers exfiltrated approximately 570 GB of compressed data from over 28,000 internal repositories (BleepingComputer, SecurityWeek, 404 Media), including CI secrets, configurations, and hundreds of Customer Engagement Reports (CERs) containing architecture diagrams, network maps, and authentication tokens. Downstream impacts were significant — Nissan confirmed 21,000 customers were affected through the breach. FINRA issued a cybersecurity alert urging financial services firms to assess their exposure.

The loss of customer infrastructure blueprints far exceeds the impact of stolen source code. This incident confirms that organisations must defend all CI/CD environments — including those for internal consulting or secondary projects — with Zero-Trust controls, microsegmentation, and Just-In-Time (JIT) access policies.

tj-actions/changed-files: The Proof of Concept (Mar 2025)

In March 2025, a supply chain attack targeting tj-actions/changed-files — a GitHub Action used by over 23,000 repositories — demonstrated the tag-repointing technique that would later be industrialised by TeamPCP. The attack chain exploited transitive trust: the attacker first compromised reviewdog/action-setup (CVE-2025-30154), which was a dependency of tj-actions/eslint-changed-files, which in turn was consumed by tj-actions/changed-files (CVE-2025-30066).

By retroactively modifying version tags to reference malicious commits, the attacker injected a base64-encoded payload that accessed Runner.Worker process memory, extracted CI/CD secrets, and printed them to build logs — exposing secrets in every public repository using the action.

Palo Alto Networks’ Unit 42 revealed that the campaign originally targeted Coinbase repositories before escalating into a broad, indiscriminate attack. This pattern — targeted intrusion followed by opportunistic mass exploitation — mirrors advanced persistent threat operations.

The attack was detected in real-time by StepSecurity’s Harden-Runner, an eBPF-based CI/CD security agent that flagged anomalous network egress. Without kernel-level visibility into runner network behavior, the secret exfiltration would have proceeded silently. CISA issued formal advisories for the CVEs, and the OpenSSF published maintainer guidance for hardening GitHub Actions pipelines. The tj-actions incident established the playbook — tag repointing, transitive dependency abuse, and secret harvesting — that TeamPCP would execute at industrial scale twelve months later.

TeamPCP: Five Attacks in Twelve Days (Mar 2026)

Between March 19 and March 31, 2026, TeamPCP (tracked by Google as UNC6780) executed a cascading campaign that compromised five major open-source projects in rapid succession, demonstrating a devastating paradigm: credentials harvested from one compromise fund the next. The campaign began by weaponising security tooling itself — tools that run with elevated CI/CD permissions — then used stolen credentials to pivot into higher-value targets across multiple package ecosystems (Unit 42 analysis, ReversingLabs, CrowdStrike).

Phase 1 — Trivy (March 19). TeamPCP exploited a misconfigured pull_request_target workflow in Aqua Security’s GitHub Actions to extract a privileged access token — the credential had survived an incomplete rotation on March 1. They force-pushed 76 of 77 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy, redirecting trusted references to malicious commits containing a multi-stage credential stealer. An infected Trivy binary (v0.69.4) was published to GitHub Releases and container registries (GitHub Advisory GHSA-69fq-xp46-6x23, The Hacker News, Microsoft Security Blog, Wiz). Because Trivy is the most widely adopted open-source vulnerability scanner in the cloud-native ecosystem, the credential stealer executed inside thousands of CI/CD pipelines with elevated permissions.

Phase 2 — Checkmarx (March 23). The same credential stealer pattern compromised Checkmarx’s AST GitHub Actions (The Hacker News, Sysdig, Kaspersky). The targeting of a second security vendor confirmed the strategy: compromise the protectors first, because security tools run with the broadest pipeline permissions.

Phase 3 — LiteLLM (March 24). Using CI/CD credentials harvested during the Trivy phase, TeamPCP published malicious versions of BerryAI’s LiteLLM AI proxy library to PyPI (versions 1.82.7 and 1.82.8). The LiteLLM maintainers confirmed they had been pinned to a compromised Trivy version, which exposed their PyPI publishing token (Sonatype, Datadog Security Labs, GitHub Issue #24518). The malware deployed a .pth file that executed on every Python process startup — no explicit import required — harvesting environment variables, SSH keys, cloud credentials, and Kubernetes configurations. The malicious packages were quarantined by PyPI within approximately three hours.

Phase 4 — Telnyx (March 27). The same cascading credential chain published malicious versions of the Telnyx Python SDK to PyPI (versions 4.87.1 and 4.87.2), extending the attack into the telecommunications API ecosystem (The Hacker News, JFrog, Akamai).

Phase 5 — Axios (March 31). While attributed to a separate actor (see the Axios section below), the Axios compromise occurred within the same twelve-day window, compounding the crisis of trust in open-source package registries.

The downstream fallout — Cisco (March 31). The TeamPCP campaign’s most significant real-world consequence emerged when Cisco disclosed that attackers had breached its internal development environment using credentials stolen via the compromised Trivy GitHub Action. The impact was severe: attackers cloned over 300 internal GitHub repositories containing source code for Cisco AI products (AI Assistant, AI Defense, and unreleased projects), as well as repositories belonging to corporate customers — including banks, BPOs, and US government agencies (SDxCentral, SC Media). Multiple AWS keys were stolen and used for unauthorised activities across Cisco AWS accounts. Dozens of developer and lab workstations were affected. Cisco isolated systems, reimaged compromised devices, and performed wide-scale credential rotation. Subsequently, the ShinyHunters extortion group posted a ransom demand with an April 3 deadline, claiming to also hold over 3 million Cisco Salesforce records. The Cisco breach transforms the TeamPCP campaign from an open-source supply chain incident into a confirmed enterprise compromise — the kind of cascading impact that makes supply chain security a board-level concern.

What does TeamPCP mean for your security posture? Three things:

Git tag integrity is a critical security boundary. Mutable tags let the attacker silently redirect consumers to poisoned code without modifying commit history. Enforce tag immutability and tag-signing verification as a deployment gate.
Security tooling needs the same Zero-Trust posture as production dependencies. Pin tools by digest, not mutable tags. Monitor scanner behavior with independent runtime controls like eBPF.
Scope CI/CD secrets per-job with ephemeral credentials. If a single compromise can cascade across ecosystems, your secrets are too broadly scoped. Google researchers warned that “hundreds of thousands of stolen secrets could potentially be circulating” as a result of the TeamPCP campaign (TechRadar).

Axios: State-Sponsored Dependency Hijack (Mar 2026)

On March 31, 2026, two backdoored versions of Axios — the JavaScript HTTP client with over 70 million weekly npm downloads — were published after a North Korean state actor compromised a primary maintainer’s npm account (Google Cloud Blog, The Hacker News). Within an approximately three-hour window (00:21–03:25 UTC), versions 1.14.1 and 0.30.4 were published with a single new dependency: plain-crypto-js, whose postinstall hook silently downloaded platform-specific remote access trojan (RAT) implants (Elastic Security Labs, Huntress, Snyk). Both malicious versions have since been removed from npm.

Microsoft Threat Intelligence attributed the attack to Sapphire Sleet, a North Korean state actor also tracked as CryptoCore/CageyChameleon. Google’s Threat Intelligence Group (GTIG) linked the infrastructure to UNC1069, a financially motivated North Korea-nexus actor active since at least 2018, based on an updated WAVESHAPER implant (Palo Alto Unit 42). The RAT supported macOS, Windows, and Linux — any CI/CD pipeline or developer environment that ran a fresh install during the exposure window could have been silently compromised. The Cyber Security Agency of Singapore issued a formal advisory in response.

The Axios incident exposes a risk that no amount of code review or SBOM analysis can catch: account takeover of a single maintainer publishing malicious code through the legitimate release channel. The earliest detectable signal was the unexpected appearance of plain-crypto-js in the dependency tree — making lockfile integrity checks the critical first line of defense.

GlassWorm: The IDE as Attack Surface (Oct 2025–Mar 2026)

The GlassWorm campaign targeted the developer environment itself — the IDE rather than the package registry or CI/CD pipeline. First discovered in October 2025 compromising 7 OpenVSX extensions, the campaign escalated dramatically in early 2026: by March 2026, at least 72 malicious Open VSX extensions had been discovered with over 9 million cumulative installs (Socket.dev, BleepingComputer, Dark Reading).

Threat actors published clean-looking extensions mimicking popular developer utilities — ESLint, Prettier, vscode-icons, WakaTime, and AI-powered coding assistants impersonating Claude Code and Codex. After passing marketplace review and accumulating user trust, the extensions were updated to abuse extensionPack and extensionDependencies to declare dependencies on separate extensions containing the GlassWorm loader. The VS Code extension model automatically installs referenced dependencies, pulling the malicious payload in without user interaction. The campaign also used stolen GitHub tokens to force-push malware into 151+ repositories in March 2026.

The loader used advanced evasion techniques: invisible Unicode characters to hide malicious code, runtime decryption, EtherHiding (Solana blockchain transactions as dead-drop C2 resolvers), and locale checks to avoid infecting Russian-locale systems (Snyk, Malwarebytes). Objectives included credential theft, SSH key exfiltration, cryptocurrency wallet draining, and conscripting developer endpoints as network proxies.

The takeaway: the developer workstation is part of the supply chain. Compromised developer environments leak credentials, signing keys, and repository access tokens before code ever reaches the pipeline. IDE extensions and editor plugins must be treated as executable supply chain components subject to allowlisting and integrity verification.

What Are the Core CI/CD Risks?

The incidents above map to six categories of risk that the maturity framework addresses:

Credential and secret leakage. Static, long-lived tokens consumed by CI agents remain the most exploitable threat. Even vaulted secrets are dangerous when they persist beyond their immediate use — stolen static credentials give attackers a persistent foothold.
Malicious dependencies. Beyond traditional dependency confusion and vulnerable open-source libraries, the risk now extends to AI/ML — poisoned datasets and backdoored models (like the 2025 NullifAI incident) introduce vectors for hidden backdoors and biased outputs.
Poisoned pipelines (configuration injection). Attackers modify pipeline definitions (YAML, build scripts) to execute arbitrary commands in the high-privilege build environment. Insecure defaults — broad agent scopes, no network microsegmentation — make this worse.
Artifact tampering. Unsigned or unverified build outputs can be swapped or modified post-build but pre-deployment. Without end-to-end provenance verification (e.g., SLSA attestation chains), backdoors slip through undetected.
Code and data exfiltration. In a compromised environment, malicious jobs siphon source code, configuration, customer data, and secrets. Network egress filtering and runtime monitoring are essential.
Insecure defaults and broad access. Overly permissive configurations — self-service runner provisioning, unchecked egress, inadequate IAM — enable rapid lateral movement after initial compromise.

The CI/CD Security Maturity Framework

What Are the Four Maturity Levels?

The framework integrates established standards from the NIST Secure Software Development Framework (SSDF) and the Supply-chain Levels for Software Artifacts (SLSA). Each level is additive — higher levels incorporate all controls from preceding levels.

Level 1 — Foundational Hygiene and Visibility. Baseline controls to eliminate easily exploitable vulnerabilities: mandatory MFA, basic RBAC, initial vulnerability scanning, protected branches.

Level 2 — Automated Prevention and Enforcement. Automated preventive controls: SBOM generation, initial code signing, approved action allowlists. Aligns with NIST SSDF initial requirements and provides the foundation for higher SLSA levels.

Level 3 — Assume Breach: Segmentation and JIT Access. An “assume breach” posture focused on reducing blast radius: Just-In-Time ephemeral credentials, immutable build agents, continuous telemetry, SBOM enforcement as a build gate.

Level 4 — Zero-Trust and End-to-End Attestation. Verifiable integrity across the entire supply chain: reproducible builds, multi-party code signing, pervasive Zero-Trust segmentation, automated incident response (MTTR < 1 hour). Satisfies the highest SLSA attestation requirements.

Maturity Framework Summary

Domain	Level 1 (Baseline)	Level 2 (Automated Prevention)	Level 3 (JIT / Segmented)	Level 4 (Zero-Trust / Attested)
Identity / Access	MFA required; Basic RBAC	Minimal long-lived tokens; Review over-privilege	JIT / time-bound access; Automated rotation	Continuous authentication; Zero-trust networking; Key rotation <24h
Build Configuration	Protected branches; PR checks	Approved action allowlist; Initial code signing	Immutable agents; Comprehensive logging (OpenSSF)	Reproducible builds; Full SLSA L4 attestation
Dependency Governance	Basic SCA scans; Trusted repos	Mandatory SBOM generation; Allow / Block-lists	SBOM enforcement (halt build if vulnerable); Vendor review	Continuous supplier risk scoring; AI/ML “AI-BOMs”
Secret Management	No secrets in code; Basic scanning	Central vault (KMS) integration; Automated CI scanning	Ephemeral secrets (per-job token exchange)	Zero static credentials; Rotate all keys / tokens daily
Monitoring / IR	Basic logging	Anomaly detection; EDR on build nodes	Telemetry into SIEM; Regular config auditing	Automated remediation; Live threat hunting (eBPF runtime)

Domain-by-Domain Implementation Roadmap

Identity and Access Management: From Vaults to Ephemeral Tokens

Effective secret management must evolve beyond storing secrets in a vault. Levels 1 and 2 require centralised vaults (cloud KMS, HashiCorp Vault) and scanning tools like Gitleaks to enforce zero secrets in code. Level 3 mandates eliminating static access privileges altogether.

What is Just-In-Time (JIT) access? JIT secrets delivery means credentials, tokens, or keys are available only at the precise moment of legitimate use, and access is revoked immediately upon job completion. This relies on ephemeral credentials — one-time-use tokens created dynamically for the duration of a specific build job and deprovisioned immediately afterward.

JIT delivery addresses the core limitation of static credentials: standing privilege. Even a securely vaulted secret is dangerous if a compromised CI agent can exploit it for lateral movement. JIT enforces Zero Standing Privilege — compromised servers or logs become valueless once the job finishes. This directly mitigates the credential leakage risk demonstrated by the Red Hat breach.

Level 4 requires continuous authentication based on real-time workload behavior and rotation of all non-machine-identity keys within a maximum 24-hour lifetime.

Build Configuration and Integrity

Level 2 enforces an approved allowlist of CI actions, plugins, and third-party tools, plus initial code-signing of commits or build recipes.

Level 3 mandates immutable build agents — containerised runners provisioned for a single job and destroyed immediately after use, preventing attackers from establishing persistence in the build environment.

Level 4 requires reproducible (deterministic) builds where identical inputs always yield identical outputs. This is the foundation for full SLSA build attestation, which verifies the complete provenance — origin, dependencies, and process — of every artifact, creating a non-forgeable, tamper-evident record that the final artifact matches the intended source code.

Dependency and Open-Source Governance

Level 2 requires mandatory SBOM generation for all builds, component allow/block-lists, and committed lockfiles.

Level 3 is the pivot from documentation to enforcement: SBOMs become a policy gate. Builds halt automatically if SBOMs are missing or if components with known high-risk vulnerabilities are detected. Level 3 also requires structured third-party vendor security reviews.

Level 4 institutionalises continuous risk scoring of all suppliers and components based on vulnerability, license, and provenance risk. It extends governance into AI/ML through AI-BOMs (ML-BOMs) for data and models, using formats like CycloneDX 1.5+. This aligns with the EU Cyber Resilience Act (CRA) and NIS2 Directive documentation requirements.

Monitoring, Telemetry, and Incident Response

Level 1 logging is reactive. Level 3 requires continuous telemetry ingested into a SIEM, anomaly detection (flagging new admin tokens, unusual IPs), and EDR on persistent build nodes.

Level 4 achieves runtime defense by deploying eBPF-based monitoring within ephemeral CI/CD runners. Tools like StepSecurity’s Harden-Runner provide kernel-level visibility and network egress filtering, restricting traffic to approved endpoints by default.

Why does this matter? Advanced attacks like XZ Utils operate stealthily within the execution environment. Traditional endpoint security may not function in ephemeral, containerised CI environments. eBPF transforms the passive build environment into an active defense surface, detecting and stopping malicious kernel-level behavior mid-build. Level 4 mandates continuous threat hunting and automated remediation playbooks to maintain MTTR below one hour.

Securing the AI/ML Supply Chain

What Are the New AI/ML Supply Chain Risks?

The integration of AI/ML models into commercial products introduces novel supply chain risks. ML models are not just data — they are executable artifacts.

The NullifAI incident (February 2025) confirmed this: attackers uploaded trojanised ML models to Hugging Face, leveraging a “broken pickle” serialisation trick to evade Hugging Face’s Picklescan security scanner. When developers loaded these models, a reverse shell was launched, compromising their systems. ML model files — PyTorch .pt files, serialised pickle formats — must be treated as potentially malicious executables.

These risks map to the OWASP GenAI Top 10:

LLM04 — Data and Model Poisoning: Manipulation of training, fine-tuning, or embedding data to introduce backdoors or biases.
LLM02 — Sensitive Information Disclosure: LLMs inadvertently leaking proprietary data from training sets or system prompts.

What AI/ML Controls Does the Framework Require?

Level 3 requires mandatory data provenance controls to track the source and transformations of all training data, plus bias, toxicity, and adversarial robustness checks on models prior to deployment.

Level 4 mandates:

AI-BOMs for all production models, detailing software dependencies, datasets, training configurations, and model lineage (CycloneDX 1.5+ supports the ML-BOM specification).
Advanced backdoor detection using techniques like Interpretable Deep Learning (IBD) or information theory, which have demonstrated significant detection accuracy improvements against compromised models under black-box conditions.

Governance and Compliance

EU Cyber Resilience Act (CRA): The SBOM as Law

The CRA was adopted in late 2024 and enters into force on a phased timeline, mandating “secure-by-design” practices and strict obligations for software providers (EU digital strategy overview). Full product compliance — including comprehensive SBOMs — is required by December 2027.

Levels 2–3 address CRA Article 10 requirements: mandatory SBOM generation and enforcement, meticulous component documentation, and proactive vulnerability management.
Level 4 ensures readiness for the phased deadlines: vulnerability and incident reporting obligations apply from September 2026, with full compliance by December 2027. The MTTR < 1 hour KPI aligns with mandated disclosure timelines.

EU NIS2 Directive: Supply Chain Risk Governance

NIS2 (intended for transposition by October 2024, with varying implementation across Member States) explicitly mandates supply chain risk management (EU digital strategy overview).

NIS2 Article 21 requires managing supply chain risks through contractual cybersecurity obligations for suppliers — directly supported by Level 3 vendor security reviews and Level 4 governance practices.
NIS2’s incident handling and reporting mandates are met by Level 4 automated IR, forensic readiness, and rapid reporting KPIs.

US Executive Order 14028 and NIST Alignment

The framework aligns with US EO 14028 (2021) and subsequent CISA and NIST guidance. SLSA’s four-level structure provides a prescriptive pathway to achieve the requirements of the NIST Secure Software Development Framework (SSDF).

How Do You Institutionalise Compliance?

Transform compliance from periodic assessments into continuous automated assurance:

Policy-as-Code enforcement. Encode policies (SBOM presence, branch protection, secret scanning thresholds) using tools like Open Policy Agent (OPA). Compliance gates are enforced automatically in the pipeline — consistently applied, auditable, and impossible to bypass manually.
The auditor’s evidence trail. Full SLSA provenance logs, CI telemetry, and ML-BOMs provide verifiable evidence of secure development practices. This shifts audits from manual document review to real-time confirmation.

Technical Controls Reference

Source Repository Hardening

Signed commits. Require cryptographic signing of all commits for non-repudiation and to prevent unauthorised code injection (Level 2).
Branch protection and RBAC. No direct push to main, mandatory review, strict RBAC with MFA for all repository access.
Action allowlisting. Restrict CI/CD actions and plugins to an approved allowlist.

Secret Management and JIT Implementation

Central vault usage. Mandate centralised vaults or KMS (HashiCorp Vault, AWS Secrets Manager) for all non-development secrets (Level 2).
Ephemeral credential architecture. Token exchange where CI/CD agents authenticate with non-sensitive machine identity and receive short-lived session tokens for specific operations (Level 3).
Rotation policy. Automatic credential rotation for all static keys and tokens with a maximum 24-hour lifetime (Level 4).

Least-Privilege CI Runners and Network Segmentation

Ephemeral agents. Containerised build agents destroyed after a single execution to prevent attacker persistence (Level 3).
Network microsegmentation and egress filtering. Restrict outbound traffic to approved endpoints (package registries, vault servers). Disable default internet egress.
Runtime monitoring (eBPF). Kernel-level EDR on CI infrastructure using eBPF to detect unauthorised activities, unusual process execution, and host tampering (Level 4).

Artifact Integrity and Provenance

Code and artifact signing. Cryptographically sign all binaries, containers, and deployment manifests with trusted build system keys (Level 2/3).
Attestation chains. Full attestation using frameworks like in-toto to document the execution environment, dependencies, and build parameters (Level 3).
SLSA L4 requirements. Reproducible builds and immutable registries that reject unsigned or non-attested artifacts (Level 4).

AI/ML Specific Controls

Model scanning. Static and dynamic analysis of imported ML models for known malicious patterns (Level 3). See Hugging Face Picklescan for baseline scanning capabilities.
ML-BOM generation. Automatically generate ML-BOMs using CycloneDX, documenting training data provenance, model architecture, and hyper-parameters (Level 4).
Advanced backdoor detection. Multivariate-interaction-based or interpretable deep learning techniques for detecting backdoors in black-box models before deployment (Level 4).

Incident Preparedness and Forensic Readiness

CI/CD-specific IR plan. Maintain a distinct incident response plan tailored to pipeline compromises (Level 3).
Forensic retention. Tamper-evident logs of all build metadata, execution telemetry, and pipeline configuration changes ingested into the SIEM (Level 3).
Regulatory reporting playbooks. Automated playbooks aligned with CRA and NIS2 reporting timelines — 24-hour and 72-hour windows (Level 4).

What Should You Do Next?

If you are assessing where your organisation stands today, here is a practical starting point for each maturity level:

If you are at Level 0–1 (no formal controls):

Enforce MFA on all repository and CI/CD platform accounts — this blocks the most common account-takeover vector.
Enable branch protection on all main branches with mandatory code review.
Run a secret scanner (e.g., Gitleaks) across your repositories and remediate any findings.

If you are at Level 1–2 (basic controls, no automation):

Generate SBOMs for all builds and commit lockfiles — the CRA makes this mandatory.
Create an approved allowlist for CI/CD actions and third-party plugins.
Move secrets from environment variables to a centralised vault (KMS, HashiCorp Vault).

If you are at Level 2–3 (automated but not segmented):

Implement ephemeral CI/CD credentials — replace static tokens with JIT token exchange.
Switch to immutable, single-use build agents.
Make SBOM validation a build gate — fail the build if SBOMs are missing or contain known-vulnerable components.

If you are at Level 3 (pursuing Level 4):

Implement reproducible builds and full SLSA L4 attestation.
Deploy eBPF-based runtime monitoring (e.g., StepSecurity Harden-Runner) on CI/CD runners.
Pin all dependencies — including security tools — by digest, not mutable tags.
Establish automated incident response playbooks with an MTTR target below one hour.

Conclusion

The signature incidents of 2024 through early 2026 — from the deep stealth of XZ Utils, to TeamPCP’s cascading campaign that weaponised security scanners, to the state-sponsored hijack of Axios, to GlassWorm’s systematic compromise of developer IDEs — confirm that legacy security models are obsolete.

The CI/CD Security Maturity Framework provides a structured path from basic hygiene to continuous assurance and Zero Trust. The evolution requires three strategic pivots:

Eliminate standing privilege. Move from vaulted secrets to Just-In-Time ephemeral credentials (Level 3). This prevents attackers from leveraging stolen tokens for persistence or lateral movement.
Verify at runtime and at the artifact level. Full SLSA L4 attestation and reproducible builds, combined with eBPF runtime defense (Level 4), transform the pipeline into a verifiable production factory that detects injection attempts mid-build.
Institutionalise governance. SBOM enforcement meets EU CRA transparency requirements. Continuous supplier risk scoring and rapid incident response align with NIS2. ML-BOMs establish readiness for the emerging AI supply chain regulatory landscape.

The CI/CD pipeline is the central hub of intellectual property and trust. Defend it accordingly.

Sources

Financial Impact and Industry Analysis

XZ Utils (CVE-2024-3094)

Andres Freund — Original disclosure on oss-security (March 29, 2024)
Red Hat — Urgent Security Alert for Fedora 41 and Rawhide Users (March 29, 2024)
CISA Alert — CVE-2024-3094 (March 29, 2024)

Polyfill.io

Sansec — Polyfill Supply Chain Attack Hits 100K+ Sites (June 25, 2024)
BleepingComputer — Polyfill.io Supply Chain Attack Impacts Over 100K Sites (June 25, 2024)
Censys — Over 384,000 Hosts Still Referencing Malicious Polyfill.io Domain (July 2, 2024)

tj-actions/changed-files (CVE-2025-30066, CVE-2025-30154)

Standards and Frameworks

Regulatory

EU Cyber Resilience Act — Regulation (EU) 2024/2847 (Adopted October 2024)
EU CRA — Digital Strategy Overview
EU NIS2 Directive — Directive (EU) 2022/2555 (Adopted November 2022)
EU NIS2 — Digital Strategy Overview
US Executive Order 14028 — Improving the Nation’s Cybersecurity (May 12, 2021)