By Vincent Danen, Red Hat and Tracy Ragan, DeployHub
Software Bill of Materials, or SBOMs, have been with us for the last 10+ years, so do they matter more today than when we started generating them? According to CISA Director Jen Easterly, “radical change” for technology product safety is required. For radical change to occur, IT teams and open source communities must disrupt their approach to securing software. Many new discussions have started around securing the software supply chain, but none is more popular than the SBOM discussion. While much of the current conversation concerns generating SBOMs, we rarely discuss what we do after we have them.
On that note, the ITI (Information Technology Industry Council) trade group formally objected to the Biden Administration’s order on SBOMs (No. 14028). In their letter dated November 21, 2022, they reason:
“Given the current level of (im-)maturity, we believe that SBOMs are not suitable contract requirements yet. The SBOM conversation needs more time to move towards a place where standardized SBOMs are scalable for all software categories and can be consumed by agencies.”
In other words, don’t require an SBOM as part of a contract until the government consumes and acts upon the SBOM intelligence, which echoes the sentiment provided by the Cybersecurity Coalition dated May 10, 2022.
We’ve been discussing the creation of SBOMs for over ten years, but has it gotten us any closer to hardening our software development practices?
Heartbleed and Log4J – Same Story, Different Year
Heartbleed was a vulnerability in the OpenSSL cryptography library. OpenSSL is widely used to implement the Transport Layer Security (TLS) protocol. In 2014, we learned the hard lesson of why SBOMs mattered. During Heartbleed, the question was, “where is OpenSSL running, and what version?” Eight years later, we asked a similar question: “Where is Log4J running, and what version?”
In 2014, Heartbleed sparked more conversations about SBOMs. SPDX (the Software Package Data Exchange format) was first released in August of 2011, so the tools for discovery existed before Heartbleed was disclosed, but few IT organizations produced SBOMs. According to the Linux Foundation’s Software Bill of Material and Cybersecurity Report 2022, 48% of the 412 companies surveyed said they were producing SBOMs. That number needs to be higher. The way to get there is to shift the conversation from generating SBOMs to consuming SBOMs; otherwise, we applaud ourselves for generating an SBOM – so far, so good, but so what? An SBOM is only useful when it’s being used.
Consuming SBOM and CVE data
Consuming SBOM and CVE data are similar but different. An SBOM describes the software, including information around licensing, provenance (where it came from), version information and so forth. Think of an SBOM as a list of ingredients but with more fidelity than you’d find in a grocery store. CVE data, on the other hand, identifies a vulnerability in a particular piece of software, showing just that package and version. It includes the CVE identifier, which product or component is affected, a severity rating, and a description of the issue. The information is related but distinct. Typically this information is produced by vulnerability scanners with varying degrees of accuracy. Not all scanners are perfect – false positives, anyone? Every user of a vulnerability scanner has been subject to a list of false positives.
Where SBOM data and CVE data intersect is when you can use the SBOM as an input to correlate CVE information. A scanner typically has to detect the software installed using a variety of detection methods. However, open source comes from several different sources, and many enterprise vendors will backport fixes to older versions of software they support. For example, a vulnerability fixed in version 1.5 of a piece of software might be isolated and applied to version 1.1, which an enterprise open source vendor is providing. A scanner would detect version 1.1 and erroneously assume the software is vulnerable.
An SBOM paired with vulnerability data provided by the vendor can clearly identify that package and version as being fixed. No more false positives! On the other hand, the truly dangerous problem is false negatives. If the scanner is not detecting a vulnerability is present because it doesn’t detect a piece of software for which a patch might be available, now you have an unknown, known vulnerability present with no reasonable way to mitigate it. Knowledge is power!
The above case shows where the consumption of SBOM data is beneficial. Vulnerability scanners are prime candidates for using SBOM data to provide more accurate scanning results. In addition, when you rely on vulnerability scanners, you must continuously re-scan your code to get the most accurate, up-to-date information. It is much easier to scan your SBOMs continuously. Because each SBOM is associated with a release version, you can immediately see if a new vulnerability is running in your production environments. No guesswork is involved.
Producing SBOM data
Beyond just consuming SBOM data from your open source vendor or upstream directly, developers and IT teams should produce SBOM data for the applications they are building. This means adding SBOM generation to your development and DevOps processes. The best way to motivate teams to do this is to consume the data and give actionable feedback.
Looking at vulnerability scanning again, it has become popular because it creates actionable data, unlike SBOM data trapped under the covers of the pipeline. Most teams may see SBOM generation as just checking off a box on a list of compliances. As a result, IT teams might perceive the generation of lists of CVEs as the most critical step. After all, CVE data is uncomfortably obvious when a vulnerability appears.
Let’s take a simple Java Docker Image example. In the image, you have your .jar file created from your build and source code, plus all of the runtime jar file dependencies. A vulnerability scan of the Docker image can produce a vulnerability list of any CVEs found in the jar files and OS dependencies in the Docker image.
If all you’re doing is consuming a vendor- or upstream-supplied SBOM, your results will be limited to the container image itself. While this is useful, what about the software placed inside the container? The same constraints apply – a scanning tool will only report on what it can accurately detect. Extending the vendor-supplied SBOM with what was added to the container will produce a more accurate SBOM and thus more accurate results for scanning tools.
Further, when this application is maintained and developed in-house, there’s the question of obtaining updates for dependencies used in the application. This is where SBOM generation is necessary. The SBOM should provide provenance so you know from where a particular component originated and where to find the resolution. More importantly, the SBOM lets you know that a particular piece of software is used in a particular deployment. With appropriate use, an IT team would know precisely what is being used and where. So when a vulnerability is disclosed, they know where to look to remediate – sometimes in advance of a vulnerability scanner reporting it.
Why SBOMs
SBOMs are the key to providing more transparency into the software you consume across your organization. Knowing what vulnerabilities may be present is essential, but more is needed to harden your software supply chain. SBOMs are all about your software supply chain, who is creating the packages you use, who you should trust, and critical dependency relationships. SBOMS provide:
- The provenance of the package dependencies, allowing teams to know who to contact for an issue, or where to obtain a fix from, which improves incident response.
- License information for package dependencies which is something critical for commercial software.
- Graphing of your dependency ecosystem. SBOM graphs will show where you may have multiple dependencies doing the same thing, the concentration of risk associated with one package across the organization, or better management of the procurement of external components.
- An SBOM generated during the build step will expose all source and package dependencies used to create your artifact (.jar, .exe, .npm, etc.). An SBOM generated at this level shows what source code you need to address when an anomaly is found in the artifact (source to artifact SBOM). It also provides a level of accuracy that cannot be obtained by scanning applications after they’re built.
- SBOMs are the foundation for zero-trust policies. SBOM specifications include showing digital signatures if the package has been signed.
Even though SBOMs create this critical level of data, if the data itself is not consumed, critical information is hidden from the teams that need it. As long as SBOM data is not consumed and put into action, the adoption of SBOMs will be an ongoing uphill battle. Why go through the efforts of creating something that’s never used?
Conclusion
SBOMs provide critical supply chain data, but we are simply not using the data to drive our supply chain decisions. Requiring SBOM generation alone is not the answer. The way forward for SBOMs is to centralize the data to create an organization’s supply chain security profiles along with easy ways to act upon the critical information. Putting the SBOM data to work will drive the adoption of SBOMs. In addition, SBOMs should be treated like any artifact and have the same level of provenance and signing. And finally, SBOM immutability and historical tracking will secure the SBOMs themselves.
About the Authors
Vincent Danen is the Vice President of Red Hat Product Security, with interest and experience in computer security, vulnerability response, operating system design, security, and development. Vincent has been working in the security field, specifically around Linux and operating system security, for over 20 years. He serves on the Governing Board of the OpenSSF.
Tracy Ragan is CEO and Co-Founder of DeployHub. DeployHub is a microservice catalog that turns supply chain security evidence into actionable results. Tracy’s career has worked in software supply chain management and pipeline DevOps practices with a hyper-focus on microservices and cloud-native architecture. She served on the OpenSSF Governing Board as a General Member Representative. She also serves on the Continuous Delivery Foundation (CDF) Technology Oversite Committee. She previously served as one of the founding Governing Board members on both the CDF and the Eclipse Foundation. Tracy is the Executive Director of the Ortelius Open-Source project, a Supply Chain Evidence Catalog currently incubating at the Continuous Delivery Foundation.