Software Bill Of Materials (SBOMs) are becoming increasingly important, and even a critical requirement if you’re aUS government vendor or a medical device manufacturer. This is for a number of reasons, but one of the primary benefits SBOMs provide is observability.
Observability enables organizations to understand and gain insight into the open source components their software uses. For example:
- Which open source components are included in the software
- Which components contain known vulnerabilities
- Which vulnerable components are not actually exploitable
- Which components are out of date
- Which components contain licenses that do not comply with corporate guidelines
- Provenance (i.e., source) information for each component
- How each component relates to each other, etc
Recall that a Software Bill Of Materials (SBOMs) is a list of ingredients required to build and run your software application, along with all the relevant metadata about those ingredients:
- A complete list of software supply chain dependencies, including all transitive dependencies.
- Details about each open source and commercial software component, such as the author/vendor, software license, release version, etc.
SBOMs are packaged in a machine-readable format that can enable organizations to automate their consumption, as well as integrate them within their existing processes. But not all SBOMs are created equal. There are currently three leading candidates:
- Software Package Data eXchange (SPDX)
- CycloneDX
- SoftWare IDentification tags (SWID)
The following table compares the key features of SPDX, CycloneDX and SWID SBOMs:
| Feature | SPDX | CycloneDX | SWID |
| First released | 2011 | 2017 | 2009 |
| SBOM metadata | Author, creation date, creation tooling | Author, creation date, creation tooling | Author, creation date |
| Format | JSON, SPDX, YAML, RDF/XML, tag/value | JSON, XML | JSON, XML |
| Size | Heavyweight | Lightweight | Lightweight |
| Certification | ISO | None | ISO/ IEC |
| License | Creative Commons | Apache 2.0 | Apache 2.0 |
| Creator | Linux Foundation | OWASP | US National Institute of Standards & Technology (NIST) |
| Component metadata | |||
| Name | Y | Y | Y |
| Version | Y | Y | Y |
| Type | Y | Y | N |
| Package Level | Y | N | Y |
| File Level | Y | N | Y |
| Snippet Level | Y | N | N |
| Patch Level | N | N | Y |
| Hashes | Y | Y | Y |
| Summary License | Y | Y | N |
| Other licenses | Y | N | N |
| Annotations | Y | Y | N |
| Relationships* | Y | Y | Y |
| Provenance (source) | Y | Y | Y |
| Vulnerability disclosure | Y | Y | N |
| VEX Support | Y | Y | N |
| Copyright Information | Y | Y | N |
| External Links/ Services | Y | Y | Y |
| Extensibility | Y | Y | Y |
*How packages, files, snippets, services, etc relate to each other. For example, a relationship may explain how a package was built from its dependencies.
The SBOM specification is still evolving, making it difficult to predict the eventual winner in the (currently) three horse race. Those organizations that are looking to adopt SBOMs now, should do so according to their use case:
- Software Asset Catalog – SWID is best for this use case, since it was originally designed as a way for organizations to track software installed on their systems. It’s also the simplest format and easiest to use if all you need is a list of components.
- Software Supply Chain Transparency – large enterprises tend to gravitate to SPDX, despite (or even because of) its complexity that offers advantages when detailed licensing and package information (down to the snippet level) are required.
- Application Security – SMBs (especially those in the software industry) may prefer to work with the lighter weight CycloneDX, including it as a generation/validation requirement whenever code changes during their software development process in order to ensure no malicious code was injected.
Top 10 SBOM Vendors
Now that you know what to look for in terms of SBOM use cases and supported features, we can evaluate the offerings from some of the leading SBOM vendors.
Anchore
Anchore embraces the application security use case for SBOMs, providing a platform that ingests SBOMSs to help you track dependency changes across incremental builds and product releases, while surfacing vulnerabilities.
The platform is SBOM agnostic, supporting both SPDX and CycloneDX. Anchore’s open source Syft tool can be used to create SBOMs throughout the software development process, from developer desktops to deployed containers, and then store them in a central repository.
Anchore’s platform provides container image inspection, policy-based compliance and alerting, and the ability to integrate with CI/CD pipelines. Security checks are provided directly within developer tooling, ensuring visibility.
Capabilities:
- SBOM tracking
- Container vulnerability scanning
- CI/CD pipeline security
- Container registry scanning
- Kubernetes image scanning
Advantage: cloud native. Anchore’s SBOM-powered platform scales from developer desktops to Kubernetes clusters, providing transparency and alerting you when application compliance and security issues arise.
Scribe
Like Anchore, Scribe is focused on the application security use case, providing an SBOM-driven platform that can help ensure the integrity of your code throughout the software development lifecycle.
Scribe automatically generates shareable CycloneDX SBOMs from the Open Container Images (OCI) and Docker containers in your CI pipeline (Scribe currently supports Jenkins over Kubernetes and GitHub Actions). Scribe also provides a dashboard for insights into vulnerabilities in your containers, dependencies, pipelines, etc. In this way you can ensure source code integrity (node.js only currently), validate open source dependencies and ensure against code tampering.
Scribe follows the “hash everything, sign everything” methodology in order to track every file from its origin to the final build. You can also export your SBOM in JSON format for customers that require it.
Capabilities:
- Verify code integrity and provenance throughout the SDLC
- SBOM management and sharing
- Report on suspicious or vulnerable components
Advantage: CI integration. Too many vendors generate SBOMs, but don’t do anything with them. Scribe makes it easy to use SBOMs as a key check/balance within your CI pipeline.
Veracode
Veracode provides solutions for developers and security personnel. Their Software Composition Analysis (SCA) tool in conjunction with their SBOM API is capable of generating SBOMs in CycloneDX JSON format.
You’ll need to run a SCA scan first, and then upload the results to the API endpoint in order to generate the SBOM. The result is an inventory of all the components within your application, including third-party code and the relationships between those entities.
In this way, Veracode’s SBOM capabilities are best suited to fulfilling the Asset Catalog use case, encouraging customers to use their SCA solution to manage vulnerabilities, license compliance, etc. and use the SBOM for reference/ providing to customers.
Capabilities:
- Visibility and clarity into the datedness of open source components
- Insight into the security posture of components
- Verify license compliance
- Comply with regulations
Advantage: API-based. Simplify the integration of SBOMs within your software development process by automating the generation of SBOMs programmatically.
Synopsis
Synopsis also takes the SCA approach to generating SBOMs, starting with their Black Duck SCA tool, which can generate both SPDX and CycloneDX SBOMs. You’ll need to run a SCA scan first, but you can then generate, save and view the SBOM as a report directly within Black Duck.
Similar to Veracode, Synopsis’ SBOM capabilities fulfill the asset catalog use case, with Black Duck to be used for managing vulnerabilities, license compliance, etc. You can export Synopsis’ SBOMs to be used for reference/ providing to customers.
Capabilities:
- Identify all components in your software, not just those explicitly declared by package managers or manifest files
- Identify and track third-party and proprietary components
- Produce SBOMs for applications without the need for source code
- Match identified components to related areas of risk
- Continuously monitor identified components for newly surfaced security and operation risk
Advantage: market leadership. Because many organizations have already deployed Black Duck, SBOM generation is essentially gained “for free” as a new capability.
Apiiro
Apiiro casts a much wider net than most of the other solutions in this post, aligning with the software supply chain transparency use case. Apiiro champions what they call an “XBOM,” which is to say they leverage the extensibility of SBOMs to include infrastructure as well as application components, such as:
- Infrastructure as Code (IaC) templates
- Container images
- Pipeline components
- APIs
Apiiro consumes their own XBOM (based on CycloneDX) in order to generate a risk graph that plots components from both the software and infrastructure layers across your software development process so you can more easily identify root cause and prioritize efforts.
Capabilities:
- Secrets detection and validation
- API security testing in code
- Open source security (SCA)
- Infrastructure as code (IaC) security
- Software bill of materials (SBOM)
Advantage: extensibility. Modern software deployments that utilize IaC and containers have the most to gain from adopting Apiiro’s XBOM.
FOSSA
FOSSA is focused on the asset catalog use case, providing organizations with the ability to generate, manage and consume both SPDX and CycloneDX SBOMs. You can also use it to import and work with third-party SBOMs.
FOSSA can be integrated with your CI/CD pipeline, generating a new SBOM each time there’s a code change. They also provide a dashboard that allows you to focus on different aspects of the SBOM and better visualize its information, including:
- Visibility into vulnerabilities
- Remediation guidance (i.e, whether newer, secure versions of a component exist)
- Dependencies and deep dependencies (i.e., dependencies of dependencies)
- Licenses, denoting those that do not align with corporate guidelines
- Ability to annotate components
Capabilities:
- Utilizes multiple techniques — beyond just analyzing manifest files — to produce an audit-grade component inventory
- SBOMs can be stored/managed in a local or remote VCS (GitHub, GitLab, etc.)
- Comprehensive language and ecosystem support
- Supports a range of security, regulatory compliance and license compliance use cases
- Doesn’t require source code access
Advantage: customizability. Not only can you export the SBOM in a wide range of formats, including HTML, plain text, CSV, markdown, etc you can also choose which elements to include/exclude from the report.
Mend
Mend (formerly Whitesource) is an AppSec vendor that has recently added SBOM capabilities focused on the software asset catalog use case. Much like Veracode and Sonatype, Mend has augmented their SCA tool with the ability to generate SBOMs.
Previously, customers had to use a CLI tool to manually create an SPDX SBOM from Mend’s inventory catalog of components. Mend has replaced that solution with an API so customers can now programmatically create SBOMs within their build process.
Capabilities:
- Identify all open source libraries
- Track and document each component, including direct and transitive dependencies
- Update automatically when components change
Advantage: API-based. Simplify the integration of SBOMs within your software development process by automating the generation of SBOMs programmatically.
Snyk
Snyk focuses on vulnerability remediation from the developer’s desktop through to the cloud-based containers your software is deployed in. Snyk’s SBOM generation capabilities are focused on application security, but to take advantage you’ll need to buy into their SCA and Advisor products, as well.
You can generate both SPDX and CycloneDX SBOMs, but you’ll need to first use Snyk Open Source (their SCA tool) to build a full dependency graph from package manifests and lockfiles. You can then use snyk2spdx to convert the Snyk CLI output to SPDX format, or else use the Snyk API to fetch the package manifest and vulnerability details, which you can then convert to SPDX.
Capabilities:
- Supports both CycloneDX and SPDX
- Generate SBOMs via CLI or API
Advantage: shift left. Snyk’s CLI tooling makes SBOMs readily consumable by developers, making them aware of licensing and vulnerabilities within their development environment so they can fix them earlier in the software lifecycle.
Sonatype
Sonatype focuses on application security, providing their own scans and vulnerability analyses on millions of components daily. They also generate a safety rating denoting how likely a component is to contain a vulnerability.
To create an SBOM, you’ll need to use the Sonatype lifecycle product to run a scan and generate a report via the CLI, API or UI. The report results can then be exported as either a CycloneDX or SDPX SBOM.
Capabilities:
- Analyze all components going into an application during the build
- Gather identity, vulnerability, and legal data of found components
- Compare the data against governance policies to generate a report
- Export a report as either an SPDX or CycloneDX SBOM in JSON or XML format
Advantage: vulnerability data. Sonatype performs its own vulnerability analysis daily on millions of components, which means they can spot vulnerabilities before they’re officially reported in public databases.
ActiveState
ActiveState generates SPDX SBOMs that provide users with a complete software asset catalog for their Python, Perl, Ruby and Tcl environments. The ActiveState Platform automatically builds runtime environments securely from source code on demand, and generates an SBOM as an artifact of the process to provide insight into the software supply chain from which the environment was built.
Because ActiveState keeps a git-like snapshot of all changes made to your runtime, you can generate an SBOM for any version of your runtime on demand. Additionally, a GraphQL endpoint is available for programmatic generation of SBOMs, simplifying integration with your software development processes.
Advantage: complete dependency tree. ActiveState vendors all dependencies (including OS-native C/C++, Fortran and other low-level libraries) in order to build everything from source code. The result is an accurate and complete SBOM that includes all runtime and build time dependencies.
Conclusions – How to Avoid SBOM Limitations
The vast majority of vendors have chosen to focus on the two leading SBOM standards: SPDX and CycloneDX. While SWID is far from dead, given the lack of SBOM vendor support, it may quickly become an also-ran.
When it comes to the two leading standards, it may seem like an SBOM is an SBOM is an SBOM, and therefore there’s little to choose between vendors as long as they can accommodate your use case. However, there are two key limitations to be aware of:
- Completeness/Accuracy – dependency trees (even for simple environments) can be extremely deep, including transitive dependencies and OS-specific libraries. The most accurate version of an SBOM is produced during the build process, rather than at runtime or by performing forensics on a software release. To avoid being blindsided, ensure the SBOM solution you choose returns results to a depth and completeness that are acceptable to your security and compliance teams.
- Usability – the majority of SBOM vendors at this point will generate an SBOM that complies with legislation and/or market requirements. But beyond being suitable for distribution to your customers, these vendors offer little else in the way of utility, preferring that you rely on their traditional security and compliance tools. However, SBOMs can often be a far quicker and simpler way to validate code changes across your software development process rather than using traditional tooling that will always generate more false positives than a simple SBOM check. Examine your development processes to see where an SBOM check may be more expedient.
Next Steps:
How do you know that your SBOMs are accurate? That’s where attestations come in. Watch our webinar “SBOMs & Attestations” to understand how you can gain complete observability for your software supply chain.
