SBOMs and Their Operational Pain Points

SBOM?[pronounced S-bomb] stands for “Software Bill of Materials” and are difficult to source, difficult to manage, cumbersome to produce analysis on, and overall, just difficult to operationalize. Anyways, thanks for coming to my TED talk…. I’ll see you all in the vendor hall.

Okay I joke. On a serious note, SBOMs are useful tools worth adding to the risk mitigation toolbelt, ?but there are some operational pains involved and it’s useful to know what the ‘gotchas’ are. At a high level, I would list the three major hurdles to operationalizing SBOMs as: ?1) Acquiring SBOMs, 2) Managing those SBOMs, and 3) Using the data from those SBOM?s. Let's?dive into those three topics.

Acquiring SBOMs

SBOMs usually come in one of two standard formats: CycloneDX or SPDX,? and most commonly are stored and distributed in a machine-readable JSON ?format. But where do these files come from? Is it a program that generates them? Is it all hand jammed by the developers? Who should deal with getting the SBOM, the customer or the vendor? The answer is, well… ‘yes’. Let’s ?rapid fire some quick hot points

• Hand jamming an SBOM: This can be done, but I wouldn’t recommend it. The only ones really suited to do this are the developers as they are the ones with the liberty of knowing what 3rd party software components they are leveraging. If you are a developer and you choose to venture down this path, I recommend using a tool like OWASP’s Dependency-track. I’m sure there are other tools, but this open-source? tool makes pretty quick work of creating a project, adding software components, and then allowing the user to export a JSON ?SBOM all through an easy-to-use webUI?.
• Generating an SBOM from source: This is what I would call the golden method to producing an SBOM. It’s only applicable to vendors since you need to have access to the source code to use this. For the sake of brevity,?I’ll leave it at If you’re? a developer and using a language that uses a package manager, as most modern languages do, check out CycloneDX’s Tool Center. You might be surprised how easy it is to add SBOM generation to your CI/CD pipeline?. I know I worked with a client that had a Java project using Gradle and it as simple? as adding two lines to the “build.gradle”?file and they had SBOM capability for that project.
• Static analysis to generate an SBOM: This is likely the category that most of my readers will fall into. Let's consider a scenario: You have some software have some software or firmware that you either have in your environment or are looking at as part of the acquisition process. The vendor doesn’t have an SBOM or is unwilling to share it. This leaves it up to you to somehow miraculously produce an SBOM from some random binary or software executable. This file can be scanned and statically analyzed to determine what software components went into its creation. There are several tool providers available on the market willing to do this for a fee. In my experience, none of the open-source ones work particularly well. The good news is that the? user experience with the handful of paid ones I’ve tried are typically excellent. Netrise, Codesentry, FiniteState, etc.

Using, Managing, and Analyzing SBOMs

Alright, now assuming you’ve solved the first hurdle and acquired some SBOMs for your assets; why did you do this again? Well,?we want to make use of the information about the third-party software components, make some sense of it, and hopefully reduce our overall risk exposure. At this point you’re going to need a way to manage the SBOMs and make use of that sweet, sweet data. Managing and analyzing SBOMs are usually conveniently bundled with the same tool providers that perform static analysis if you choose to go through one of them. This of course is paid software, but they serve as a one stop shop for generating SBOMs via static analysis, ingesting external SBOMs, generating reports, and analysis on the components found. I should mention that the previously mentioned Dependency-track can also manage SBOMs and provide some analysis. While it’s very impressive for an open-source tool, it took some patience to set up. Also, while the CycloneDX?file format is standardized, I’ve seen some nuances in the JSON ?that cause ?the Dependency-track to choke more often than not when importing an SBOM.

Why SBOMs?

Okay enough fluff, why do we care about SBOMs? What do they do for us? Let’s look at some of the potential data and its use cases:

• Software Licenses: As a consumer of software, this one may not apply to us, as we get the luxury? of not concerning ourselves with this side of software development when we decide to purchase some device or software. If this is for an in-house developed piece of software, this is something you should very much be aware of. You may have heard of the terms copyleft and copyright? when it comes to software licensing. I won’t? get into the details, ?but various software licenses can be potentially damaging in terms of what rights you have to your own code when incorporating 3rd party software libraries. SBOMs will often have license information in them or as part of the post analysis operation.
• Vulnerabilities: The software packages used in the development of a piece of software often have vulnerabilities associated with them. Now, before everyone sounds the alarm bells, just because a software package has a vulnerability doesn’t mean the final product is vulnerable. These weaknesses still need to be tracked and illuminated though. As a software vendor you owe it to your customers to know what’s in your own product. As a consumer of software, you would be remiss to completely trust and rely on your vendor to track what libraries they have in their code let alone the potential vulnerabilities they represent. ?A case study I like to bring up is busybox, a widely used open-source library, had a vulnerability in its ntp functionality. This code was largely used from a software project called open ntpd.? The vulnerability was discovered in open ntpd,?but was not patched right away in busybox. Compound this with all of the? software vendors incorporating busybox into their products and you have a compounding problem of existing and discovered vulnerabilities remaining unpatched.
• Foreign Influence and Control: This one is likely of real concern only to government entities subject to executive orders and other mandates. Many government customers are concerned that key pieces of hardware and software may be coming from adversarial countries. Through analysis of SBOM components, the country of origin can be determined for those software libraries.

Where does Fortress fit in?

Alright, time for the shameless plug. Here at Fortress Infosec we’ve built a solid SBOM program that can help with any SBOM needs that might arise. We have the ability to generate SBOMs, manage those SBOMs, and produce a meaningful? analysis of them . In addition to providing vulnerability analysis on the software components, we go beyond that and are able to reduce the potential vulnerabilities to a list of key vulnerabilities that pose the biggest risk. We offer subscriptions to our SBOM datastore of over 14,000 SBOMs, data management, and even assist in in-house generated SBOMs from time to time. Whatever your use case is for SBOMs, we can assist in standing up your SBOM program to help defend your assets.