Most security teams have a clear picture of their application security risks. They know where their APIs are exposed, which libraries have CVEs, and how authentication works. But there’s a blind spot that attackers have been exploiting with increasing frequency: the pipeline itself.
CI/CD systems are the most privileged infrastructure in any engineering organization. They have access to source code, cloud credentials, artifact registries, and production environments. Compromise the pipeline, and you compromise everything downstream — as SolarWinds, Codecov, and the recent TanStack incident demonstrated.
In 2022, OWASP published the Top 10 CI/CD Security Risks — a framework created by Daniel Krivelevich and Omer Gil (then at Cider Security) based on extensive research across hundreds of CI/CD environments and high-profile breaches. It’s the closest thing the industry has to a shared threat model for software delivery infrastructure.
Here’s what every risk means and what you can do about it.
CICD-SEC-1: Insufficient Flow Control Mechanisms
The risk: No single entity — human or programmatic — should be able to ship code to production without external verification. When flow controls are missing, a compromised developer workstation or a malicious insider can push unreviewed code straight through the pipeline.
What to do: Enforce mandatory code reviews, require sign-offs on pull requests to protected branches, and gate production deployments behind approval workflows. Branch protection rules in GitHub and GitLab, combined with CI-level deployment gates, catch most of this.
CICD-SEC-2: Inadequate Identity and Access Management
The risk: Engineering environments have hundreds of identities — human accounts, service accounts, bot tokens, machine users — spread across SCM, CI, artifact registries, and cloud providers. Most are overly permissive. Compromising any one of them can provide a foothold into the delivery pipeline.
What to do: Apply least privilege everywhere. Audit who has write access to repositories, who can trigger production deployments, and which service accounts have standing access to sensitive systems. Rotate credentials regularly and revoke access that hasn’t been used in 90 days.
CICD-SEC-3: Dependency Chain Abuse
The risk: This is the category most teams are familiar with — and the one that keeps producing headlines. Dependency chain abuse covers four main attack vectors:
- Dependency confusion — publishing a malicious package to a public registry with the same name as an internal package
- Dependency hijacking — compromising a maintainer’s account and publishing a malicious version of a legitimate package
- Typosquatting — registering package names that look like popular ones (
lodahsinstead oflodash) - Brandjacking — publishing packages that imitate a trusted brand’s naming conventions
The axios incident (March 2026) and the TanStack/Mini Shai-Hulud campaign (May 2026) are textbook dependency hijacking attacks. Both resulted from compromised maintainer credentials and affected millions of downstream users.
What to do: Use lockfiles and pin exact versions. Route all package fetches through an internal proxy or private registry. Enable checksum and signature verification for pulled packages. Scope private packages under an organization namespace and enforce that scope in client configuration. Generate SBOMs for every build so you know exactly what dependencies are in play — and scan them for known vulnerabilities on every commit.
boring.tools generates CycloneDX and SPDX SBOMs automatically for every repository commit and scans them against OSV, NVD, and GitHub Security Advisories, including transitive dependencies.
CICD-SEC-4: Poisoned Pipeline Execution (PPE)
The risk: An attacker with access to the source code repository — but not the CI system itself — can “poison” the pipeline by modifying files the CI job will execute. There are three variants:
- Direct PPE (D-PPE) — modifying the CI configuration file (e.g.,
.github/workflows/*.yml) directly - Indirect PPE (I-PPE) — modifying files the pipeline references, like Makefiles, test scripts, or linter configs
- Public PPE (3PE) — exploiting the same technique through pull requests on public repositories
The result is the same: the attacker’s code runs inside the build environment with full access to secrets and cloud credentials.
What to do: Never run pipelines on unreviewed code. Require manual approval for pipelines triggered from forks. Isolate build nodes so that unreviewed code executes without access to production secrets. Store CI configuration files in protected branches separate from the application code.
CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
The risk: Pipelines that run with overly broad permissions — access to multiple cloud environments, multiple artifact registries, or secrets that belong to other teams — turn a single pipeline compromise into a lateral movement opportunity.
What to do: Scope each pipeline’s credentials to exactly what it needs. Use OpenID Connect (OIDC) for cloud access instead of static keys with broad permissions. Run pipelines on ephemeral, disposable nodes. Segment build networks so pipeline nodes can only reach the resources they need — not the internet at large.
CICD-SEC-6: Insufficient Credential Hygiene
The risk: Secrets and tokens scattered across CI configuration files, environment variables, source code, and documentation. Hardcoded API keys, long-lived service account tokens, and credentials checked into git repos are all alarmingly common.
What to do: Use a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or a CI-native solution like GitHub Actions secrets). Rotate credentials on a schedule. Scan repositories for accidental secret leaks as part of every commit. Never pass secrets through pipeline configuration files or build logs.
CICD-SEC-7: Insecure System Configuration
The risk: Build nodes, CI controllers, artifact servers, and registry proxies running with insecure defaults, unpatched software, or overly permissive network configurations.
What to do: Treat CI/CD infrastructure the same way you treat production infrastructure. Harden base images, apply security patches promptly, disable unused services, and audit configurations against benchmarks (CIS, NIST). Run build nodes as immutable, ephemeral containers rather than long-lived VMs.
CICD-SEC-8: Ungoverned Usage of 3rd Party Services
The risk: Teams integrate third-party services — code coverage tools, quality gates, performance monitoring, package registries — into their pipelines with minimal security review. A compromised third-party service that executes code in your pipeline (like the Codecov breach) can exfiltrate secrets or inject malicious artifacts.
What to do: Maintain an inventory of every third-party service integrated into your pipeline. Review their security posture before enabling them. Pin specific versions of external scripts and verify their integrity using checksums. Monitor for unexpected changes in third-party integrations.
CICD-SEC-9: Improper Artifact Integrity Validation
The risk: An attacker who gains a foothold anywhere in the delivery chain can push a malicious artifact downstream if there’s no mechanism to verify that the artifact hasn’t been tampered with. This is how the SolarWinds attack worked — malicious code was inserted during the build process without leaving traces in source control.
What to do: Implement software signing and attestation throughout the pipeline. Sign commits with GPG or SSH keys. Use frameworks like Sigstore, SLSA, and in-toto to create verifiable provenance chains: “this binary was built from this commit, by this CI system, on this date.” Verify signatures before promoting artifacts between stages. Compare checksums of fetched resources against published hashes.
CICD-SEC-10: Insufficient Logging and Visibility
The risk: If you can’t see what’s happening in your CI/CD environment, you can’t detect a compromise — and when you do discover it, you can’t investigate. Most engineering environments are severely under-logged compared to production infrastructure.
What to do: Enable audit logging on every system in the delivery chain — SCM (push events, branch creation, permission changes), CI (build triggers, configuration changes, secret access), artifact registries (package uploads, version yanks), and deployment systems. Ship all logs to a centralized SIEM. Build detections for anomalous patterns: builds triggered outside business hours, unexpected credential usage, or deployments from unusual branches.
A shared vocabulary for pipeline security
The OWASP Top 10 CI/CD Security Risks gives security and engineering teams something they’ve been missing: a common language to talk about pipeline risk. It doesn’t prescribe specific tools — it describes the problem space. #3 (Dependency Chain Abuse) and #9 (Improper Artifact Integrity Validation) are where most supply-chain-focused tooling, including SBOM generation and vulnerability scanning, provides the most direct defense.
The rest of the list — flow controls, IAM, credential hygiene, logging — is infrastructure fundamentals. Harder to productize, but just as important.
boring.tools generates CycloneDX and SPDX SBOMs from your repositories, scans them for vulnerabilities on every commit, and tracks artifact provenance so you always know what went into any release. See how it works →