SBOM — Software Bill of Materials for supply chain

An SBOM (Software Bill of Materials) is a structured list of components in an image: the base image, the packages, the libraries, the transitive dependencies. The SBOM is the inventory that supports vulnerability management, license compliance, and supply chain attestation. This lesson covers the standards, the generation tools, the signing workflow, and the admission integration.

The SBOM standards

Two standards dominate:

Both standards list the same kind of information: the package name, version, supplier, license, and hash. The differences are in the schema and the tooling.

flowchart LR
    A[Image] --> B[SBOM generator]
    B -->|SPDX| C[SPDX document]
    B -->|CycloneDX| D[CycloneDX document]
    C --> E[Sign with Cosign]
    D --> E
    E --> F[Store in registry]

A production cluster typically generates both SPDX (for compliance) and CycloneDX (for security).

Generating an SBOM

Two tools dominate:

1. Syft — the de-facto standard. Generates SPDX and CycloneDX from images, filesystems, and archives.

# Generate SPDX
syft myapp:v1.0 -o spdx-json > myapp.spdx.json

# Generate CycloneDX
syft myapp:v1.0 -o cyclonedx-json > myapp.cdx.json

2. Trivy — a vulnerability scanner that also generates SBOMs.

trivy image --format spdx-json --output myapp.spdx.json myapp:v1.0
trivy image --format cyclonedx-json --output myapp.cdx.json myapp:v1.0

Both tools inspect the image’s filesystem, identify packages by their package manager metadata, and produce the SBOM.

Signing the SBOM with Cosign

The SBOM is signed with Cosign and stored in the registry as an OCI artifact:

# Generate the SBOM
syft myapp:v1.0 -o spdx-json > myapp.spdx.json

# Attach the SBOM to the image
cosign attach sbom --sbom myapp.spdx.json myapp:v1.0

# Sign the SBOM
cosign sign-blob --key cosign.key myapp.spdx.json > myapp.spdx.json.sig
cosign attach signature --signature myapp.spdx.json.sig myapp:v1.0

The signed SBOM is now in the registry alongside the image. Anyone with the public key can verify the signature.

Verifying the SBOM at admission

A validating webhook (Kyverno, Cosign verifier) checks that the image has a signed SBOM:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-sbom
spec:
  validationFailureAction: Enforce
  rules:
  - name: require-sbom
    match:
      resources:
        kinds: ["Pod"]
    verifyImages:
    - imageReferences:
      - "registry.example.com/*"
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              ...
              -----END PUBLIC KEY-----
        type: sbom

The policy rejects any Pod whose image does not have a signed SBOM. The CI pipeline fails on the policy violation.

sequenceDiagram
    participant CI
    participant Registry
    participant Kyverno
    CI->>Registry: Push image + SBOM + signature
    Kyverno->>Registry: Fetch SBOM + signature
    Kyverno->>Kyverno: Verify signature
    Kyverno->>CI: Allow or reject

Production patterns

1. Generate SBOMs in CI. Every image build produces both SPDX and CycloneDX.
2. Sign and attach SBOMs. Cosign signs the SBOM and stores it in the registry.
3. Verify at admission. Kyverno or Cosign verifier checks the SBOM signature.
4. Use the SBOM for vulnerability management. The SBOM is the input to Grype, Trivy, or Dependency-Track.

Production failure modes

1. No SBOM generated. The image is deployed without an inventory. The fix is to add SBOM generation to the CI pipeline.
2. SBOM is unsigned. Anyone can replace the SBOM. The fix is to sign with Cosign.
3. SBOM is outdated. The image was updated but the SBOM is stale. The fix is to regenerate the SBOM on every build.
4. No admission check. Pods without SBOMs are admitted. The fix is to enforce the policy at admission.

Cross-course references

• The Linux course covers the package managers that SBOM generators inspect.
• The Observability course covers the audit log entries for SBOM verification.

Quiz

Production discipline

An SBOM is the inventory that supports vulnerability management, license compliance, and supply chain attestation. A defensible SBOM programme generates SBOMs in CI for every image, signs them with Cosign, stores them in the registry alongside the image, and verifies the signature at admission. A cluster whose images all have signed SBOMs has a supply chain programme that is auditable; a cluster whose images have no SBOMs or unsigned SBOMs has a programme that is not.