Skip to main content

Container SBOM and Runtime Traceability

🌟 Objective​

Ensure that all container images used in pipelines or production have an SBOM (Software Bill of Materials) generated from the real artefact, versioned and traceable, enabling:

  • Objective visibility of components, libraries and layers;
  • Vulnerability analysis based on the actual content of the image;
  • Comparison between versions and detection of unexpected changes;
  • Support for regulatory requirements (e.g. SLSA, SSDF, EO 14028).

In the SbD-ToE model, the SBOM is treated as evidence of composition, not as a guarantee of security nor as a substitute for risk analysis.

🧬 What a container SBOM is​

A container SBOM represents the effective state of the image after the build, including:

  • Installed packages (e.g. apk, apt, npm, pip);
  • Transitive dependencies;
  • Origin and licensing information;
  • Hashes, locations and metadata;
  • Known links to CVEs.

🧱 An SBOM is not equivalent to a Dockerfile, lockfile or declarative manifest.
It describes what is actually present, including side effects of the build process.

⚠️ Complete SBOM ≠ absence of risk​

In automated environments, it is essential to avoid incorrect interpretations:

  • ✔️ Existing SBOM → visible composition
  • ❌ Existing SBOM ≠ secure image
  • ❌ SBOM without CVEs ≠ non-existent risk

Typical limitations include:

  • undetected dependencies;
  • static binaries;
  • manually embedded components;
  • differences between build environments.

For that reason, the SBOM must be used as a technical input for analysis, not as a conclusion.

📘 Recommended formats and tools​

FormatSupported toolsTechnical observations
CycloneDXSyft, Trivy, Docker SBOM, GitHubLightweight, extensible, suited to pipelines
SPDXSPDX tools, FOSSologyCommon in formal audits
Syft JSONSyft (syft image:tag -o json)Useful for custom validations

🌟 SbD-ToE recommendation: CycloneDX JSON as the base format for container image SBOMs.

🛠️ How to generate container SBOMs​

StageTechnical exampleOperational notes
Post-build generationsyft docker:app:tag -o cyclonedx-jsonMust reflect the final image
Alternative generationtrivy image --format cyclonedx image:tagMay enrich with CVEs
CI/CD integrationMandatory step after buildAutomatic execution
VersioningArtefact associated with the image digestUnambiguous correlation

Automatic generation does not eliminate the need for human interpretation of the results.

📂 Storage, versioning and correlation​

To ensure real traceability:

  • Store the SBOM as a versioned artefact;
  • Explicitly associate:
    • image (digest),
    • build,
    • pipeline;
  • Reference the SBOM via labels or OCI metadata;
  • Optionally sign the SBOM or link it to the image signature.

The absence of this correlation reduces the SBOM to an informational file with no auditable value.

🔍 Correct use of the SBOM​

In SbD-ToE, the SBOM must be used to:

  • Feed SCA scanners and analysis processes;
  • Detect unexpected changes between builds;
  • Support incident response;
  • Justify acceptance or mitigation decisions.

It must not be used as:

  • a seal of approval;
  • a substitute for contextual analysis;
  • proof of the absence of vulnerabilities.

✅ Good practices​

  • Generate the SBOM automatically after each build;
  • Treat the SBOM as a versioned artefact;
  • Review the SBOM after base image changes;
  • Correlate the SBOM with signature and provenance;
  • Use the SBOM as input to documented human decision;
  • Review analysis criteria after relevant incidents.

📎 Cross-references​

DocumentRelation to container SBOM
01-imagens-base.mdApproved images must have an associated SBOM
03-assinatura-cadeia-trust.mdLink between integrity and composition
07-vulnerabilidades-imagens.mdSCA analysis based on the SBOM
09-riscos-processo-imagens.mdSBOM as evidence, not decision
15-aplicacao-lifecycle.mdOperational integration into the lifecycle

🔍 The SBOM answers the question “what is here?”.
The question “is this acceptable?” still requires human analysis and decision.