TOPIC SECURITY
SBOM a full inventory of every software component in your application
IN 10 SECONDS
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.
GOTCHA An SBOM is only useful if it's kept up to date. A stale SBOM from last month misses newly added dependencies and recently discovered CVEs. Generate SBOMs on every build and attach them to the artifact as metadata — make it part of your CI pipeline, not a manual step.
HOW AN SBOM IS GENERATED AND USED
01 Build pipeline after `npm install` or `go mod download`, a tool (Syft, Trivy, CycloneDX plugin) generates an SBOM in SPDX or CycloneDX format.
02 Storage the SBOM is uploaded to a registry (dependency-track, Grype DB) alongside the container image or artifact.
03 Vulnerability scan the SBOM is compared against CVE databases. Each component is checked: `lodash@4.17.20` → 3 known CVEs.
04 Alert when a new CVE is published, the SBOM database is rechecked. An alert identifies exactly which images and deployments are affected.
POKE IT YOURSELF
syft packages ghcr.io/myorg/myapp:v1.2.3 -o spdx-json — generate an SBOM for a container image
grype ghcr.io/myorg/myapp:v1.2.3 — scan an image for CVEs using its SBOM
Drill this topic →
~80 sec read