SECURITY / A CONCEPT NOTE
SBOM
a full inventory of every software component in your application
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
A Software Bill of Materials (SBOM) is a nested list of all open-source and third-party components in your application — libraries, packages, container base images, their versions, and dependencies. In the event of a CVE (e.g., Log4Shell), you query your SBOM database to instantly know every service that's affected, instead of manually tracking down dependencies.
02 / FOLLOW THE MECHANISM
How an SBOM is generated and used
Build pipeline
after
npm installorgo mod download, a tool (Syft, Trivy, CycloneDX plugin) generates an SBOM in SPDX or CycloneDX format.Storage
the SBOM is uploaded to a registry (dependency-track, Grype DB) alongside the container image or artifact.
Vulnerability scan
the SBOM is compared against CVE databases. Each component is checked:
lodash@4.17.20→ 3 known CVEs.Alert
when a new CVE is published, the SBOM database is rechecked. An alert identifies exactly which images and deployments are affected.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
generate an SBOM for a container image
syft packages ghcr.io/myorg/myapp:v1.2.3 -o spdx-jsonscan an image for CVEs using its SBOM
grype ghcr.io/myorg/myapp:v1.2.305 / CHECK YOURSELF
Could you explain SBOM to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Security & identityOIDC Federationsecretless repository authentication for CI/CD actions