Snyk SBOM generation works by running its existing dependency-resolution engine against a project's manifests and lockfiles, then exporting the resulting dependency graph in a standard bill-of-materials format — typically CycloneDX or SPDX. It's the same underlying data Snyk uses for vulnerability matching, repackaged into a portable document a customer, auditor, or downstream consumer can read without access to your Snyk account. That reuse is both the feature's strength (it's accurate to what Snyk actually scanned) and its limitation (it only knows what the scan covered).
How does SBOM generation actually work under the hood?
The process starts with dependency resolution: the scanner parses manifest files (package.json, pom.xml, requirements.txt, go.mod, and similar) plus their lockfiles to build a full graph of direct and transitive dependencies, not just what's declared at the top level. That graph — package name, version, ecosystem, and the parent-child relationships between dependencies — is the raw material. Generating an SBOM is then a serialization step: the same graph gets written out in a structured, machine-readable format (CycloneDX JSON/XML or SPDX tag-value/JSON) that other tools can parse without needing to run their own scan. Some SBOM exports also fold in license metadata and known vulnerabilities from the same scan, producing what's sometimes called an "SBOM with VEX," where the document ships alongside vulnerability exploitability statements for the same component list.
What formats does an exported SBOM actually use?
The two dominant standards are CycloneDX, originated by OWASP and now an Ecma standard, and SPDX, an ISO/IEC standard originally focused on license compliance that has expanded to cover security metadata. Most scanners, Snyk included, support exporting to both, because different downstream consumers expect different formats — a federal contract may require SPDX to satisfy NTIA minimum elements, while an internal supply-chain tool might consume CycloneDX because it more naturally represents vulnerability and dependency-tree data. If you're building your own sbom examples for internal tooling, picking the format your downstream consumers already parse saves you a conversion step later.
What does a generated SBOM actually contain?
A useful SBOM template includes, at minimum: component name, version, and package URL (purl) for every direct and transitive dependency; the license each component is distributed under; a unique identifier for cross-referencing; and ideally a relationship graph showing which components depend on which. Vulnerability-aware exports add known CVEs mapped to specific component versions. What it typically does not contain: anything about code your own team wrote (an SBOM documents third-party components, not your application logic), and it won't tell you whether a listed vulnerability is actually reachable from your code — that requires a separate reachability analysis layered on top of the raw component list.
Where do SBOM generation tools fall short?
They're only as complete as the manifest and build system they can parse. A monorepo with an unusual build tool, a vendored dependency that was manually copied into the tree instead of declared in a manifest, or a native binary pulled in outside the package manager can all end up invisible to a manifest-based scan — which means they're also invisible in the resulting SBOM, even though they're very much present in the shipped artifact. Container-image SBOMs face a similar gap: scanning the final image catches OS packages and installed libraries, but a statically-linked binary built from source inside the image can hide dependencies that never touch a package manager. This is why an SBOM is a strong baseline for supply-chain visibility but not, by itself, a substitute for a scan that also checks reachability and runtime behavior — see how SCA tooling fits alongside SBOM generation in a fuller pipeline.
Why does SBOM generation matter beyond compliance checkboxes?
Because an SBOM turns "what's in this build" from a forensic exercise into a lookup. When a new critical CVE drops in a widely used library (the way Log4Shell did in 2021), teams with SBOMs on file for prior releases can grep a known component list instead of re-scanning every historical artifact under pressure. That's the actual operational payoff — the compliance requirement (NTIA minimum elements, executive orders on software supply chain security) is what forced adoption, but the incident-response speed is what keeps teams generating them once the mandate isn't the only reason.
FAQ
Is a Snyk SBOM the same as a Snyk vulnerability report?
No. A vulnerability report lists known CVEs matched against your dependencies. An SBOM is the underlying component inventory — every dependency, its version, and its license — with or without vulnerability data layered on top.
Which SBOM format should you generate first?
Generate both if your tooling supports it cheaply, since they're derived from the same dependency graph. If you have to pick one, match what your primary downstream consumer (a customer's procurement team, a compliance auditor) already expects.
Do SBOMs need to be regenerated on every build?
Yes, ideally. Dependencies change between builds, and an SBOM tied to a specific build artifact (referenced by build ID or image digest) is far more useful during an incident than a generic "as of last month" snapshot.
Can an SBOM alone tell you if you're actually vulnerable to a new CVE?
It tells you if the affected component is present. Whether you're exploitable depends on whether your code actually calls the vulnerable function — reachability analysis, not the SBOM itself, answers that question.