Skip to content
Alex DowJul 22, 20212 min read

Software Bill of Materials (SBOM)'s in 5

In 2020, sophisticated hackers compromised Solarwinds’ development pipeline and embed a malicious backdoor in their popular network monitoring software suite. Through the auto-update mechanism of Solarwinds’ software, at least 800 government and private sector organizations were directly compromised. The actual impact to arguably the world’s largest and most egregious cyber attack in history is still not fully comprehended due to the wide array of victims and what the cyber criminals did within each organizations networks, once inside.

In response, the US Government has issued an executive order to address the increase in potential vulnerabilities within our digital world. The Executive order includes almost 50 directives to help improve cyber security for critical systems with the expectation that these directives will eventually expand to non-critical systems.

What is an SBOM?

One of the directives within the executive order states the desire for a Software Bill of Materials (SBOM) to be provided to the purchaser from the development company for “critical software”. This mandate is to help address the software composition problem which is the risk of (eventually) vulnerable, deprecated or malicious dependencies within the software, external 3rd party integrations and risks associated with open source licenses. Below are the highlights of the SBOM mandate.

What is a Critical Software?

The executive order mandates changes to how risk is managed for “critical software” but what is critical software? Well, it is a to be determined definition from the National Institute of Standards and Technology (NIST). An initial draft of the definition is due June 26th 2021 and will likely outline a criteria focused on what functions the application performs, what data the application collects processes and stores as well as where the application will reside in the government’s technology stack and who will have access to the application.

Think of It as a Nutritional Label

It was only in recent times that were granted details of what is in the food we eat. This allowed us to make informed decisions of what we consumed depending on our health goals. Similarly, knowing the risk of certain ingredients in software, the US government is now mandating the SBOM track the composition of the software in an effort to make better risk decision on whether to entrust the software with important business functions and data.

What Data Needs to be Tracked?

Still being defined, the SBOM will require software suppliers to provide details of the composition of their software such as the dependency supplier’s name, the name of the dependency, version and licensing. Considering it is still being determined, I can also see SBOM extending beyond dependencies like libraries but also focusing on any 3rd party integrations the software may call on. It’s turtles all the way down.

Will We See This Requirement in the Private Sector?

Yes and for good measure. First yes, because many companies in the private sector directly or indirectly supply software to the government and that means those requirements will trickle down to each supplier. Secondly, this is not just a big government problem but an everyone problem because of the ubiquity of applications in our daily life and their use of 3rd party dependencies and services.