Does your business need a software bill of materials?

At the end of 2021, a now infamous vulnerability was found in the Apache Log4j open-source logging library. It led to a race against time, with teams struggling to identify which apps and services were affected and apply the patch before attackers could exploit the bug.

As the risk of similar software supply chain threats multiplies, a software bill of materials (SBOM) can help. Essentially an inventory of open source and third party components, an SBOM is now part of regulations including the US Executive Order on Cybersecurity, the EU Cyber Resilience Act (CRA) and the EU Network and Information Systems 2 Directive (NIS2).

How do SBOMs work, and does your business need one?

Why firms need an SBOM

Most modern applications include open source and third party components. As a result, a large share of software risk comes from dependencies that teams did not write themselves.

Latest Videos From

“When a serious issue like Log4j appears, the first question is simple: Where are we exposed?” says Ilkka Turunen, field CTO at Sonatype. “If you cannot answer this question quickly, you have a real problem.”

Log4j is “the prime example of why SBOMs can be indispensable”, says Dana Simberkoff, chief risk, privacy and information security officer at AvePoint. “Because the library is very broadly used in consumer and business-facing software applications, the attack on Log4j had catastrophic consequences for a wide range of applications across regions and sectors.”

An SBOM might have prevented the worst effects of the attack by allowing IT professionals to more easily expose and patch the vulnerability that triggered it, according to Simberkoff.

Visibility into software supply chains

As software supply chain threats become more complex, organizations need complete visibility into the components that make up their applications. This visibility is “critical for security”, says Crystal Morin, senior cybersecurity strategist at Sysdig.

She points out that modern vulnerabilities are being weaponized much more quickly. “So when a vulnerability is discovered in a software component, SBOMs allow organizations to quickly determine whether they are affected and see where that component is in use.”

It comes at a time when the urgency to fix bugs is increasing. In April, Mozilla said it used Anthropic’s Claude Mythos Preview to find and fix 271 bugs in Firefox. Anthropic has argued that teams could find many hundreds of vulnerabilities by applying current frontier models.

As AI super-charges vulnerability discovery, it creates a need for much better visibility into software, says Turunen.

An SBOM performs this task by offering security, engineering and legal teams a shared understanding of “which components are in use, where they came from, and what needs attention when something goes wrong”, says Turunen. “In practice, this means less guesswork, faster coordination, and a better chance of keeping up as both software complexity and vulnerability discovery speed increase.”

Who needs an SBOM

Regulators are now mandating an SBOM across critical sectors. In the US, Executive Order 14028 requires stronger software supply chain security for federal systems, including the use of SBOMs. Meanwhile, agencies such as the National Institute of Standards and Technology (NIST) and the National Telecommunications and Information Administration (NTIA) have published guidance for federal entities and their software suppliers.

The EU CRA, set for full enforcement in December 2027, requires SBOMs for products with digital components sold in the EU. In the UK, the government has introduced SBOM guidance through its Software Security Code of Practice.

The UK’s National Cyber Security Centre (NCSC) encourages organizations to adopt SBOMs to boost software supply chain security. This is despite the fact they are not yet mandated in domestic regulation, says Ritchie Perry, electronics engineer at ByteSnap Design. “The direction of travel is the same: more transparency over what’s in the software you ship, and better evidence that you’re tracking known vulnerabilities.”

Even if you are not in a regulated market yet, there is a good chance your larger customers are – and they will start flowing SBOM requirements down the supply chain, Perry adds.

Industries where SBOMs are most critical are “where the stakes are highest”, says Simberkoff. “For example, software products that interact with critical infrastructure, government agencies and services, and emergency services.”

How to create an SBOM

A typical SBOM consists of supplier name, component name, version, dependency relationship, the author of the SBOM, the time the data was added to the SBOM, and any known risk related to security, legal, and quality. “Together, this information helps secure the intricate and vast systems that constitute software supply chains,” according to Turunen.

Creating an SBOM should be an “automated, integrated part of your software development lifecycle”, says Simberkoff. “It should not be treated as a one-time task because software changes. Every time software is patched or changed, your SBOM should automatically update.”

Most teams will lean on tooling, says Perry. He points out that products such as Black Duck, Snyk, Mend and FOSSA can scan codebases and generate SBOMs.

Meanwhile, platforms such as GitHub and GitLab include SBOM support from their dependency graphs. “These tools are helpful, but not perfect, so it is worth spot checking the output, particularly around high-risk components,” adds Perry.

SBOMs also must be analyzed for risk using threat intelligence and policy rules, monitoring each vulnerability proactively in case it needs to be replaced with a more secure alternative.

To integrate compliance and security throughout business processes, SBOMs must be exported and shared in standard formats for use across teams and external stakeholders, says Turunen.

Turunen also has a warning: “Even if an organization knows what its developers are using, that doesn’t mean their knowledge extends to vendors. This means not just using SBOMs, but requiring them from vendors as well.’’

It’s also important to realize that simply generating an SBOM is not enough. Organizations must take proactive steps to ensure SBOMs are “living assets used to drive better security decisions”, says Turunen.

Keeping SBOMs current is a top priority, concurs Perry. “Components change, dependencies update and new CVEs appear constantly. An SBOM that reflects last year’s build is far less useful than one generated from yesterday’s.”