The “global information environment”—the theme of this issue of the ISACA® Journal—can mean different things to different people. For some, it might mean navigating the complex web of international geopolitics and economics, while for others it might mean fully leveraging the cloud and the Internet of Things (IoT) to tap into new markets in new regions. Some might look at jurisdictional differences in privacy and other legislation, while others might focus on collaboration challenges across regions (e.g., effective productivity in distributed teams.) For me, the biggest elephant in the room is the supply chain—in particular, the software supply chain.
Now, I know what some of you are thinking. Perhaps you may be thinking that the past few years have generated a great deal of hype about the software supply chain, but relatively little in the way of actual practical utility. Or, perhaps less generously, that there has been a veritable nonstop parade of people telling us about how things like a software bill of materials (SBOM) will solve all software supply chain problems, and that this talk has translated into relatively little payoff for those of us in the trenches with actual problems to fix.
While this view is, perhaps, cynical, it is not unfair. It is a fact that there has been much hype about the software supply chain generally, and the SBOM concept specifically. It is also a fact that the SBOM renaissance many predicted has not come to pass. The fact of the matter, though, is that two things can be true at the same time: SBOM is not a panacea (and hype suggesting otherwise is misplaced), and if approached diligently, the exercise of producing and consuming an SBOM pays dividends. The difference, I would argue, is in how you approach it.
With that in mind, then, let us look at the software supply chain through the lens of an SBOM—what it is, how it can help you, and how you can adapt your own program to practically incorporate it.
What Is an SBOM?
In a nutshell, the purpose of an SBOM is to provide transparency into what comprises a particular piece of software, such as a business application, development library, or really any other software package or software component.
As an analogy, consider something like a material safety data sheet (MSDS) or even the ingredient list on a packaged food. For example, if you purchase a granola bar, the bar’s packaging will contain a list of ingredients used to manufacture it. If you have a need to know what is in it because, for example, you have a certain dietary restriction, this information can help you make informed decisions. If you have a severe food allergy, such as to peanuts or tree nuts, or a food intolerance or illness such as celiac disease, this information is not just nice to have—it can literally be lifesaving.
The purpose of an SBOM is very similar: In one place, the consumer of a software application learns unambiguously what components are used in it. Why might anyone care what components are used in the creation and execution of the software in their environment? For a whole host of reasons. For example, consider what happens when someone discovers a vulnerability in a ubiquitous component, such as what happened with the Log4Shell vulnerability (CVE-2021-44228) in the popular Apache Log4j component. Many of us still remember the frustrating exercise of trying to find out from the vendors we use whether or not their software was impacted by it. The more helpful vendors (usually those on the larger side) put together informational resources such as support articles, statements on web pages, customer bulletins, and so on, that explained whether they were using it, and where, and detailing any risk exacerbating (or mitigating) factors that might effect customers. Frankly though, this type of response was uncommon. Most of us had to spend significant time emailing, calling, creating support tickets, and pestering vendors to learn whether the software supporting our businesses was benign or a ticking time bomb.
While most organizations had to go through at least some of those challenges, organizations that actually produced software had it worse. They not only had to engage in the exercise of determining whether or not their vendors used the component like everyone else, but also had to respond to a near-constant drumbeat of customers wanting that information, which is a harder question to answer than one might think. Today, most software employs dozens or hundreds of different components (some open source and some commercial), any of which could contain this particular item. On its own, that would be a difficult problem. But keep in mind that each of those components is, in turn, built using other components, which are, in turn, built using still more components, and so on. If you have never spent more than 120 hours trying to track down whether or not your supplier’s supplier’s supplier’s supplier uses the XYZ open source library, take it from me, it will give you a new perspective when you do.
How You Can Use This
Of course, all of this raises the question of what we might do instead. Looking at it in a manner similar to how the person with a nut allergy views an ingredient list, one can start to see why an SBOM would be desirable. Used this way, an SBOM is like a shipping manifest: You can tell by looking at it what is contained within. You do not have to track anyone down, you do not have to make phone calls, and you do not have to open support tickets. You just look at the report.
For software vendors, the same thing holds true. Rather than having to dig into each individual component, you can instead draw upon the information in the report to readily answer the questions your customers are asking; and instead of having to report the status to each customer individually, you can prepare something once and distribute it to everyone. It reduces issues for both sides of the relationship.
Sounds great, right? Absolutely. Hence, the reason for all the hype.
Of course, the gotcha is that being able to either practically produce or consume SBOMs takes a great deal of work and planning. It requires a bit of automation, a great deal of temet nosce (i.e., self-awareness), and it is not something that can simply be concocted. There are some pretty solid logistical and engineering reasons for that. It is true on both sides, by the way—for both producers and consumers. Both sides of the usage equation take planning and effort.
To illustrate why it is true, let us say that tomorrow morning you arrive at the office and have a directory full of data sheets for all of the software you use in your enterprise and all the dependencies they have. This is putting aside the fact that (at least for large organizations) knowing what all that software is in the first place is a monumental piece of engineering in and of itself (let alone what features are in use for each product, how they are used, by whom, etc.), and that knowing what components comprise that software is a practical impossibility. Let us just wave a hand over all that and assume you know the answers to those questions and that somehow the documentation was made available to you with no additional work on your part. How much documentation do you think that would be? Dozens of applications? Thousands? Tens of thousands? Now, start to consider how many individual and unique components are used in the creation of those applications. How many do you think you would have now? Tens or hundreds of thousands? Now consider how many components might be used to develop those. Millions? More?
At this point, you are only three orders in and you are talking about potentially hundreds of thousands or millions of individual components. Realistically it can “nest” to much more depth than just third order dependencies—meaning that the consumption of SBOMs requires an ability to organize, search and filter.
It is for exactly these reasons that the current SBOM standards require automation. I will not spend much time on the mechanics of the individual standards, but for reference they are:
- CycloneDX—An Open Web Application Security Project (OWASP) standard that utilizes XML or JSON to contain dependency information
- Software Package Data Exchange (SPDX)—An international standard (International Organization for Standardization [ISO]/International Electrotechnical Commission [IEC] standard ISO/IEC 5962:2021) that specifies the format for codifying components, license information, etc.
- Software Identification (SWID)—An international standard (ISO/IEC 19770-2:2015) that provides mechanisms for how to contain and transmit information about software components
The fact that there are two ISO/IEC standards on the list should clue you into the fact that this is by no means a simple process. In large part, the complexity is driven by the incredibly complicated spider web of dependencies woven into even the simplest of applications that might be employed.
In terms of actually producing an SBOM, bear in mind that it almost certainly requires automated support to produce content using the machine-readable standards described herein.
Using an SBOM in Your Program
Despite the practical challenges in production and consumption of SBOMs, there are still compelling ways that you can use them in your software supply chain efforts. First and foremost, If you are an organization that produces software, understand that some of your customers will absolutely ask you for them. That may not be happening yet, but they will eventually. This means that you should have it in the back of your mind as you evaluate the tooling and processes you use. For example, if you are looking into modifications to your DevOps/DevSecOps tool chains, consider incorporating supply chain capability into that just as you would Static Application Security Testing (SAST) or quality assurance (QA) automation. Likewise, as you evaluate other software you might employ in the application space (e.g., SAST, Dynamic Application Security Testing [DAST], software composition analysis [SCA], Code Quality), consider the capabilities offered by those vendors in the supply chain space.
If this is front of mind, you will realize that many of the tools you might already be familiar with and/or use, such as SCA tools, can help—as can those that you might be using for things such as open source licensing compliance. Those tools can help in at least two ways. First, they can help you in the task of identifying what software you are using (and their supporting components). Second, they can assist in the generation of the data structures and packaging outlined in the previously listed standards.
From a process point of view, undertaking the exercise of actually trying to produce an SBOM can be enormously beneficial in a “ journey is the destination” kind of way. That is, actually trying to do it forces you to build a better understanding of what you have in play—and it can help you build the automation to get to better levels of understanding and coverage. Your efforts out of the gate may not be comprehensive or easy to get up and running, but they can pay dividends down the road—particularly if you have customers who are demanding higher levels of transparency.
For organizations that consume software but do not necessarily produce it, there can also be benefits in planning around an SBOM. For some of the larger vendors that usually have SBOMs available, it can be helpful to actually try to consume them and extract information from them. Why? Two reasons: First, the information in them can be valuable, and building out the ability to consume them is time well spent. Second, laying the groundwork means that as more and more vendors start to provide them, you can bring them into the fold and build out a searchable database to inform everything from incident response to compliance to architecture and beyond.
ED MOYLE | CISSP
Is currently director of Software and Systems Security for Drake Software. In his 20 years in information security, Moyle has held numerous positions including director of thought leadership and research for ISACA®, application security principal for Adaptive Biotechnologies, senior security strategist with Savvis, senior manager with CTG, and vice president and information security officer for Merrill Lynch Investment Managers. Moyle is co-author of Cryptographic Libraries for Developers and Practical Cybersecurity Architecture, and a frequent contributor to the information security industry as an author, public speaker and analyst.