Today’s biggest threats to critical infrastructure may come from the digital world. In early May, a ransomware attack on Colonial Pipeline disrupted the distribution of gasoline and jet fuel across the eastern seaboard. Just months before that, it was discovered that threat actors believed to be working with the Russian government gained access to multiple federal agencies by exploiting Solar Winds.
Governments and regulators are taking notice–and taking action. On May 12, the Biden Administration issued a new, and highly-anticipated Executive Order (EO) in response. While its initial impacts will be felt most directly by government contractors, other industries can consider this EO a bellwether to better understand the direction of future regulations and standards.
One topic getting much-needed attention In the EO: supply chain security. Today’s connected device firmware and software applications are patchwork quilts of code from many sources, and third-party code is dominant. Typical device firmware contains only 5-20% first-party code. The rest is assembled from components–much like a car is assembled from prefabricated components in a factory.
In a car factory, a BoM (Bill of Materials) represents a listing of every component that went into a particular vehicle. The digital equivalent is an SBOM: a Software Bill of Materials, with a comprehensive inventory of all software components in applications or firmware.
President Biden’s EO includes a provision that would require software vendors selling to the federal government to maintain an SBOM — a provision that many in the cybersecurity world anticipated, and advocated for in recent years.
In theory, SBOMs should present a comprehensive look at risk: if we can see which components are utilized, we can determine which vulnerabilities are present in the code and mitigate them before they can be exploited.
Unfortunately, it’s not that simple. Three major issues stand between most organizations and an SBOM they can trust:
Vendor trust & knowledge: SBOMs are typically developed by vendors. This requires an organization to trust the vendor regarding what components they are providing. This can go wrong in two ways: a well-intentioned vendor could provide what they believed was a complete SBOM which was incomplete, or in the worst case, a relationship of trust could be exploited by a malicious vendor or attacker.
SBOM standardization: For an SBOM to empower and inform organizations, it needs to be understandable and comparable. Today’s SBOMs can suffer from inconsistent naming issues due to manual data entry, an inability to indicate when a component is present but has been modified, and formatting issues. For example, not all software and third-party libraries can be expressed in the format of <software component name> <version number>. This is the reason that RIPPLE20 was so hard to detect – there is no strong versioning system for the Treck IP stack, and it could be configured wildly differently based upon the implementation. We see similar issues with poorly ‘versioned’ Linux kernels being modified and configured per endpoint; which makes vulnerability information hard to accurately list.
Supply chain compromise: Even when organizations require an SBOM, attackers can undermine that system by ensuring the compromise happens later in the cycle (e.g. SolarWinds Orion). Even having a complete and accurate SBOM cannot protect against certain supply chain exploits or configuration issues.
Getting more from your SBOM
They may not be perfect, but SBOMs are a viable and important security practice. Just like in the car factory, SBOMs make it easier to identify and trace impacted products when problems are discovered. When a new software vulnerability is disclosed, the SBOM makes it easier to examine networks, devices, and software for its presence.
Even when an SBOM is inaccurate or incomplete, the vast majority will remain true. This means that even imperfect SBOMs can lessen the overall risk by identifying relevant components when security vulnerabilities become known.
However, an incomplete SBOM can give a false sense of security if organizations do not understand its limitations, leaving them open to unanticipated attacks from devices they believed to be secure.
Here’s the good news: we don’t have to accept SBOMs with flaws.
The key to getting the most out of SBOMs lies in making their production scalable, automated, and machine-readable. If an SBOM is created through a manual process, it is almost certainly subject to errors. It’s far easier to trust an SBOM when it was produced automatically by a third party using widely accepted tools.
In a perfect world, companies would not only provide one SBOM: their customers would demand a new one for each update, created by a trusted third party. More robust tooling could be used by manufacturers, as well as customers and end-users, to discover vulnerabilities throughout the supply chain For embedded systems and critical infrastructure, tooling that is purpose-built for firmware analysis is required, as existing AppSec tooling is incompatible with these systems.
A complete and accurate SBOM is just a list of components, a little like a grocery list: the list itself matters far less than what you do with it. If you have no processes to ingest and operationalize the information, its impact on your security profile will be minimal. The true value of an SBOM can only be realized in an organization committed to taking action to identify and remediate vulnerabilities discovered using the SBOM.
SBOMs help organizations take an important step toward visibility – and, as the cybersecurity adage goes, “you can’t protect what you can’t see.” Taking the next steps will require digging into how your vendors’ SBOMs are created, how deep they go, and how to automate SBOM production and analyze software and firmware at each stage of the development lifecycle as devices are readied for market.