CICD-SEC-9 is the OWASP CI/CD risk where a pipeline passes along code or artifacts without checking they are genuine. An attacker with a foothold in any step can slip in a tampered file that looks legitimate. The fix is to sign what you produce and verify before the next step uses it.
What does the risk actually say?
OWASP's Top 10 CI/CD Security Risks defines it as insufficient mechanisms for validating code and artifacts. A delivery process has many stages and many inputs, from internal builds to third-party packages and scripts fetched from remote hosts. Each hand-off is a place where something can be swapped. If nothing checks the swap, the tampered item flows down the pipeline "in the guise of a legitimate resource," all the way to production.
The impact OWASP names is execution of malicious code, either on the build systems themselves or in production. Its references include the compromise of the SolarWinds build system.
Where are the gaps in a normal pipeline?
Walk the path of one release:
- A developer commits. Is the commit signed, and is the signature required?
- The build pulls dependencies. Does it use a lockfile with hashes, or whatever is newest?
- The build writes an image to a registry. Can anyone with registry write access replace it?
- The deploy step pulls the image by tag. Tags can be moved. A digest cannot.
- A build script downloads a tool with curl and runs it. Is the hash checked?
Most teams find at least three of these unguarded the first time they look.
What are the recommended controls?
OWASP suggests signing a resource when it is generated, using an external signing infrastructure, and validating it against the signing authority before the next step consumes it. It names three families of measures:
- Commit signing in source control, so unsigned commits cannot proceed.
- Artifact signing and verification tools. OWASP points to in-toto, SLSA and Sigstore, all Linux Foundation projects.
- Configuration drift detection, to spot resources deployed outside signed infrastructure templates.
For third-party resources fetched during builds, calculate the hash and compare it to the one the provider publishes.
SLSA gives a ladder for this: it describes incremental guidelines for supply chain security and asks for provenance, a record of where and how an artifact was built, so a consumer can decide whether to trust it.
A constructed example
A team deploys containers by pulling "app:latest" from an internal registry. A compromised service account pushes a modified image under that tag at night. The next deploy pulls it. Nothing fails, because nothing checks. After the team signs images at build time and the cluster admission step verifies the signature and pins by digest, the same push is rejected at deploy, and the alert names the unsigned image.
What does good evidence look like?
When an auditor or an incident responder asks whether a production artifact is the one you built, you want to answer with records, not memory. That means a signature that verifies, a provenance record naming the commit, the build system and the time, and a log of who or what approved the release. If you cannot produce those three for a random production artifact today, that is your baseline gap, and it is a fair first target for the next quarter.
How to check or apply this
- Draw your pipeline and list every place an artifact is created, stored or fetched.
- Require signed commits on protected branches.
- Pin dependencies with a lockfile that records hashes, and install from it only.
- Reference images by digest, not by tag.
- Sign build outputs and verify the signature in a gate before deploy.
- Record provenance, so you can answer who built this artifact, from which commit, on which runner.
- Hash and verify every script or binary your build downloads.
- Limit who can write to the registry, and alert on writes from unexpected identities.
Safeguard's policies and gates can block a release when verification or dependency checks fail, which covers step 5 from the dependency side.
Quick check
How is this different from a dependency vulnerability?
A vulnerable dependency is a real package with a flaw. This risk is a fake or altered artifact that nobody noticed was swapped.
Do I need all of SLSA to start?
No. SLSA is incremental. Signed commits, lockfile installs and digest pinning are a sensible first layer.
Sources
- OWASP CICD-SEC-9: Improper Artifact Integrity Validation
- SLSA, About SLSA
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
