Is SBOM the answer?
By David Foose
Government and industry experts have recently pointed to software bill of materials (SBOM) as a requirement for organizations, but what are you getting? David Foose spends some time exploring aspects of SBOM fever.
To continue the conversation around supply chain, I would like to take a few minutes to single out one of the items pushed to the forefront, providing a software bill of materials (SBOM).
This idea received special attention in Executive Order 14028 that was signed by President Biden. The order directed the federal agencies to request a SBOM or have it published on a public website. It directed NIST to define the minimum elements of SBOM, tools to generate, and use cases all with a very brief window of time to complete. For most of the fall of 2021, the herculean effort was shouldered by teams across several federal agencies.
The executive order did take special effort to clarify the intent of what it was looking for in the footnotes. It specified that an SBOM will “enumerate open source and commercial software components” in a product. It is “analogous to a list of ingredients” that could be used to ensure that components are “up to date.” It would also be provided in a “machine readable format.” This would be a departure from earlier discussions where some security experts suggested detailed reports that would come closer to traditional code reviews.
There are still some additional details that need to be defined. First, who is the “vendor” that will be providing the SBOM? Is it the person you purchased from or is it the original creator of the product? Is it good enough to tell you the software is Microsoft Windows 10 build 1607 IoT edition (which is even giving you build/patch level including licensing) or do I need to list out each individual Windows component and patch? This could be a negotiation at the time of the contract, but I am sure it is not going to be a universally understood obligation. When requesting additional information beyond what has been stated, who is obligated to provide? Microsoft or the person providing the final transaction? Again, this can be contractually stated and seems to be pushing towards a flow-down expectations where the information may not exist and the party who can generate it is not motivated to complete the task.
Perhaps it is in my best interest as a boutique vendor to a specific group of clients that I do this type of vetting/generating of information for all my primary products prior to sale. For decades, nearly all automation projects I have been a part of expected binders of media with licensing, versions, and install media as part of the initial turnover. What may be lacking would be some additional individual components and a document in the new ‘machine readable format’.
As many of our environments are very much on the brownfield variety, several companies and industry groups are attempting to tackle the problem of creating your SBOM with the least amount of disruption to running operations. Some approach the problem with technical capabilities of inspection. This is often done for speed to cover the environment versus reaching out to each individual vendor with a human. This is not scalable and can lead to frustrations. Frequently the creator of the device may not answer due to support or may not even exist anymore. Some groups are taking it a step further by building a repository of data from devices or companies from which they partner so that their users can check against. No need to scan because it has already been checked.
Let us say that you can scan your environment and get back most, if not all of your main devices and software versions. You now have a large list to supplement our original asset list. Next big bad bug hits. Your boss sends you the link from Bloomberg and you can give an immediate thumbs up or down if you are impacted. Job well done, right? Well, almost. If there is impact, that only starts the clock on “when it will be fixed”.
Who do you call now? The SBOM company that helped you find it? Maybe. That could be a service they could provide in the help to arbitrate common devices if there is an issue. Is it your immediate upstream vendor? Maybe. It depends on if you have a relationship that they are willing to take your phone call and act with any level of urgency. Money certainly greases the wheels, but answers only come so fast. This could be super critical depending on how pressing the vulnerability seems. Several events over the last few years had timelines to respond in days at most. Each link in the chain for someone to check is another delay on response. It should be telling that SBOM is not a user focused request when the President of the United States is asking for ‘machine readable’ documents. This is and always has been a niche ask for an extremely small subsection of analysist and vendors to build a product or service which should and will be wrapped into normal asset or vulnerability management. End consumers, much like your C level executives, just want the assurance it is handled and a timeline.
I still contend that SBOM exists in a form today that is useful for a large percentage of bugs that continue to not be triaged on a regular basis. Look at the decades of missed updates to workstations, servers, and network infrastructure. It isn’t a lack of knowledge that these devices are in the environment or the bugs that exist that are preventing organizations from action.
Are there examples of vendors abandoning versions of woefully neglected and vulnerable software into environments across enterprise and consumer electronics? Yes. Do we have instances where this untouched code was leveraged for a compromise? Also, yes. Would knowing that a device had a vulnerability on it that can be leveraged by a bad person in an active attack going on right now cause an individual to act? History has shown, just maybe.
Much like threat intelligence feeds or vulnerability databased efforts in the past, I don’t see this latest push for an ‘ingredients list’ of what is running on our gear leading towards nuanced defensive decisions. The information will be still generic, dated, and incomplete. Vendors will iterate methods of collection and then preach consolidation. End users will over-rely on tools leading to blinds spots.
Rinse and repeat.
