Generating Software Bill of Materials (SBOMs) with Snyk is surprisingly easy once you understand how Snyk views your project’s dependencies.
Let’s see Snyk in action generating an SBOM. Imagine you have a Node.js project with a package.json and package-lock.json. You’ve already installed Snyk CLI and authenticated it with your account (snyk auth).
Here’s how you’d generate a CycloneDX SBOM in JSON format:
snyk sbom --format=cyclonedx --output-format=json > bom.json
And here’s the equivalent for SPDX in JSON format:
snyk sbom --format=spdx --output-format=json > bom.spdx.json
You can also generate these in YAML:
snyk sbom --format=cyclonedx --output-format=yaml > bom.yaml
snyk sbom --format=spdx --output-format=yaml > bom.spdx.yaml
Snyk’s sbom command, when run in your project directory, does the heavy lifting. It first identifies your project’s language and build tools (like npm, Maven, Gradle, Pip, etc.). Then, it uses these tools’ native mechanisms to enumerate the direct and transitive dependencies. For example, with npm, it reads your package-lock.json to get the precise versions of every installed package. Snyk then enriches this dependency list with vulnerability data from its own vulnerability database. The SBOM generation process essentially takes this comprehensive dependency tree and formats it according to the chosen SBOM standard (CycloneDX or SPDX).
The core problem an SBOM solves is providing a clear, structured inventory of all software components and their versions within an application. This is crucial for security, license compliance, and supply chain risk management. Snyk, by integrating this SBOM generation directly into its workflow, allows you to not only see what’s in your software but also to immediately understand its security posture.
When you run snyk sbom, Snyk’s CLI inspects your project. It looks for manifest files (like package.json, pom.xml, build.gradle, requirements.txt, etc.) and lock files (like package-lock.json, yarn.lock, Pipfile.lock). Based on these, it determines the project type and invokes the appropriate package manager to build a complete dependency tree. This tree includes not just your direct dependencies but also all their transitive dependencies, down to the deepest levels. Snyk then cross-references these identified components against its vast vulnerability database, flagging any known security issues. Finally, it serializes this enriched dependency information into the chosen SBOM format, adhering to the specifications of CycloneDX or SPDX.
The output-format flag dictates the serialization format (JSON or YAML), while the format flag selects the SBOM standard itself (cyclonedx or spdx). Snyk supports both standards because they offer different perspectives and data models. CycloneDX is generally more modern and component-centric, whereas SPDX is a broader standard that can also describe licenses and other metadata beyond just software components. Snyk aims to provide flexibility by supporting both, allowing teams to choose the standard that best fits their existing tooling and processes.
What most people don’t realize is that Snyk’s SBOM generation is tightly coupled with its vulnerability scanning. When you run snyk sbom, Snyk isn’t just listing packages; it’s also implicitly gathering the data that would be presented in a snyk test or snyk iac test command. This means the SBOM you generate is already "security-aware," containing information about known vulnerabilities associated with each component, if any exist. You can then use this SBOM with other tools that understand these formats to perform further analysis or reporting.
The next logical step after generating an SBOM is to analyze it for known vulnerabilities and license compliance issues using dedicated SBOM analysis tools or by feeding it back into Snyk’s platform for deeper insights.