Tuesday, 06 June 2023 11:43

Why SBOM is in the News and Why it is Important

Written by

Reading time is around minutes.

Since Executive Order 14028 came out on May 12th from the Biden Administration there has been a lot of talk about what it means and what are the legal and regulatory ramifications of this order. While the larger conversation is one for a later (and much longer) article the overall tone of the EO is one that highlights a desire to centralize control over cybersecurity at the federal level, but not a lot of direct regulatory changes. Everything is recommendations, or guidelines. There is nothing in EO14038 that makes any real changes. Now that is both a good thing and a bad thing. On the one hand it means that organizations have time to adapt to the tone and general message of the EO and new cybersecurity requirements, and on the other hand, as we are already in an election cycle, many companies are likely to adopt a wait and see attitude towards any changes. One area is around SBOM, or Software Build of Materials.

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.

Read 338 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.