Why SBOM Generation Became Non-Negotiable in 2026
The Log4Shell aftermath cost enterprises an estimated $100 million in emergency remediation. SolarWinds proved that a single poisoned dependency can compromise thousands of downstream targets. By 2026, the updated U.S. Executive Order on Cybersecurity, NIST SP 800-218 guidance, and the EU Cyber Resilience Act all require software vendors selling into regulated sectors to produce a Software Bill of Materials. SBOM generation has gone from a nice-to-have audit artifact to a hard compliance requirement — and the tools ecosystem has matured to match that demand.
If you ship software — containerized microservices, open-source libraries, firmware, or SaaS APIs — and you cannot answer the question what components are in this build? within minutes, you have a supply chain problem. This guide covers the formats, tools, and pipeline patterns you actually need, including concrete examples using the Microsoft sbom-tool and Snyk SBOM generation capabilities.
SBOM Formats: SPDX vs. CycloneDX
There are two dominant SBOM formats. SPDX (Software Package Data Exchange), now at version 2.3, is the ISO/IEC 5962:2021 standard. CycloneDX, maintained by OWASP, reached version 1.6 in mid-2026. Both serialize to JSON, XML, and tag-value text. Both carry license data, package identifiers (PURL, CPE), relationships, and vulnerability references.
The practical difference comes down to your use case. CycloneDX has better native support for Vulnerability Exploitability eXchange (VEX) data and fits more naturally into CI/CD-oriented pipelines. SPDX has stronger traction in the U.S. federal supply chain space and is what NTIA minimum-element guidance references. If your customers are U.S. government contractors, default to SPDX. If you are integrating with Dependency-Track or building a modern DevSecOps workflow, CycloneDX wins on tooling ergonomics.
SPDX SBOM Generator Options
For pure SPDX output, the official spdx-sbom-generator CLI supports Go, Java (Maven and Gradle), Node.js, Python, Ruby, Rust, PHP, and .NET. It walks a dependency manifest such as go.sum, package-lock.json, or requirements.txt and emits a compliant SPDX document. Installation is a single binary download with no daemon required. It integrates cleanly with GitHub Actions and GitLab CI. One caveat: it only covers manifest-declared dependencies, not transitive dependencies discovered at runtime or embedded in container layers. That is where container-aware tools come in.
The Microsoft SBOM Tool: What It Actually Does
Microsoft open-sourced their internal SBOM toolchain in 2022 under the microsoft/sbom-tool repository. By 2026 it is a mature, production-grade CLI used across Azure DevOps pipelines and GitHub Actions workflows. It generates SPDX 2.2-compliant documents and is the tool Microsoft themselves use to produce SBOMs for Windows, Azure, and Microsoft 365 components.
Microsoft SBOM Tool Example: Basic Usage
Here is a minimal example for a Node.js project. After installing via dotnet tool install --global Microsoft.Sbom.DotnetTool, you run the following command:
sbom-tool generate -b ./build-output -bc ./src -pn MyService -pv 1.4.2 -ps MyOrg -nsb https://myorg.com/sbom
The flags break down as follows. The -b flag is the build drop path where compiled artifacts live. The -bc flag is the source component path the tool scans for package manifests. The -pn and -pv flags set package name and version. The -ps flag sets the package supplier, and -nsb sets the namespace base URI for SPDX document identification. Output lands in _manifest/spdx_2.2/manifest.spdx.json alongside a SHA256 manifest hash file.
What makes the Microsoft SBOM tool distinctive is its multi-ecosystem detection. It parses NuGet, npm, PyPI, Maven, Gradle, Go modules, CocoaPods, and Ruby Gems in a single pass. It also detects components via component detection libraries that Microsoft developed, so it catches packages that are not in a lockfile but are present as compiled DLLs or installed gems. That is meaningful coverage lift over manifest-only tools.
Microsoft SBOM Tool in GitHub Actions
A production GitHub Actions integration looks like this in your workflow YAML. Add a step after your build step that installs the tool and generates the SBOM, then upload the manifest directory as a workflow artifact. The output gives you a tamper-evident supply chain record for every build. Pair this with SLSA provenance attestation using slsa-github-generator and you are meeting SLSA Level 2 requirements, which NIST SP 800-218A now explicitly recommends for critical software.
Snyk SBOM Generation: Developer-First with Vulnerability Context
Snyk SBOM generation, available through the Snyk CLI and API since late 2024, generates CycloneDX or SPDX documents enriched with Snyk's vulnerability database. This is the key differentiator: most SBOM tools produce a component inventory. Snyk produces a component inventory plus known CVEs, exploitability data, and fix availability, all inline in the same document.
To generate an SBOM with the Snyk CLI, run snyk sbom --format=cyclonedx1.4+json --file=package.json and redirect the output to a JSON file. The output is a CycloneDX 1.4 document — with version 1.6 support landing in the 2026 Q1 CLI release — containing vulnerability annotations in the vulnerabilities component array. You can also target a container image directly using snyk container sbom --format=spdx2.3+json myregistry/myimage:1.2.3, which combines manifest scanning with layer analysis.
Snyk SBOM generation integrates naturally into vulnerability management workflows. You are not just tracking what is in your software — you are tracking what is exploitable right now. That is the shift-left argument in concrete form.
Other Noteworthy SBOM Generators in 2026
Syft by Anchore
Syft is the most widely adopted open-source SBOM generator for containers. Running syft myimage:latest -o spdx-json gives you an SPDX document covering OS packages (APK, RPM, DEB), language packages from embedded manifests, and binary classification via pattern matching. Pair it with Grype for vulnerability correlation and you have a self-contained supply chain scanning pipeline. Our container image scanning capabilities build on exactly this kind of layered approach.
Trivy by Aqua Security
Trivy deserves mention not just as a vulnerability scanner but as a full SBOM generator. Running trivy image --format spdx-json --output sbom.json myimage:tag produces SPDX output covering OS and language components. Trivy SBOM generation also supports OCI artifact attestation: push the SBOM as an OCI manifest alongside the image, then verify it at admission control. That is supply chain security at the registry layer, not just at build time.
cdxgen for Polyglot Monorepos
For polyglot monorepos, cdxgen is hard to beat. It auto-detects build systems across more than 20 ecosystems, generates CycloneDX 1.6 output, and has first-class support for container builds, Kubernetes manifests, and Terraform configurations. The --deep flag triggers full transitive dependency resolution, giving you complete blast-radius visibility.
Integrating SBOM Generation into Your DevSecOps Pipeline
Generating an SBOM once and filing it somewhere is theater. The value is in continuous SBOM generation tied to every build, every container push, and every release, so that when a new CVE drops you can query your SBOM store and know within minutes which services are affected.
A production-grade pipeline works like this. A source code commit triggers CI. The SBOM is generated at build time, not scan time. It is signed with Sigstore and cosign, pushed to a storage backend such as Dependency-Track or a custom object storage bucket, and indexed for querying. When a critical vulnerability hits, your incident response workflow queries the index and returns a hit list in seconds, not days.
This kind of pipeline hygiene is central to a mature code security posture. Static analysis catches vulnerabilities in your own code. SBOM generation surfaces risk in your dependencies. Both are required. Neither alone is sufficient.
For teams running Kubernetes-based workloads, coupling SBOM generation with your SAST pipeline creates a two-layer defense. You catch insecure code patterns before merge, and you track vulnerable dependencies across all running images. The combination dramatically reduces the window between vulnerability disclosure and remediation.
SBOM Generation for Compliance: What Auditors Actually Want
EU Cyber Resilience Act Article 13 requires manufacturers of products with digital elements to produce SBOMs covering all incorporated components. NIST SP 800-218 Secure Software Development Framework 1.1 maps SBOM production to the PW.4 practice area. The 2026 revision of U.S. FDA guidance for medical device software mandates SBOM submission as part of premarket notification.
What do auditors actually want to see? At minimum, NTIA's seven minimum elements: author, timestamp, supplier name, component name, version, unique identifier (PURL or CPE), and dependency relationships. Beyond that, auditors increasingly ask for VEX documents alongside the SBOM — a machine-readable attestation of which vulnerabilities are exploitable in your specific configuration. Snyk SBOM generation natively produces this context. For pure SPDX or CycloneDX toolchains, you will need to layer in a separate VEX tool like vexctl or OpenVEX.
The compliance angle on SBOMs is real and growing. If you are pursuing SOC 2 Type II, ISO 27001:2022, or NIS2 compliance, documented software composition practices are increasingly part of assessor evidence packages. An automated SBOM pipeline is the difference between scrambling to produce documentation before an audit and pulling a pre-signed artifact from your CI history.
SBOM Storage, Signing, and Distribution
Generating the SBOM is only step one. You need to store it, sign it, and make it discoverable. Three patterns dominate in 2026.
OCI Artifact Attachment means pushing the SBOM as an OCI referrer manifest alongside the container image using cosign attach or oras attach. The SBOM travels with the image and can be verified at admission control using policy engines like Kyverno or OPA Gatekeeper. This pattern requires no external storage dependency.
Dependency-Track is the OWASP open-source continuous SBOM analysis platform. Ingest CycloneDX documents, get real-time vulnerability tracking as NVD and GitHub Advisory data updates, policy violation alerts, and a REST API for integration. It is free, self-hosted, and the de-facto standard for organizations wanting full control over their SBOM data.
Commercial SBOM Management platforms integrate SBOM ingestion into broader security posture management workflows. SECRAILS lets you correlate SBOM data with cloud inventory, runtime behavior, and policy checks in a single interface, eliminating the need to pivot between disconnected tools.
Signing matters enormously. An unsigned SBOM is a text file anyone could modify. Use Sigstore cosign to attach a keyless signature to every SBOM you generate. It ties the signature to your CI identity via OIDC, creating an auditable attestation chain without managing long-lived signing keys. This is the pattern the OpenSSF SLSA framework recommends, and it is increasingly what security-conscious customers will ask to verify before accepting your software.
Common Mistakes That Undermine SBOM Quality
Several failure modes keep appearing in SBOM generation implementations. The first is scanning source manifests only. Package managers can lie: a lockfile might not reflect what is actually installed in a Docker image if layers were modified post-build. Always scan the final build artifact or image, not just the source tree.
The second mistake is ignoring transitive dependencies. Direct dependencies are the easy part. The blast radius of a vulnerability like Log4Shell came almost entirely from transitive inclusion. Tools that do not resolve the full dependency graph give you false confidence.
The third mistake is generating SBOMs at scan time rather than build time. If your SBOM does not match what was actually compiled and shipped, it is noise rather than signal. The fourth — and often overlooked — mistake is not keeping SBOMs up to date. An SBOM for version 1.0.0 is useless when you are running 1.4.7 in production. Every build, every image push, and every release must trigger a fresh SBOM. Automate it or it drifts. Pair your SBOM pipeline with VM scans for runtime environments to close the loop between what was shipped and what is actually running.
The Road Ahead: SBOMs as Living Security Artifacts
The next evolution is not just generating SBOMs but making them queryable, comparable, and actionable across your entire fleet. Imagine a security team asking which services run a specific vulnerable library across all environments and getting results in under five seconds. That is achievable today with Dependency-Track paired with a well-structured SBOM pipeline. It is what mature organizations are building toward.
The tooling is there. The formats are stable. The regulatory pressure is real. What is missing at most organizations is the operational discipline to generate, store, sign, and query SBOMs at scale — and that is an engineering problem, not a tooling one. The organizations that solve it in 2026 will enter the next wave of supply chain attacks in a fundamentally stronger position than those who treat SBOMs as a compliance checkbox.