There is no debate that the software supply chain is filled with action. It’s the front lines of the security world these days. If you have a shadow of a doubt, search the history of SolarWinds, Codecov, or CircleCI for examples of how attackers use the supply chain as a gateway of compromise.
The software supply chain is so hot that it’s caught the attention of the US Federal Government by way of the now infamous Executive Order 14028. If you haven’t been living under a rock, then you realize that a central figure of the Executive Order is the SBOM.
The EO defines a Software Bill of Materials, or SBOM, as a formal record containing the details and supply chain relationships of various components used in building software. This makes sense, with the emphasis placed on a “formal record.” (Note that records do not act. Data is available to read but does not intrinsically add value without the action of some other entity.)
SBOMs are not magic pixie dust. SBOMs do not make your product or application more secure. Instead, an SBOM contains an ingredient list that goes into an application or product. The efforts surrounding a software supply chain program are what improve the security of your products and applications.
Let's be clear: I do not dislike SBOMs, and I hold no grudge against them. However, the industry has gone all in on SBOMs, so the value question must be asked. Large companies have thousands of products with thousands of software releases throughout the product's or application's lifetime. What is the value proposition for making all this information available? What, if anything, will be gained through the data?
SBOMs are on the cusp of being a tool that could significantly improve — or distract — from the software supply chain security improvements we need as an industry. However, security professionals face a challenge if the SBOM continues to be seen as a silver bullet. If the SBOM continues to be interpreted as something it's not, it could hurt more than it ever helps.
Here are two core problems with SBOMs, followed by six key misconceptions about them that we need to clear up if we are going to make them a useful tool for software supply chain security.
[ Learn why you should go beyond the SBOM with our Special Report. Plus: Download the White Paper ]
-
1. SBOMs could produce a false sense of security
If the industry continues to project the value proposition of SBOM as it does now, this produces a false sense of security. Therefore, when asked about the current state of the security of an application, the answer “we have an SBOM” will be given.
Having an SBOM makes a product no more or less secure. The SBOM, as a record of ingredients, is a piece of data. Only when programmatic efforts are wrapped around the SBOM does the SBOM unlock security value.
-
2. SBOMs could become another checkbox compliance item
SBOMs could result in another checkbox compliance activity. Checkbox compliance makes auditors happy, but doesn’t move the security needle.
If organizations must invest in SBOM, the value should exist. Their products and applications should become more secure due to the efforts they are forced to make. If we put the effort in, we should get something of security value out of it.
If you snapped your fingers and magically generated SBOMs for all the software in the world, how would this software be more secure? It would not. More information about that software and its metadata would require detailed analysis and action to address security weaknesses and generate value. That might include a program to analyze the records' contents and generate alerts about the vulnerabilities. A human would then need to review those alerts, prioritize them and act to resolve any issues.
All this attention to SBOMs leads some security professionals, including me, to an uncomfortable question: “Does an SBOM improve security?” The question is uncomfortable because so many resources are being expended across our industry on building and making SBOMs available. The premise of the question is that, for the attention and effort being placed on them, SBOM may not return much value. Call it the "Software Bill of Mediocrity."
Software Bill of Mediocrity? Not if we can agree on its value
But, of course, it doesn't have to end that way. Yes, SBOMs will continue to offer mediocre value to organizations if their value proposition continues to be misunderstood, resources are not extended to act upon SBOM programmatically, and the industry cannot move forward into a usable and performant method of information sharing between buyers and sellers of software. But, on the other hand, it doesn’t have to be mediocre if everyone agrees and invests in its true value proposition.
The Executive Order declares the value proposition from the US Government’s point of view for developers, buyers, and software operators. Below is a direct quote from the EO regarding the value proposition for developers of software:
“Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities.”
6 misconceptions about SBOMs
1. SBOMs have operational capability
The EO's suggestion that SBOMs have an operational capability to scan for vulnerabilities is the first misconception. A class of application security tools reviews applications for software supply chain vulnerabilities called Software Composition Analysis (SCA). Such tools have existed to enhance software supply chain security for years. The SBOM, on its own, doesn’t scan or report anything.
Developers already have access to the components that make up their applications and products. Therefore, an SBOM for a developer adds no value beyond what they can gather using a commercial or open-source SCA tool.
2. SBOMs are comprehensive
This SCA dependence also raises a second misconception: SBOMs do not impact the custom portions of the code written by the developer, which is combined with the open source and third-party software components to create the product. While this custom code, on average, makes up 10 percent of the total codebase, that 10 percent has its slew of bugs and vulnerabilities.
Don’t forget, SBOMs only allow you to report known vulnerabilities by deducing the vulnerabilities in the software components that make up an application. When you build an application, you write some custom code. That custom code is where the top application security risks make their presence felt. These items are described in the OWASP Top 10, or the top 10 application security risks.
The Executive Order also provides the rewards of SBOMs for operators of software:
“Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format provides greater benefits through automation and tool integration."
3. Development teams can act on SBOMs
There lies the third misconception about SBOM – those that operate software have the resources and programs to ingest SBOMs and act upon them. Yet, thousands of SBOMs will be generated daily and require consumption from all the software the agency or organization relies upon. Sure, you can keep up. I believe in you.
4. Cross-organizational sharing is "quick and easy"
From there, we find our fourth misconception about SBOM as an extension of the third – cross-organizational SBOM sharing results in vulnerability notification and actions between buyers and sellers of software. The EO says, “quickly and easily.” There is nothing quick or easy about cross-organizational data sharing. Perhaps if notification and action are entirely automated, there is a chance that this could work.
However, given the current state of automation and the trust among parties, this seems like it could be more challenging to implement. Coordinating with a central vulnerability organization when working on releasing fixes for a given vulnerability across the entire industry is one thing. That is a many-to-one relationship, with the one doing the coordination. For SBOM to generate, action would be a many-to-many relationship, with every buyer and seller of software involved in the mix. There is a word for this many-to-many relationship: chaos.
The final reward described in the Executive Order is for those that purchase software:
“Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product.”
Now, this is something workable. SBOMs do provide license data to allow the understanding of license risk. License risk or using the wrong license and opening a product or application up to an unplanned source code sharing is an inward-facing problem. As a buyer, the risk of using a product with a lousy license has little impact on your operations.
5. SBOMs and modern software delivery
The fifth SBOM misconception stems from buyers needing more time or resources to keep up with the steady flow of SBOMs as new software releases occur. The software is pushed multiple times daily in a DevOps world with a modern SaaS-style offering. The challenge is volume.
Keeping up with the influx of new SBOMs will be a monumental task. Beyond keeping up is acting and gaining valuable and actionable results.
6. SBOMs alone help evaluate risk
The sixth SBOM misconception comes from the idea that buyers can use the SBOM to evaluate the risk in a product. Software is a constantly changing thing. In a modern DevOps world, where multiple software releases are pushed to production per day, the SBOM could change drastically between 9 o’clock in the morning and the end of the business day. Evaluating risk based on the contents requires an automated script that generates a risk score. You would then need to average the risk score across multiple days of SBOMs for an accurate idea of how fast the software components are being updated based on vulnerabilities.
This whole approach stinks of a waterfall world where there was a single software release per year. In that type of world, this approach of spending weeks analyzing an SBOM would have merit. Unfortunately, the water has fallen, and the software world is now moving at the speed of DevOps.
Evaluating individual SBOMs as a risk reduction strategy is a pipe dream.
Let's agree to not treat the SBOM as a silver bullet
SBOMs don’t have to be mediocre if they're understood for what they are. Suppose our industry wakes up and realizes that SBOMs are not a silver bullet. In that case, we all agree it does not improve security inherently; it’s not a checkbox compliance play; and it realizes that SBOMs can contain traces of innovation.
SBOMs can be the catalyst for building vital software supply chain programs, and new tooling that automates risk evaluation. Understand them for what they truly are. Only then will you extract their value.
