How should security teams verify software artifacts before deployment in CI/CD pipelines?

What to verify before a build artifact is allowed into deployment

Artifact verification should answer one question: did this object come from the expected build process, and has it stayed intact since then? Provenance ties the artifact to a specific source and pipeline; signature validation checks integrity and signer trust; build-source identity confirms the repository, branch, and CI environment that produced it. When any of those are missing, the artifact should be treated as untrusted, even if it looks operationally normal.

That distinction matters because deployment pipelines often trust what they receive by default. In practice, teams should verify the attestation or metadata, not just the binary, and compare it to the expected delivery path. SLSA is the clearest external reference point for this model because it centers build provenance and integrity as first-class deployment controls.

How provenance, signatures, and source identity work together

Provenance answers where the artifact came from, signatures answer whether it was altered after signing, and source identity answers whether the build was produced by the right repository and automation context. None of those checks is redundant. A valid signature on the wrong artifact is still a failure; a correct provenance record without signature validation is still forgeable; and a signed artifact from an unexpected branch or runner can still be dangerous if the build path was compromised.

The strongest practice is to verify all three conditions as a single gate, then enforce that gate as close to deployment as possible. That usually means the CI/CD system, release controller, or admission policy rejects anything that does not match the expected digest, signer, and attestation claims. Teams that already rely on CI/CD Pipeline Identity Security Guide should use the same build identity discipline here: the artifact is only trustworthy if the pipeline identity and publishing path are trustworthy too.

For teams managing cloud builds, Cloud Workload Identity Guide is directly relevant because keyless federation and temporary credentials reduce the chance that a stolen static secret can impersonate the build system and produce a believable but malicious artifact.

Where verification belongs in the pipeline, and what it should block

Verification belongs at the point where an artifact becomes deployable, not only at build time. That may be the release job, artifact repository promotion step, Kubernetes admission control, or another policy enforcement point. The control should block unsigned artifacts, mismatched hashes, unknown signers, expired attestations, and provenance that does not match the expected repository, branch, workflow, or environment.

Security teams should also treat verification as a policy problem, not a manual review habit. If the check happens only when someone remembers to inspect a package, it is not reliable enough for production. The goal is automatic rejection of untrusted artifacts, with a clear audit trail showing why the artifact was accepted or denied. For teams using build-time attestations and keyless signing, the same pipeline identity controls should govern both who can publish and which artifacts can pass verification.

Attacks against CI/CD often exploit the gap between “built” and “trusted.” A compromised action, token, or publishing path can make a malicious artifact look legitimate enough to pass weak checks. Real-world supply chain incidents show why teams should assume the build path itself can be abused, not just the resulting file. GitHub Action tj-actions Supply Chain Attack is a useful example of how one compromised pipeline component can expose secrets and undermine trust in downstream output.

Practitioner Guidance

What to verify: Require a signed attestation that binds the artifact digest to the expected repository, branch, commit, workflow, and CI environment. If the attestation cannot prove those fields, treat the artifact as untrusted even if the file hash itself matches a previously seen value.

What good looks like: The deployment system automatically accepts only artifacts that meet the policy, and operators can show which signer, build source, and pipeline produced each release. That gives you a deterministic trust decision instead of a best-effort manual review.

Common mistake: Teams often verify the artifact after it has already been promoted or mirrored, which creates a trust gap. The safer pattern is to verify before promotion or admission, so the untrusted object never becomes a candidate for production deployment.

Practitioner takeaway: The control is not “check the checksum,” it is “prove the artifact came from the expected build path and enforce that proof automatically at the deployment boundary.”

Related resources from NHI Mgmt Group

• How should security teams detect unauthorized software releases in CI/CD pipelines before users are affected?
• How should security teams implement software composition analysis in CI/CD pipelines?
• How should security teams use a software supply chain framework to verify release risk before deployment?
• How should security teams hunt for malicious logic in code repositories and CI/CD pipelines before it reaches production?