SBOM and container image signing: Cosign, Sigstore, and supply chain security in the cloud

Kubernetes should not receive just an image with a familiar name like app:1.2.3, but a verified artifact: one with an immutable digest, a software bill of materials, a signature, and build information.

To make this easier to follow, we have prepared a short list:

• SBOM (Software Bill of Materials) shows what is inside the image: packages, libraries, versions, and licenses.
  
• Signing with Cosign verifies the specific image and the expected publisher.
  
• Attestation and provenance link the image to additional evidence: a bill of materials and information about the build process.
  
• Digest is more important than tag because a tag can be overwritten, while a digest points to specific content.
  
• Kubernetes admission policy turns validation into an admission rule: an unsigned or unverified image must not be allowed to run.
  
• SBOM and a signature do not automatically make an image secure: they do not fix CVEs, replace CI/CD security, or verify the application's business logic.

The goal is not to “sign the image just to tick a box,” but to ensure that Kubernetes runs only verified artifacts and that the team can quickly prove exactly what was run, who released it, and what the image contains.

Why this matters for cloud infrastructure

In Kubernetes, teams often use a familiar image name: app:1.2.3, backend:stable, or even app:latest. On a normal day, this seems convenient: the tag is clear to developers and easy to specify in a Helm chart, a manifest, or release notes. But during an incident, a tag alone is no longer enough.

The team needs to answer several questions quickly: who built the image, from which code, which dependencies were included, whether the tag was overwritten, and whether the artifact running in the cluster is really the one that went through the release process. Without those answers, the investigation turns into a manual review of the registry, CI logs, and old deployments.

That is why supply chain security is built not around a single tool, but around a collection of evidence. An SBOM shows the contents, a signature confirms the specific artifact and publisher, an attestation adds verifiable build information, and an admission policy in Kubernetes makes these checks mandatory before the image is allowed to run.

Next, we should examine what evidence is needed before a container image is run and why a Cosign signature alone is not enough.

What must be proven before running a container image

A container image cannot be assessed with a single “allowed to run” stamp: before running it, you need to understand what is inside, who published the artifact, whether its contents have changed since publication, and what process was used to build the image.

A simple analogy is the delivery of hardware to a data center. Seeing a familiar name on the box is not enough. You need a list of components, a tamper-evident seal, and a document showing the origin of the shipment. The logic for containers is similar: instead of a component list, there is an SBOM; instead of a seal, a signature; and instead of an origin document, build information.

To avoid mixing these layers, it is better to separate the evidence by purpose:

This model shows the key point: a signature alone does not reveal the contents of an image, and an SBOM by itself does not prove who published the artifact or whether it has been tampered with. A workable model exists only when all evidence is tied to the same image and verified before it is run.

Attestation is needed precisely to establish this link. It is a signed statement about a property of an artifact: for example, “this SBOM was created for this image” or “this image was built by this process.” Provenance is a specific and important type of attestation: information about the origin of the build. This usually includes the repository, commit, build script, build environment, and other metadata.

At deployment time, these pieces of evidence come together in Kubernetes. An admission policy can allow only images that have a signature from the expected publisher, a verified SBOM, and information about the origin of the build. If the evidence is missing or does not match the rules, the workload should not start automatically.

This gives the team not manual trust in the pipeline, but a verifiable chain: during a release, it is clear why the image is allowed, and during an incident, it is possible to reconstruct which artifact was run, what it contained, and what process was used to build it.

Why a digest is more important than a tag

In the previous chapter, we covered the evidence required before running an image: its contents, signature, build information, and admission policy. But all of this evidence is meaningful only when it applies to a specific artifact, not to a convenient name.

A tag is convenient for people. A string such as registry.example.com/app:1.2.3 clearly indicates release 1.2.3, and it is easy to specify in a Helm chart, Kubernetes manifest, or release notes. But a tag is a pointer. It can be overwritten, reused, or accidentally made to point to a different image.

A simple scenario: yesterday, app:1.2.3 pointed to one image; today, after a rebuild or manual publication, it points to another. The string in the manifest looks the same, but the content has changed. For validating the SBOM, signature, and build information, this is critical: the evidence must apply to the specific content, not to the release name.

A digest solves this problem. It is an immutable content-based identifier for an image, for example registry.example.com/app@sha256:.... If the published artifact changes, the digest changes as well. As a result, app:1.2.3 can be a convenient label for humans, while app@sha256:... is the exact object that the system verifies.

In short, a tag is like a label that says “release 1.2.3,” while a digest is like the content’s serial number. The label can be moved; the serial number is tied to what is inside.

In practice, this leads to three rules:

1. Retrieve the digest after publishing the image to the registry;
   
2. Create the SBOM, signature, and attestation for image@sha256:..., not only for the name with a tag;
   
3. In Kubernetes policies, verify the digest and the expected publisher, not just a familiar image name.

This turns the check “image app:1.2.3 is signed” into a stricter check: “the specific app@sha256:... is signed by the expected publisher.” This is also important during incident investigations. The team can accurately reconstruct which artifact was run, which SBOM applied to it, and which build information was valid.

If the SBOM was created for one digest, but a different one reached the cluster, the bill of materials no longer proves the contents of the running image. It describes a different artifact. This is why the digest becomes the anchor that all other evidence is tied to.

Once the object of trust has been pinned down, the next question is: who attests to this artifact, and why can that attestation be trusted? This is where Cosign and Sigstore come in.

Cosign and Sigstore: What They Add to the Chain of Trust

In short, Cosign and Sigstore add verifiable evidence: a signature, a link to the expected publisher, and information about the build process.

Cosign is a tool for signing and verifying container images and other OCI artifacts. It can sign a specific digest, verify a signature, and create signed attestations about an artifact’s properties, such as its contents or build provenance.

Sigstore is broader. It is an ecosystem that helps establish trust in such signatures without ongoing manual management of private keys. In simplified terms, Cosign creates and verifies the signature, while Sigstore helps determine who signed the artifact and why that signature can be trusted.

This model includes several important components:

• Cosign — signing, verification, and signed attestations for artifacts;
  
• OIDC/keyless — signing without a long-lived private key, with identity provided by CI/CD;
  
• Fulcio — a short-lived certificate for a verified identity;
  
• Rekor — a transparency log that records the signing event.

The practical value is that the image is signed not by an abstract “someone with a key,” but by a specific process. For example, a release script in the expected repository and branch. That is why verification should check not only that the signature is technically valid, but also the signer’s identity: whether this is the workflow, job, or service account that the organization trusts.

This is especially important for CI/CD. If a pipeline stores a long-lived private key, it can be stolen and used later. With a keyless approach, there is no persistent key: the CI/CD process obtains a verified identity through OIDC, and Fulcio issues a short-lived certificate specifically for that build.

For a team, this has two practical effects. Before deployment, artifacts signed by the wrong process can be blocked automatically. During an investigation, it is possible to see which CI/CD environment produced the image and whether there is a record of the signature in the Rekor transparency log.

The evidence now forms a coherent chain: the digest identifies the specific image, the SBOM describes its contents, Cosign signs the artifact and attestations, and Sigstore helps verify the trusted identity. The next step is to assemble this into a working pipeline: building the image, publishing it, obtaining the digest, generating the SBOM, signing, attestation, and verification before deployment to Kubernetes.

What the pipeline looks like: from image build to validation before Kubernetes

What CI does

First, CI builds the image and publishes it to the registry. After publication, the pipeline obtains the digest of the published image. This is important: the registry records the final artifact that Kubernetes will later download. If you sign a local intermediate build or only a tag, the evidence may refer to the wrong object.

Next, an SBOM—a software bill of materials—is created for this digest. For example, you can use Syft for this: it analyzes the image and generates a list of packages, libraries, versions, and licenses in SPDX or CycloneDX format.

After that, the SBOM should not remain just another file among the CI artifacts. It must be linked to a specific digest through an attestation so that, during verification, it is clear that this bill of materials describes this exact image, not a similar build with the same tag.

The pipeline then creates build provenance information: which repository, commit, and workflow were used to build the image, and in what environment and with which parameters. This is not “pretty JSON for a report,” but evidence that helps establish the origin of the artifact.

After that, the image itself is signed with Cosign. As a result, three layers of evidence are linked to a single digest: composition, build provenance, and the signature of the expected publisher.

What to verify before deployment

Before deployment, it is important to verify more than just the presence of a signature. A valid signature is useful only when it is clear who created it and why that process can be trusted.

The verification should answer several questions:

• Whether this specific digest is signed;
• Whether the signer matches the expected identity;
• Whether there is an SBOM associated with this image;
• Whether there is build provenance information;
• Whether the check was completed before the workload reached Kubernetes.

If the SBOM is skipped, the team will not be able to quickly analyze the image contents when a vulnerability is discovered. If no attestation is created, the bill of materials remains a separate file that is harder to associate with a specific artifact. If the signer’s identity is not verified, a valid signature still does not prove that the image was produced by the required release process.

Manual verification with cosign verify is useful as a test, but it is not sufficient for production. In an operational workflow, verification must become an admission rule: Kubernetes itself rejects a Pod, Deployment, or Job if the image does not have the required signature, SBOM, or build information.

This turns the pipeline from a set of commands into a chain of trust. CI produces the artifact, the evidence is tied to the digest, Cosign and Sigstore help verify the publisher, and Kubernetes allows only images that comply with the policy to run.

Pre-deployment checks in Kubernetes: admission policy

The pipeline can prepare all the evidence: the digest, SBOM, signature, and build information. But as long as these are checked by a person or a separate CI team, this remains a matter of process discipline. For a production environment, something else is more important: Kubernetes must reject unverified images before they are run.

This point is called admission. When a user, CI/CD system, or GitOps system submits a manifest to the Kubernetes API, the API server can pass the request to a policy controller. The controller looks at which image is specified in the workload, verifies the evidence in the registry, and decides whether the resource can be created.

The purpose of an admission policy is simple: an image without the required signature, without a verified SBOM, or without build provenance information must not be started automatically. This is no longer a recommendation in the documentation; it is an admission rule.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

Different implementations are possible: Sigstore Policy Controller, Kyverno with Cosign checks, OPA Gatekeeper combined with external checks, or commercial admission controllers. From an architecture perspective, the specific product matters less than the set of conditions checked before startup:

• The image must come from the expected registry;
• Verification must apply to the digest, not only to the tag;
• The signature must have been created by a trusted build process;
• The SBOM must be associated with this image;
• The provenance attestation must confirm the origin of the build if required by policy;
• If it does not comply, the resource must be rejected or routed to a separate approval process.

For example, if the manifest specifies the image registry.example.com/app@sha256:..., the controller checks whether that digest has a signature from the expected release process. It can then verify that an SBOM attestation and build information exist for the same digest. If the image was signed by a different workflow, has no SBOM, or is associated with a different digest, creation of the Pod, Deployment, Job, or CronJob is blocked.

One additional nuance is the use of tags in manifests. If the team leaves app:1.2.3, the admission controller must resolve the tag to a digest itself and verify the immutable artifact. Otherwise, a person sees a familiar release tag, while the policy may be checking a different object from the one that will actually be pulled and run.

After the admission policy is enabled, the chain becomes complete. CI builds the image, publishes it, creates the SBOM and attestations, signs the digest, and Kubernetes allows only the artifact that complies with the rules to run. What remains is to honestly examine the boundaries of this scheme: which risks it reduces, and which still require separate protection for CI/CD, the registry, dependencies, and the cluster itself.

Which risks SBOMs and signatures cover—and which they don’t

Where this combination really helps

The main benefit is that the team stops trusting an image based only on its name. Instead of app:1.2.3, there is a verifiable artifact: a digest, its composition, a signature, and build information.

This benefit can be broken down by specific risks: one mechanism shows the composition, another verifies integrity, a third ties the evidence to the image, and an admission policy makes verification a prerequisite for running it.

These tools do not “fix” an artifact; they make it verifiable. During a release or an investigation, the team sees not just an image name, but a specific digest, its composition, a signature, and the build provenance.

However, artifact verifiability is not the same as complete security. The next step is to separate the limitations of the image itself from the risks surrounding the build process, the registry, and Kubernetes.

Limitations of the image itself

An SBOM shows which packages and versions are present in an image, but it does not update them automatically. It also does not always prove whether a specific vulnerability is reachable in the application. This is why vulnerability scanning, CVE prioritization, dependency updates, and a policy for critical findings are also needed.

An SBOM also does not guarantee that a dependency is safe in practice. It can identify a package, but it will not always reveal malicious behavior, especially if the vulnerability has not yet been documented in public databases. This requires dependency reviews, version pinning, control over package sources, and reputation checks.

A signature also does not mean that the code inside is correct. It confirms the artifact’s origin and integrity, but it does not validate the application’s business logic. Authorization flaws, unsafe data-processing flows, and logic bugs remain the responsibility of code review, testing, SAST/DAST, threat modeling, and secure development practices.

Even if the image itself can be verified, there is still the environment that produces, stores, and runs it.

Risks Around the Build, Registry, and Kubernetes

The key point here is to look not at the artifact itself, but at the process surrounding it:

• CI/CD. If an attacker gains control of an approved release process, they can build and sign a malicious image with the “correct” identity. Protected branches and tags, approvals, least privilege, runner isolation, and short-lived secrets are required.
  
• Registry. A signature helps detect an unsigned or unauthorized image, but it does not eliminate the risks of image deletion, tag overwrites, or publishing junk. Minimum privileges, immutable tags, action auditing, and separate delete permissions are required.
  
• Kubernetes. A signed image can still be dangerous in a poorly configured cluster. If a workload has been granted excessive privileges, or if there are no network restrictions or runtime protection, Pod Security Standards, network policies, capability restrictions, seccomp/AppArmor, and behavior monitoring are required.

The conclusion can be stated as follows: SBOM, Cosign, Sigstore, and admission policy increase trust in a container artifact, but they do not automatically make the entire process secure. They cover an important part of the chain: composition, publisher, provenance, and admission to run. The remaining risks require separate controls around CI/CD, the registry, dependencies, Kubernetes, and the application itself.

How to interpret the four key risks in practice

After reviewing the overall risk map, it is useful to examine several scenarios separately. This makes it easier to understand where an SBOM and a signature genuinely help, and where they provide only part of the picture.

Vulnerable dependencies

An SBOM helps quickly answer the question: “Where are we using package X version Y?” This is especially important during large-scale incidents involving popular libraries. Without a software bill of materials, teams often start with a manual search across repositories, Dockerfiles, and images. With an SBOM, they can more quickly determine which images contain the vulnerable component, which are already running in production, and which are associated with critical services.

However, an SBOM does not fix the dependency on its own. It also does not always show whether the vulnerable code is reachable in a specific application. The workflow therefore looks like this: the SBOM provides the component inventory, the scanner checks it against vulnerability databases, the team prioritizes fixes, and a policy can block the deployment of images with critical vulnerabilities that exceed the agreed threshold.

Image substitution

Image substitution is a situation where the artifact that ends up in the cluster is not the one the team expected. For example, the app:1.2.3 tag was overwritten, a different image was published to the registry, or someone attempted to use a similar name from another project.

Here, the combination of the digest, signatures, and admission policies acts as a strict control. The system checks not a familiar string in the manifest, but the specific digest and a signature from the expected identity. If the image has been substituted, the digest will change. If the image was not signed by the required process, Kubernetes should not allow it to run.

Unsigned Image

An unsigned image must be treated as untrusted by default. It is important to formulate the rule exactly this way: not “if a signature is present, that is good,” but “if there is no signature, running it is prohibited.” Otherwise, the signature remains attractive metadata for disciplined releases, but does not become a real enforcement barrier.

In practice, this means the admission policy must block a Pod, Deployment, CronJob, or Job that uses an unsigned image. The same applies to an image signed by the wrong process, for example, a test workflow instead of a release workflow.

CI/CD Compromise

CI/CD compromise is the most difficult scenario, because SBOMs and signatures provide only partial protection here. If an attacker gains access to an authorized release process, they can build a malicious image, generate an SBOM, sign the artifact, and pass the admission check with a “valid” identity.

This does not make signatures useless. They help determine which process released the artifact and narrow the scope of the investigation. But prevention requires separate controls: protected branches and tags, mandatory approvals, isolated runners, least-privilege tokens, prohibiting arbitrary changes to release workflows without review, short-lived secrets, and activity auditing.

These four scenarios illustrate the key takeaway: SBOMs, signatures, and admission checks increase trust in an artifact, but they do not replace the broader security control environment. This is why it is better to start implementation with a practical minimum set of rules that quickly reduces the most obvious risks and does not require building an ideal supply-chain model from the outset.

Minimum Rule Set for Implementation

Rules for the artifact

First, the container image itself must be made verifiable:

1. Do not run production images without a digest. The tag can be retained for human convenience, but the policy must verify the immutable artifact.
   
2. Sign the image after publishing it to the registry. You need to sign the object that Kubernetes will later pull, not the local intermediate build.
   
3. Create an SBOM for each release image. It is better to do this automatically in CI and link the bill of materials to a specific digest via attestation.
   
4. Verify the signer's identity. What matters is not only that a signature exists, but also who created it: the expected release process, the correct repository, branch, or service account.

After these steps, the image has a verifiable “passport”: its digest, contents, signature, and provenance information. But this passport should not simply sit alongside the release; it must actually affect whether the image is run.

Rules for admission and the process

The second level is to make verification mandatory and protect the process that produces the image:

1. Block unsigned and unverified images at the admission level. If verification remains a manual command before release, it will eventually be bypassed.
   
2. Secure CI/CD separately. Artifact signing is not a substitute for securing the process that creates those artifacts. Protected branches and tags, reviews of release scripts, least privilege, short-lived secrets, and action auditing are required.

This minimum closes the main gap: Kubernetes stops accepting “just images from a registry.” Every production image must have a digest, composition information, a signature, provenance information, and pass automated verification before it is run.

Conclusion

SBOM, Cosign, Sigstore, and Kubernetes admission policies are not needed as a “security checkbox,” but to make container artifacts verifiable. The team must understand exactly what is running, what the image was built from, who released it, and why that artifact was admitted to the cluster.

A working model is built around the digest: the software bill of materials, signature, build information, and admission rules are all tied to it. But this model should not be overestimated. It reduces the risks of image substitution, unsigned builds, and lack of visibility into dependencies, but it does not replace protection for CI/CD, the registry, Kubernetes, or the application itself.

FAQ

Do we need an SBOM if we already scan images for vulnerabilities?

Yes. Scanning helps identify known vulnerabilities, but an SBOM is useful as a standalone inventory of components. It can be stored, signed, shared with customers, and used during an incident when you need to quickly determine which images contain a specific library or package version.

Does a Cosign signature guarantee that an image is secure?

No. A signature confirms that a specific artifact was signed by the expected identity and has not been changed since it was signed. It does not prove the absence of vulnerabilities, malicious logic, configuration errors, or issues in the application's business logic.

Why can’t you just sign the tag?

Because a tag can be reused or overwritten. It is more reliable to bind the signature, SBOM, and attestation to the digest: it points to the specific contents of the image. If the digest changes, it is a different object to verify, even if the tag looks the same.

What should be done with images from third-party vendors?

They also need to be checked for the presence of a signature, an SBOM, provenance information, the vendor’s reputation, and compliance with internal policies. If the vendor does not publish an SBOM or signatures, the organization must decide separately whether it accepts that risk and what compensating controls are required.

If CI is compromised, is the signature useless?

Not exactly. A signature does not prevent a malicious image from being released if an attacker controls the authorized release process. However, it helps establish the artifact’s provenance and enforce strict admission policies. Preventing this scenario requires separate controls: protected branches and tags, reviews of release workflows, least privilege, isolated runners, short-lived secrets, and activity auditing.

Sources

1. Sigstore documentation

2. Cosign documentation

3. Sigstore Policy Controller

4. SLSA framework

5. SPDX specification

6. CycloneDX specification

7. Kubernetes Admission Controllers