BOMs are nothing new in technology or any manufacturing process. It allows for tracking of everything that goes into making an item. In technological manufacturing tightly controlling the BOM is a way of ensuring a higher quality of product. We have seen controlled BOMs implemented by computer component manufacturers to ensure a particular performance profile or overclocking capability. The same can be said for the automotive industry where a controlled BOM goes into making their flagship vehicles. These steps have been implemented for years at this level, but for the most part have been absent from one area in particular: application development.
The absence of a Software BOM is an alarming one when we take the events of the past 18-24 months into account. We have seen critical components of software abused, open-source repositories used to push malicious packages imitating popular and commonly used software components. On top of that we have seen a massive increase in supply chain attacks targeting everything from UEFI firmware to Network monitoring software and controls, to Operational Technology control software. Attackers are not just going after the endpoint; they are going after the applications that power the endpoint before they are even installed.
In EO 14028 there are several mentions of SBOM (a total of 11 for those counting), The references seem to set the requirement for providing an SBOM “(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;” give a timeline for publication of minimum elements of an SBOM, and define what an SBOM is (“formal record containing the details and supply chain relationships of various components used in building software”). The EO correctly states that having a proper SBOM allows a purchaser to understand the inherent risk in a particular piece of software simply by knowing the parts and versions used of all open-source and/or third-party components. What it does not really do is require them in any real form though.
SBOMs are not just good for people purchasing software though, they can also provide a baseline for developers and development security teams to quickly identify any changes between builds that might have been injected by a malicious actor (internal or external). Having a proper (centralized) system for tracking software development from initial development to compilation on top of an available SBOM would have allowed for detection of the changes made to SolarWinds Orion before it did so much damage. This baselining and testing in the pre-compilation phase can also identify any unusual characteristics and vulnerabilities before a build is pushed out.
If we combine requiring an SBOM into standards like SOC (1 and 2) along with proper application penetration testing this will have one of two effects, either companies will start to actually work to secure their tools and software, or they will fail in the market removing a player that leaves the market insecure. This might sound harsh, but when you look at the security landscape you will see that not having these items in place and available for purchasers has created a target rich environment for attackers.
Now for those that say we cannot implement SBOMs because we are not ready, or the tools are not in place; you must start somewhere and sometime, and it should be now. Yes, creating this is not going to be easy, but nothing truly good ever is. Progress is hard, but not taking steps to create a more secure environment is not doing anyone any good. There are multiple tools and companies that have products to assist in getting this critical part of security off the ground and going. We will be looking at some of them. We hope to show the key components to these tools and give an insight into their vision of how to properly meet this strategic goal in a tactically and logistically sound way.
