As an attack vector, the computer supply chain is attractive one and attacks on it continue to rise. Most people view a supply chain attack as something that affects only hardware. A typical scenario would involve a malicious actor working in a factory. This bad actor installs chips into the hardware that allow some kind of remote access once the system is booted or, alternatively, pre-install malware on a hard drive before the computer ships. But these days this can also include a “software” supply chain.
The hardware world has long had a complete list of components shipped as part of a system delivery known as a “Bill of Materials.” This BOM provides the customer with a detailed inventory of all the parts and pieces of a box, usually down to the types of memory installed, the processor model, everything. On rare occasions, this would include at least a starting firmware/software version, whatever the OEM put into the system itself.
A software bill of materials (SBOM) is the software equivalent of the hardware version: a list of all the components used to build an application, including any open-source or commercial components in addition to whatever code is original to the vendor. SBOMs, though, have not been quite as standard as their hardware counterparts.
Why is a software bill of materials important?
Not surprisingly, the information in a bill of materials can help determine how to fix something on whatever system to which the BOM is referring. On the hardware side, serial numbers, component specifics, and overall product identification numbers are essential when replacing a hard drive, motherboard, memory module, or any other hardware item.
Think of a software bill of materials (SBOM) in the same context. Wouldn’t it be simpler to fix a software bug if you had a list of all the additional software components in an application? Wouldn’t you sleep better at night knowing that your application consumes a specific Python library for input and output? What about your logging components? And—I’m just spitballing here—wouldn’t it be great to know for sure that you didn’t have a vulnerable version of a logging component for some, oh, I don’t know, web server like Apache?
Yeah, I know: it seems so far-fetched that something like that would ever be a threat, right?
Not only is it important to know where your software comes from, it’s also important to know what software components and shared libraries you have running on your devices or inside your applications. That’s where the concept of a software bill of materials comes into play.
With an inventory of all the software components used in an application or on a deployed device, your organization can finally figure out if you use Open Source Software library A, or custom software library B, and then which asset has which version!
Certainly, that would make those late-night calls over winter vacation much easier to take, as the solution to the question “do we run this?” would be right at your fingertips!
More on avoiding late-night, vacation-time emergencies: Improve your cybersecurity defense with centralized logging, continued: A deeper dive!
Aren’t software bills of materials already standard procedure?
The good news is that the National Telecommunications and Information Administration (NTIA) has been thinking about this concept since 2018! They’ve put together a site for practitioners to use and learn about SBOMs, and have written up some FAQs and consumable documents that help guide anyone new to this concept. Additionally, the Cybersecurity and Infrastructure Agency (CISA) has created weekly workstream meetings to share information with anyone interested, based on different topics. You can find the workstream events listed here.
What to do in the meantime
Ultimately, either generating your own software bills of materials or asking your vendors to supply them will substantially increase your ability as an organization to answer those age-old questions:
- Are we vulnerable to this new zero-day vulnerability?
- Where exactly are we vulnerable to it?
If you find yourself needing to create the SBOM yourself, be sure to visit that NTIA site, which also offers guides to creating SBOMs, evaluating the many online resources to help you out, and dispelling misconceptions about SBOMs (for example, they are not really a roadmap for hackers; the benefits to you are far greater than to a hacker who has so many other exploits available).
Taking time and care to catalog your software components correctly (and update that catalog frequently!) will help you and your leadership sleep better at night. For the most part.
Sleep even better with help from our security team! Contact us today with your security needs.
Read up on things you can do right now to strengthen your security posture: