SBOM and Software Supply Chain Security
Software Bill of Materials and managing third-party dependencies, provenance and vulnerabilities in the software supply chain.
Quick Answer
Track every dependency in an SBOM, continuously match it against CVE/KEV data, pin and verify sources, and only then can you rapidly answer 'are we affected' when a new vulnerability is disclosed.
Definition
An SBOM is a machine-readable inventory of all components in a software artifact; using it lets an organization identify, prioritize and remediate vulnerable or malicious dependencies.
What it is
An SBOM (Software Bill of Materials) inventories every component, version and dependency of a software artifact. It is the basis for supply-chain security: you cannot secure what you cannot enumerate.
Why it matters
High-impact supply-chain incidents exploit trusted, undetected dependencies. With an SBOM you can answer “are we running the vulnerable version?” within minutes of a CVE/KEV disclosure — the difference between a patched posture and an emergency.
How it works
- Generate SBOM (CycloneDX/SPDX) at build; store and RE-verify provenance.
- Continuously match components to NVD/Kev CVE data (see
guides:tool-cve-guide). - Pin exact versions, review new/transitive deps, and watch for typosquatted or renamed packages.
Detection
- A disclosed CVE/KEV matching a dependency in your SBOM.
- An unexpected version bump or new transitive dependency in a merge.
Mitigation
- Automate SBOM generation + CVE matching in CI (see
security:devsecops). - Prefer signed, well-maintained packages; keep a dependency update cadence.
- Treat a KEV-listed vulnerable dependency as a blocking incident.
Investigation
Given a disclosed CVE, query your SBOM for affected components, confirm reachability in your code, then patch/upgrade and verify. See guides:tool-cve-guide for severity and KEV context.
References
Ask OpenTrojan's evidence-backed assistant about this topic — answers cite their sources.