It's human nature to resist regulation: even if we know something is for the best, we don't like it forced upon us. 

The US government mandated regulation around Software Bills of Material (SBOMs), with the production of "recipes" for software. Essentially, the building blocks to creating a smarter method to identify potential security issues. It comes as no surprise that there are negative reactions and sentiments around this regulation.

The response from the ITI Council, a who's who of tech big hitters, has described SBOMs as "not ready" and that the whole conversation needs to be more "mature" before the IT industry can consider the extra burden of creating and maintaining these records—especially as the rules don't stipulate the standards to be used.

It's a very questionable approach. The IT sector should not be resisting this regulation but should be welcoming it, leading its implementation, and creating a mature discussion around it, not just waiting for it to happen.

The case for SBOMs
Bills of materials are not a new idea. Also known as component lists or product recipes, they are common in manufacturing—a structured, standardised list of everything needed to manufacture a product.

In manufacturing, they're vital for planning purchases and also the first point of call if there's a fault or other issue. If a component is found to be faulty, then it's easy to identify any product that used that component and start the process for a recall or whatever action is appropriate.

An SBOM is a list of all the open-source and third-party components present in a piece of software, but also more than that: it contains the version numbers, the licences, and the patch status of each component. Just as in manufacturing, this becomes a key reference material when something goes wrong. A business that makes use of open-source software can tell immediately where vulnerabilities may lie if something goes awry.

This is important as, no matter how professionalised open-source becomes, it is built on a community and hobbyist foundation that must always be kept in mind. So, while the biggest names in tech may be developing tools with open-source principles and hosting them on open-source platforms, they are building on code that may have been put together as a side project and is not as actively maintained as other code.

The Log4Shell vulnerability is a perfect example. Log4j was used, as the name suggests, to log errors and events and communicate them to admins. If someone visits a website and receives a 404 error, that would likely be logged by Log4j—if many of these are happening, it points to a problem. Its usefulness made it ubiquitous, and this made it, perversely, rather obscure—a default piece of software used everywhere that no one really thought about. When it was revealed that Log4j could be used to inject code, it meant that millions of servers could be attacked and taken over. The NIST vulnerability database gives Log4Shell a CVSS (Common Vulnerability Scoring System) rating of 10, the highest possible.

The ubiquity of Log4j meant that, perversely, it was easy to know if a patch was needed—almost every server needed an upgrade. Future vulnerabilities may not be so widespread, but still common, making SBOMs extremely valuable.

The need to lead rather than resist
Much of the pushback against SBOM regulation has mainly been one of practicality rather than principle. The ITI Council response said that "currently available industry tools create SBOMs of varying degrees of complexity, quality, completeness. The presence of multiple, at times inconsistent or even contradictory, efforts suggests a lacking maturity of SBOMs."

It is true that there are multiple ways to produce an SBOM, so there is no one standard that every business and organisation can, at the moment, adhere to. But this is where the technology giants should be leading rather than kicking the can down the road. Rather than simply shrug and say that this is impossible, it should decide what the best standard is and, adopt it, and look for ways to bridge the gap between these different standards if needed.

The worst-case scenario, if this lobbying fails, is that SBOMs are mandated without a standard, meaning everyone who needs to create them simply chooses a method and uses that to meet the demands of the regulation. Standardisation will come eventually, as it always does, as one tool is adopted by most of the industry and wins out simply by being more popular. This, however, will take time, possibly years, and will be costly for those businesses that need to change their system.

While this happens, we may see another vulnerability on the scale of Log4Shell. If that happens, the US Government will be able to point at its regulation and say that it has mandated this change for the industry. If the SBOM protocols that have been implemented are not up to the task and don't underpin the response necessary, the industry will be caught out by something that is more or less inevitable.

SBOMs will be key to dealing with the next big vulnerability and incredibly useful in the fight to minimise the effects of smaller weaknesses. The problems with adopting SBOMs today should not be seen as a barrier; instead, the IT industry should create a timetable and work collaboratively to solve these issues rather than pushing back on any attempts to legislate. The lobbying attempts should focus on how this works rather than if it happens at all.