Verifiable trust in containers: SBOM, VEX, SLSA, and attestations

Container security has matured significantly over recent years. The introduction of SBOM has consolidated the notion that you cannot secure what you do not know structurally. Inventories have ceased to be a bureaucratic artifact and have become a central element of modern engineering. 

However, composition does not equal trust. An artifact can have its list of dependencies perfectly documented and still have been built in a compromised environment, outside of the standard process, or by an unauthorized identity. 

The current challenge in supply chain security is not just knowing what makes up a container, but demonstrating, with verifiable evidence, that it was produced with integrity, traceability, and under appropriate controls. Trust, in this context, cannot be implicit. It must be cryptographically demonstrable. This is where attestations, the notion of provenance, the role of VEX, and the maturity levels defined by SLSA come into play.

SBOM as a starting point, not a destination

SBOM establishes a structured representation of an artifact's composition. It describes libraries, operating system packages, frameworks, dependency relationships, versions, and licenses. By being generated during the build and stored as a versioned artifact, it allows for later correlation with vulnerability databases without the need to re-scan the binary. 

However, an isolated SBOM is just a declarative document. Nothing prevents someone from generating an SBOM that does not correspond to the distributed artifact. Nothing prevents the image from being modified after the inventory has been generated. For the SBOM to participate in a trust model, it must be linked to the image digest and signed. This binding transforms the SBOM into an attestation of composition.

Suppose an image is published to a registry:

$ registry.example.com/app/backend:1.4.2

The first step is to identify its immutable digest:

$ docker pull registry.example.com/app/backend:1.4.2

$ docker inspect --format='{{index .RepoDigests 0}}' registry.example.com/app/backend:1.4.2

The result will look something like:

$ registry.ex

This digest is the cryptographic anchor upon which attestations will be built. If the SBOM was generated in CycloneDX format, for example sbom.json, it can be associated with the artifact using cosign:

$ cosign attest  --predicate sbom.json  --type cyclonedx \ registry.example.com/app/backend@sha256:abc123

This command creates an attestation whose subject is the image digest and whose predicate contains the SBOM. The attestation is signed with the key configured in the environment. From that moment on, the SBOM ceases to be just an inventory and becomes evidence cryptographically linked to the artifact.

Attestations as an evidence model

An attestation is a signed statement about an explicit artifact. It associates three fundamental elements: 

1. the artifact's digest;

2. a statement type;

3. the content of that statement. 

The standard widely used in the cloud native ecosystem derives from the in-toto model, which defines how to represent these links in a structured and verifiable way. The advantage of this model is the separation between binary and metadata. An image can have multiple independent attestations. One can describe its composition, another can describe its provenance, another can declare the SLSA level achieved, and another can contain VEX information. This modularity allows the trust architecture to evolve without modifying the executable artifact.