On Thursday, May 12, 2021, President Biden signed the “Executive Order on Improving the Nation’s Cybersecurity” (Executive Order). Among other things, the Executive Order set out a need to enhance threat information sharing, update the nation’s cybersecurity infrastructure, and created a “Software Bill of Materials” (SBOM). Understanding the overlap between SBOM and lower-level controls sheds light on how organizations can enhance security.
What is Software Bill of Materials?
According to the Executive Order, the “Software Bill of Materials” is:
a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for more significant benefits through automation and tool integration.
In short, the SBOM acts like the nutrition charts on food packages. Many software companies use open-source code that can’t be validated for continued security.
Additionally, some software companies are “Original Equipment Manufacturers” (OEMs), which means that other companies use their components when building new software. For example, when a Dell or HP laptop includes a Microsoft Windows operating system, Windows is an OEM.
However, not all OEM services are as evident as a Windows OS. For example, a software provider may purchase a tool from another provider and build additional capabilities on top of the purchased software.
Why does the Software Bill of Materials matter to security?
When software and hardware companies “resell” components, the contracts often mean that the end-user does not know all the underlying providers.
Consider this example:
- Software Company A contracts with Software Company B to use their code as a component of the Product.
- When a company buys a Product, they only know the about the components that Software Company A tells them.
- Software Company B’s component has a security vulnerability.
- Software Company A should be monitoring for vulnerabilities that impact Product.
- Software Company B releases a security update to its component.
- Software Company A does not install the security update into Product 1 because it would crash Product.
The customer who bought Product 1 assumes that Company A kept its software up to date. The customer does not know that the Product includes the vulnerable component from Company B.
If malicious actors exploit the vulnerability in Company B’s component, the Product is now at risk. The customer’s risk of a data breach increases.
The customer will be held responsible for the data breach arising from the vulnerability, despite not knowing the OEM component is vulnerable.
Where SBOM and Lower-Level Technical Controls Meet
Lower-level technical controls like CIS Benchmarks and Security Technical Implementation Guides (STIGs) give you the security configuration information you need. These technical controls include the security update patch information necessary for hardening software and firmware.
For example, the NIST National Checklist Program Repository includes secure configurations for most software, firmware, and hardware providers. With SBOM, an organization gains more visibility into and control over the software, firmware, and hardware included in its systems. With more visibility, this means that organizations can incorporate ensuring that these components remain updated as part of their security monitoring.
In theory, an SBOM would give organizations a way to hold their vendors accountable for maintaining secure configurations. However, it’s equally likely that vendors will find reasons not to update software, firmware, or hardware. For example, often, updates to configurations conflict with other software or hardware. A vendor may choose to document or provide a waiver for why it did not apply the security update. As SBOM policy rolls out, organizations should look for how this impacts their current technology stack and whether they need to make changes.
Why is Continuous Monitoring so Complex?
Prev post
