We can’t wait for SBOMs to be demanded by regulation

Old ads can be startling—cigarette ads used to boast their health-giving properties, sugar-laden candy was once advertised as a dietary aid, and soft drinks were advertised as a milk alternative for babies. None of this would fly today, of course, thanks to regulations. Foods must be advertised more responsibly, and they must list their ingredients clearly on the packaging, especially allergens.

Software bills of materials (SBOMs) are like ingredient lists for software. No software is created out of whole cloth, and an SBOM will list the building blocks used to create it. And just as anyone with a food allergy needs to be able to scrutinize the list of food that has gone into their microwave-ready meal before eating, so businesses need to know not just what software is in use, but what software their software is using.

The need for SBOMs

Bills of materials (aka component lists, aka product recipes) are common in manufacturing. A BOM is a structured, standardized list of everything needed to manufacture a product, the quantities, and how to obtain them. They’re vital in planning purchases and minimizing delays—no efficient manufacturer wants to be stuck with warehouses full of components while waiting for vital parts to arrive. It’s also the first point of call if there’s a fault or other issue.

SBOMs work in a similar way. A 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 licenses, and the patch status of each component. Just as in manufacturing, this becomes a key reference material when something goes wrong. A manufacturer that discovers a faulty component can tell which of its products may need to be recalled. A business that makes use of open-source software can tell immediately where vulnerabilities may lie if something goes awry.

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 it a CVSS (Common Vulnerability Scoring System) rating of 10, the highest possible.

The advice to keep everything up to date is good but only goes so far. Different types of software are updated at different cadences, so there was no guarantee that waiting for a patch was good enough. It was also possible to attack servers that were regarded as internal and not usually vulnerable to such attacks, and likely regarded as less vital to patch.

An SBOM is incredibly valuable in this situation, giving security teams a handy ready reckoner showing where vulnerabilities lie when they arise.

Waiting for regulation

We need SBOMs. The good news is that regulations demanding SBOMs are in the works in the US and elsewhere. The US government has demanded that federal agencies adopt SBOMs in a standard format, but whether this is necessary is based on the “criticality of the software”.

The EU has the proposed Cyber Resilience Act, and the UK is looking to bring managed services providers into the scope of current laws that already apply to critical infrastructure.

But as with any regulation, there are a lot of maybes and caveats as they wind their way through legislative bodies. There is a worry that requirements might stifle innovation, and that smaller businesses may be hampered by extra red tape. These new cybersecurity rules are as much in response to supply chain attacks such as the SolarWinds hack and are more likely to target those big providers that underpin so much of IT today.

Our advice is not to wait for regulation and to enact policies that act as if strict demands on SBOMs already exist. Act as if a G-man wielding strict regulation were to arrive unannounced tomorrow and demand to be shown this documentation.

There are standards in place that can make this simpler— the SPDX format should be used unless there’s a very good reason not to, as it’s well-known and an ISO standard.

What’s most important is that a system is used where one can rapidly find components that may have vulnerabilities. Generating SBOMs should be done via build-time methods, typically using a CI/CD pipeline, meaning the SBOM will always be up to date. One should be generated for each version produced, so older versions that may still be used can be checked if necessary.

There is a risk that demanding vendors to turn over their SBOMs means exposing their secret sauce—the programs they use to build their solutions, a potential issue for competition. Regulations can go too far, and bad regulation is possible if self-regulation isn’t taken seriously enough.

Neither developers nor security teams can wait—they need to implement and demand SBOMs now, normalizing them ahead of the next big hack. This isn’t just about security, it’s about partners and customers having confidence in your ability to respond to unexpected events or vulnerabilities. When the next CVSS Level 10 event hits, the ability to say “don’t worry, we’ve got this” will be invaluable.