Do You Have an SBOM Strategy? Gartner Predicts Sharp Rise as a Critical Infrastructure Requirement.

Don’t have a Software Bill of Materials (SBOM) security strategy yet? Well, it’s a good time to start preparing one. SBOMs began to gain momentum as a requirement after the White House issued an Executive Order in May of 2021 requiring the development of the new 2022 NIST SBOMs standards and encouraged it as a requirement in federal contracts. Following those developments, a memo was issued in September of 2022 that requires agencies to get self-attestations or SBOMs from software providers. But Gartner predicts that “by 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice, up from less than 20% in 2022.” Let’s look at how SBOMs can reduce any organization’s risk and why you and your customers may soon require these documents as part of a new contract.

What is an SBOM?

According to the United States’ Cybersecurity and Infrastructure Security Agency (CISA), a “software bill of materials” (SBOM) has emerged as a key building block in software security and supply chain risk management. An SBOM is a nested inventory; it’s a list of ingredients that make up software programs and services. Most software programs use some open-source components and code libraries, and an SBOM should be a detailed inventory of every code library and component used so you can quickly determine if you are impacted when a vulnerability in a popular and widely used software library is discovered.

Securing open-source software is now a major issue for the US government and businesses. This comes as no surprise since open-source software accounts for 70% to 90% of code in web and cloud applications. All this drives the need for SBOMs as part of a strong overall security strategy. Let’s dig into this issue and find out how you can incorporate these software inventories into your security action plan.

Growing Open-Source Software Risk

The problem isn’t software vulnerability alone; it’s also knowing exactly what components make up the software you have installed. Without an SBOM, you might not be aware of vulnerable code hiding in your applications. Take the Log4j vulnerability for example. As a widely used logging tool, Log4j is found in tens of thousands of Java software artifacts. However due to lack of transparency, many security professionals are unaware that Log4j is part of their software supply chain.

Most of this complexity is due to the rise of open-source software (OSS). In the Linux Foundation SBOM and Cybersecurity Readiness report, 98% of organizations surveyed use OSS. This means a plethora of new apps get built, packaged, and sold, but without an SBOM, the exact software components aren’t well defined. And if you don’t know what’s in your supply chain, how can you patch it? How can you be secure?

SBOMs Help You Quickly Remediate Risks 

The threat of vulnerabilities (both known and zero-day) combined with the unknown contents of software packages has led security regulators and decision makers to push for the development of software bills of materials.

Once you have a detailed list of individual software components, you can quickly and accurately assess risk exposure. For example, you can begin to match your list against CISA’s Known Exploited Vulnerabilities Catalog. Or if you hear about an emerging mass exploit like Log4j, you can quickly check to see if your stack is at risk. If you don’t have an SBOM, you’re in the dark until you are notified by your vendor… or until you get hacked.

It’s estimated that 98% of codebases use open-source software components. Let’s dig deeper into what the Linux report found regarding organizational SBOM readiness and adoption in the third quarter of 2021 shows us. Of the total 412 organizations who participated in the survey:

• 76% have a level of SBOM readiness
• 47% are using SBOMs
• 78% plan to use SBOMs by the end of 2022 and 88% in 2023

As SBOMs become more readily available, you should incorporate requiring and utilizing these inventories as part of your organization’s supply chain security plan.

Production Steps & Benefits

Software and application makers should produce SBOM security lists as part of their development process. SBOM production should follow these steps:

1. Identify software components: For any software deliverable, start by listing each software component, the baseline component information, and any additional component attributes.
2. Compile data about components: Data includes author, supplier, and component names as well as version string, component hash, unique identifier, and relationship.
3. Import component data into a structured inventory format: Software component transparency improves when SBOM data can be generated, shared, and processed by machines. SPDX (an open-source machine-readable format) and SWID (an international XML-based standard) are two widely used formats.
4. Validate and ensure the format is valid: Check to make sure your SBOM format is valid (necessary fields are present, proper document structure, etc.). Both SPDX and SWID provide validation tools.

According to the Linux report, the key benefits of producing these inventories include:

• Understanding dependencies: Modern software applications have many components, and each component can have several to many dependencies. SBOMs provide explicit identification of dependencies, which is increasingly useful as the complexity of components in an application grows.
• Monitoring components for vulnerabilities: In global threat analysis, new vulnerabilities are continuously discovered while existing vulnerabilities are mitigated. SBOMs help monitor your current vulnerability status for improved security resource allocation.
• Managing license compliance: License compliance is especially important with the ubiquitous use of open-source software.

SBOM Security Benefits

For businesses that purchase and use software, the top SBOM security benefits include:

• Better reporting and compliance: With a well-developed SBOM, software compliance issues can be quickly identified and addressed.
• Improved risk analysis: Compliance, financial, and reputational risk assessment is improved with full visibility into software components.
• Enhanced security exposure understanding: When a vulnerability is identified, this detailed inventory enables you to immediately assess whether your tech stack is exposed.

SBOM Strategies Continue to Evolve

Across all industries and sectors, SBOM readiness, production, and requirements are in the process of being operationalized, according to Linux. Also, solutions are emerging, but consensus has yet to materialize around a particular methodology, format, and tooling workflow.

For any organization, a good first step would be to begin to compile your own SBOM strategy, including requesting an SBOM from all new vendors. Meanwhile, the National Telecommunications and Information Administration provides in-depth guidelines for establishing a common software bill of materials. 

Contact us if you need help defining or updating your cybersecurity policies and procedures. Our team is ready to assist you!