How do you sign container images and attest SBOMs with cosign in CI pipelines?

How cosign changes the release pattern for container images and SBOMs

Cosign makes signing part of the release artifact lifecycle, not an after-the-fact manual review. In CI, the release job should produce the image, sign the image digest, and attach an attestation for the SBOM so consumers can verify integrity and provenance before deployment. The practical shift is that trust moves to verifiable artefacts, not to the pipeline’s word.

For release engineering, that means the signature and attestation need to travel with the image in a way downstream systems can validate reliably. A clean pattern is to build once, sign once, and publish the image, signature, and SBOM attestation as a single release set. That keeps verification simple for admission controllers, deployment gates, and artifact consumers.

When the workflow is done well, the image digest becomes the stable reference point. The signature binds the release to the signing identity, and the SBOM attestation binds the software contents or metadata to that same release point. This is why image tag checks alone are not enough, tags move, but digests, signatures, and attestations give you a durable trust chain.

What a CI pipeline must protect before it signs

Signing only helps when the signing step is separated from untrusted build activity. The signing identity, whether keyless or key-backed, should not live inside general build containers, and build jobs should not be able to mint release-grade signatures on their own. If an attacker can influence the build job, they can often influence what gets signed.

That is why pipeline design matters as much as the cosign command itself. Use a protected release stage, keep signing permissions tightly scoped, and treat the build job as untrusted until it has finished producing the artifact that will be signed. If you use keyless signing, the CI identity and trust policy become part of the control surface; if you use keys, key handling and rotation become equally important.

For an implementation baseline, it helps to align the release flow with Container Image Security Guide, because the signing step only makes sense when the image itself, registry path, and verification path are all controlled. The broader release discipline is reinforced by the SLSA and Build Provenance Guide, which ties signing and provenance to the build process rather than treating them as separate documentation tasks.

How to verify before deployment, not after an incident

Verification should happen at the point of consumption, not merely at publish time. Admission controls, promotion gates, and deployment checks should refuse unsigned images and unattested SBOMs, or at minimum refuse artefacts that do not match the expected signer, digest, and policy. This is the control that turns cosign output into an enforceable trust decision.

SBOM verification adds a second layer of assurance. The SBOM attestation should be checked for provenance, completeness expectations, and consistency with the image being deployed. If the SBOM is detached from the digest, or if a deployment system accepts a signature without validating the attestation, you lose the ability to tie the released artifact to what was actually built.

The surrounding supply-chain controls are best understood alongside the SBOM Guide and the OpenSSF guidance ecosystem, because image signing is most effective when SBOM generation, provenance, and policy enforcement are treated as one workflow. For the container-specific side, NIST SP 800-190 Container Security remains a useful reference for registry, image, and runtime trust boundaries.

Risk and Threat Considerations

Signed images and signed SBOMs reduce supply-chain ambiguity, but they do not remove pipeline compromise risk. If a release job is poisoned, the attacker may be able to sign a malicious image or attach a misleading attestation, which makes downstream trust decisions dangerously confident instead of safer.

Failure mechanism: The control fails when signing authority is reachable from untrusted build steps, when verification is optional, or when release policy checks the existence of a signature but not its signer, digest, or attestation binding.

Impact: A malicious or tampered image can be promoted as trusted, and an inaccurate SBOM can hide vulnerable or unauthorized components until runtime or incident response.

Practitioner Guidance

What to verify: Confirm that the CI job signs the exact image digest produced by the release build, not a mutable tag, and that the SBOM attestation is attached to the same digest. Also confirm that deployment policy rejects unsigned artefacts by default.

Decision rule: If the signing identity can be influenced by the same environment that builds unreviewed code, separate the release signer from the build job before expanding usage. If not, treat the pipeline as capable of producing trusted-looking output that is not actually trustworthy.

Common mistake: Teams often validate signatures in a registry UI or during publishing, then forget to enforce the same check at admission time. That leaves the strongest control outside the enforcement path.

Practitioner takeaway: Cosign is most effective when signing, attestation, and verification are all policy-enforced parts of the release path, because trust only works when every consumer checks the same digest-bound evidence.

Related resources from NHI Mgmt Group

• How should teams secure GitLab CI pipelines that build and deploy container images automatically?
• Why do private container images increase NHI risk in CI/CD environments?
• How should teams generate SBOMs without slowing CI pipelines?
• How should security teams prevent malicious Docker images from entering CI/CD pipelines?