How does Cosign work?

What Cosign actually does in the supply chain

Cosign is a signing and verification tool for software artefacts. It creates a cryptographic signature over an image, binary, or other artefact, then verifies that signature before the artefact is trusted. The security value is not just “signing”, but proving that the object being deployed matches what was signed and has not been altered in transit or after publication.

In practice, that means Cosign becomes a gate in the release or deployment path. If the signature check fails, the artefact is treated as untrusted. If it passes, defenders gain a cryptographic integrity check that supports provenance enforcement, policy decisions, and tamper detection.

Cosign is commonly used with SLSA and Build Provenance Guide because the real control is not only “was it signed?” but “can I trace this artefact back to a trustworthy build and signer?”

How Cosign ties signatures to trust

Cosign can bind signatures to either a private signing key or an identity-based trust model, often called keyless signing. In the key-based model, trust depends on protecting the signing key and verifying the matching public key. In the identity-based model, trust depends on validating the signer’s authenticated identity and the rules that say that identity is allowed to sign that artefact.

That distinction matters operationally. Key-based signing puts more pressure on key custody and rotation. Identity-based signing reduces long-lived key handling, but shifts control to identity assurance, certificate trust, and policy that decides which identities are permitted to attest to which releases.

For teams mapping this to broader control practice, NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support the same idea: trust decisions should be explicit, governed, and auditable rather than implicit.

What Cosign checks before something is trusted

At verification time, Cosign checks whether the signature is valid and whether the verified artefact is the same object that was originally signed. That is what stops silent modification, substitution, or “looks similar but is not the same” artefacts from entering use.

Defenders usually pair that check with provenance or policy requirements, such as requiring signatures from approved identities, requiring attestations, or rejecting unsigned artefacts outright. In a mature setup, the signature is not a decorative metadata field. It is a deployment control that decides whether the pipeline continues.

This is why SLSA is a natural companion concept. Cosign verifies trust in the artefact, while SLSA helps define how strong that trust should be and what evidence should exist behind it.

Risk and Threat Considerations

Cosign reduces supply-chain tampering risk, but it only works if the signing trust path is itself controlled. A stolen signing key, a weak identity trust rule, or an overly permissive verification policy can let a malicious artefact pass as legitimate even though the signature is technically valid.

Failure mechanism: Attackers or insiders obtain a signing path, reuse a trusted identity, or exploit a policy gap so that altered, replayed, or rogue artefacts still satisfy verification checks.

Impact: Unsigned or tampered code can be blocked, but trusted-signature abuse can instead turn Cosign into a false assurance layer, allowing compromised artefacts to reach production with a clean trust signal.

Practitioner Guidance

What to verify: Verify which trust model you are actually using, key-based or identity-based, and make sure the verification policy matches that model. If the policy is only checking that “a signature exists”, it is too weak for production use.

Decision rule: If the artefact can execute in production or influence downstream builds, require signature verification at deploy time and reject exceptions by default. Treat “we will check later” as a control failure, not a temporary convenience.

What good looks like: The release process can show who signed the artefact, what was signed, what policy was enforced, and why the verifier accepted or rejected it. That evidence should be available without manual reconstruction after an incident.

Practitioner takeaway: Cosign is best understood as a trust enforcement point, not just a signing utility. Its value comes from combining cryptographic integrity with a policy that makes untrusted artefacts fail closed.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?