As modern software grows more complex, it’s becoming increasingly important to know every last bit of what’s in the applications you’re developing. In Sonatype’s 8th Annual State of the Software Supply Chain report, we noted that, on average, a library contains 5.7 dependencies, and the average Java application contains 148 dependencies. The reality is that many organizations aren’t aware of dependencies pulled into their applications through open source.
But even if an organization knows what its developers are using, that doesn’t mean their knowledge extends to vendors. That makes using (and requiring) a software bill of materials (SBOM) incredibly important.
What is an SBOM?
A software bill of materials (SBOM) is a comprehensive inventory of all the components that comprise a piece of software. It’s similar in concept to a bill of materials used in manufacturing. Your typical SBOM includes the following:
- The supplier name
- The component name
- The version
- The dependency relationship
- The author of the SBOM
- The time the data was added to the SBOM
- Known risk related to security, legal, and quality
Identifying all the different components used in software helps developers find potential security vulnerabilities and make informed decisions about how to mitigate them. For example, suppose an SBOM reveals that a particular third-party library contains a known vulnerability. In that case, they can replace it with a more secure alternative or take other steps before it causes a more significant security issue.
Are SBOMs required?
While SBOMs are not currently a requirement for everyone, the Biden administration’s 2021 executive order requires all vendors who sell software to the federal government to use an SBOM. And the US National Telecommunications and Information Administration has laid the groundwork to make them a requirement for all.
The Biden administration's legislation and incidents like the Log4j vulnerability have created a demand for their requirement. Additionally, SBOMs are included in guidelines from the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of the National Intelligence (ODNI).
The recently released Biden-Harris National Cybersecurity Strategy might not have made SBOMs a general requirement, but the writing is on the wall. The consensus: use an SBOM.
What makes Sonatype’s SBOM capabilities superior?
Accurate component identification
Sonatype’s analysis has three phases:
- Analyzing all components going into an application during the build.
- Gathering identity, vulnerability, and legal data of found components.
- Comparing the data against governance policies to generate a report.
And how does that translate into more accurate component identification? Many of our competitors’ tools pull data from publicly available vulnerability databases. One of Sonatype’s differentiators is having a large security team that produces more precise data than what is available within public databases. Sonatype analyzes more than 4.7M components per day and has discovered 95x more malicious packages as compared to alternative solutions.
Sonatype’s team analyzes every security issue and ensures that risks are accurately associated with the right components. Their findings include:
- Identified vulnerabilities
- Potential remediations
- Evidence that supports our findings
Our security team utilizes a wide array of automated tooling and machine learning to collect security data from well over 100 sources–beyond publicly available security feeds–to find vulnerable components. We often identify components before they’re widely known to be malicious and added to the public vulnerability databases.
Once our security team implicates a component, our advanced vulnerability detection systems will ensure that any other components that share the identified code–or embed that code–are also implicated. Compared to public vulnerability databases, our team leaves no stone unturned in the hunt for malicious components.
Scalability and speed of scanning
Sonatype’s SBOM capabilities offer a powerful combination of speed, scalability, and ease of use. Our tools can rapidly analyze large volumes of software code to identify all the components used. This allows you to generate an SBOM in minutes compared to the hours it can take our competitors to generate a similar report.
And as a bonus, the Sonatype Platform integrates with popular DevOps tools and workflows, allowing you and your team to integrate SBOM generation into your existing development process seamlessly.
The Sonatype Safety Rating
Sonatype offers users another leg up on staying ahead of vulnerabilities through the Sonatype Safety Rating. Powered by our superior data capabilities, it is an aggregate rating designed to estimate the likelihood that an open source project contains vulnerabilities. Projects score on a 1-10 scale. The more confident the model is that a project will not have vulnerabilities, the higher the rating.
Sonatype bases the Safety Rating score on two things:
- The OpenSSF Security Scorecard data for that project.
- The project’s Mean Time To Update (MTTU)–a measure of how quickly the project updates its dependencies when new versions come out.
The model is based on empirical research conducted by the Sonatype Research Team. Our team analyzed thousands of projects and determined a high correlation between the Safety Rating and the presence of vulnerabilities. Fun fact: 88% of projects scoring below 5 have existing known vulnerabilities. Utilizing the Safety Rating to determine which projects your team should use can help keep unnecessary vulnerabilities out of your software supply chain.
Export any application scan report as Cyclone DX SBOM
Sonatype has been a part of supporting CycloneDX–a tool for automating SBOM creation–since its early development. And Sonatype Platform users benefit from SBOM generation and scanning as a built-in feature of Sonatype Lifecycle.
Users can export every report as a Cyclone DX SBOM in either an XML or JSON format. We’ve utilized the Cyclone DX standard to create an API that provides users with an easy way to integrate and share SBOMs between other Sonatype products and completely different systems.
How does the competition compare?
Earlier, we mentioned that the writing is on the wall regarding SBOMs, and our competitors have certainly taken note. Many have made recent additions to their offers to include SBOM generation.
Some of those recent additions include:
- Bomber 0.3.4
- SBOM Checker
- SBOM API and CLI
Let’s take a deeper look.
Bomber 0.3.4 and SBOM Checker:
- Analyze SBOMs and generate reports on security vulnerabilities.
- Identify known vulnerabilities in open source libraries and frameworks by comparing the contents of an SBOM to publicly available vulnerability databases.
SBOM API and CLI are slightly different. They generate SBOMS directly within API and CLI tooling to document direct and transitive dependencies.
The big difference between these and what Sonatype offers is that none of these provide analytical tools beyond vulnerability scanning. And as we mentioned earlier, these tools depend on publicly available vulnerability databases, which can’t compare to the in-depth results that Sonatype’s Research Team produces.
Even when it comes to free tools, Sonatype is superior
You don’t have to be a Sonatype customer to start benefitting from our capabilities. The Sonatype Vulnerability Scanner is a free scanning tool that utilizes Sonatype Lifecycle. Like Bomber 0.3.4 and SBOM Checker, it analyzes an application and generates a report on security vulnerabilities.
So how is Sonatype Vulnerability Scanner superior to what our competition offers? You'd be correct if you guessed that our superior data sets it apart. Even our free tools pull from our remarkable data set. Compared to free tools like Bomber 0.3.4 and SBOM Checker, Sonatype Vulnerability Scanner users can be confident of the accuracy of their results–and trust that there are no false positives.
We can’t see the future, but we know SBOMs are a massive part of it
While our competitors are beginning to improve their ability to generate SBOMs efficiently, they’re still playing catchup. We’ve always prioritized shifting security left and being proactive about software supply chain risk rather than reactive.
To learn more about what makes our data superior to our competitors and how the Sonatype Platform protects your entire software supply chain, schedule a demo with one of our security experts.
A big thank you to Eddie Knight, Nitin Phadnis, Omar Torres, and Dariush Griffin for helping pull all the bits and pieces of this blog post together.
