What breaks when CI/CD security relies only on artifact scanning?

Why This Matters for Security Teams

Artifact scanning is useful, but it only answers part of the question. A clean container image or dependency report does not prove the build was trustworthy, reproducible, or sourced from approved inputs. If the pipeline can fetch packages at build time, inherit an unpinned base image, or evaluate templates that change outside version control, the scanned artifact may already differ from what developers thought they released.

This matters because security teams are often asked to certify a release, not just inspect its output. When lineage is missing, the team cannot confidently connect the binary to the commit, build recipe, signing event, and dependency graph that produced it. That gap weakens incident response, slows root-cause analysis, and creates audit friction when questions arise about provenance, integrity, and change control. The control expectation aligns closely with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need evidence that system components are authorised, monitored, and protected from tampering.

In practice, many security teams encounter these gaps only after a release needs to be explained during an incident, rather than through intentional build governance.

How It Works in Practice

Effective CI/CD security treats scanning as one layer in a larger integrity model. The practical goal is to ensure that what gets built, what gets scanned, and what gets deployed can be traced back to trusted inputs. That means pinning base images by digest, locking dependency resolution, recording build metadata, and signing artefacts so downstream systems can verify provenance before deployment.

Build provenance is especially important when pipelines use generated code, reusable templates, or remote actions. Those inputs can change without a source repository diff that is obvious to reviewers. Security teams should expect artefact scanning to miss these shifts because scanners usually inspect the final package, not the path used to create it. Best practice is to pair scanning with admission checks, signed attestations, and policy gates that verify the build came from an approved pipeline and branch.

• Pin sources and dependencies so the build is repeatable.
• Capture SBOMs, provenance data, and signatures together, not separately.
• Verify that the build identity, runner, and signing key are trusted.
• Block deployment when the artefact cannot be matched to approved lineage.

Framework guidance such as the CISA Secure by Design and software supply chain guidance reinforces this approach by emphasising secure build processes, not just secure outputs. Where organisations use policy-as-code, the policy should evaluate provenance claims, not only vulnerability severity. These controls tend to break down when ephemeral runners, dynamic package mirrors, or heavily templated infrastructure are allowed to introduce undocumented build-time changes because the resulting artifact no longer reflects a stable, inspectable chain of custody.

Common Variations and Edge Cases

Tighter build provenance often increases pipeline complexity and operational overhead, requiring organisations to balance delivery speed against release assurance. That tradeoff is real, especially in multi-language repositories, monorepos, and platforms that assemble software from many upstream packages.

There is no universal standard for how much provenance evidence is enough. Current guidance suggests that higher-risk systems should require stronger attestations, while lower-risk internal tools may accept a lighter control set if the organisation can still explain build inputs and deployment decisions. The right threshold depends on blast radius, regulatory exposure, and how much third-party code enters the pipeline.

Edge cases often appear in environments that use remote build services, container layer caching, or generated artefacts from AI-assisted development. In those settings, a scanner may report a safe result while the actual risk sits in the build graph, the signing step, or an upstream dependency that changed after approval. Identity also matters here: if the CI/CD system uses non-human identities, those identities need tightly scoped permissions, short-lived credentials, and clear ownership so provenance evidence remains trustworthy. Teams handling regulated workloads should map these controls to software supply chain expectations and to the broader assurance model in NIST control guidance and related software assurance practices.

Related resources from NHI Mgmt Group

• What is workload identity federation and why is it important for CI/CD security?
• How do I implement secrets scanning in a CI/CD pipeline?
• When should teams prioritise CI/CD hardening over broader secret scanning?
• How should security teams govern machine credentials across cloud and CI/CD environments?