Limit Software Bill of Materials to Prevent Cyberattacks

Understanding Software Bills of Materials (SBOMs) and Cybersecurity

A key component of the May 2021 White House executive order focused on enhancing U.S. cybersecurity is the requirement for a software bill of materials (SBOM). This represents a formal record detailing the constituents and supply chain connections inherent in software product construction.

What is a Software Bill of Materials?

Essentially, an SBOM is a comprehensive inventory of all elements required for application development. It details all components, encompassing open-source software (OSS) dependencies – both direct and transitive – alongside open-source packages, vendor agents, and vendor software development kits (APIs).

Software is frequently built by developers and vendors through the integration of pre-existing commercial and open-source components, as highlighted in the executive order. This information is valuable to developers, purchasers, and those responsible for operating the software.

Benefits of Implementing SBOMs

An SBOM empowers software developers to verify the currency of open-source and third-party components. Purchasers can leverage SBOMs for vulnerability and license analysis, facilitating risk assessment. Furthermore, software operators can quickly ascertain potential exposure to newly discovered vulnerabilities using SBOM data.

The executive order emphasizes that a standardized, machine-readable SBOM format maximizes benefits through automation and integration with various tools. Storing SBOMs in a readily searchable repository further enhances their utility for analysis and vulnerability management. Understanding a software’s supply chain, obtaining an SBOM, and analyzing known vulnerabilities are all vital for effective risk mitigation.

The Hierarchical Nature of SBOMs

An SBOM is inherently structured hierarchically. The finished software product resides at the apex, with all its dependencies forming the supporting layers of its functionality. Exploitation of any component within this structure can trigger cascading effects.

Discussion and Concerns Regarding SBOM Mandates

The proposed SBOM provision has generated considerable discussion since the executive order’s release, particularly within the cybersecurity sector. Past incidents, such as the breaches at Equifax and SolarWinds, which exploited software vulnerabilities, have renewed interest in this concept.

The intent behind SBOMs is undoubtedly positive. The idea is that if software vendors aren’t proactively updating dependencies to address security flaws, requiring them to disclose their dependency lists might incentivize better maintenance practices, driven by the potential for negative publicity.

Challenges with a Traditional SBOM Approach

However, this approach may be based on an outdated understanding of modern software development. Contemporary applications and microservices architectures often rely on a multitude of dependencies. A relatively small application can easily incorporate dozens of dependencies, each potentially relying on others.

Consequently, the total number of dependencies for a single application can quickly reach hundreds, and for systems comprised of hundreds of microservices, the number can climb into the thousands. Publishing such extensive lists presents practical challenges.

Even if vendors also publish a list of vulnerable dependencies – potentially numbering in the hundreds – the benefit to end-users remains questionable. Upgrading hundreds of vulnerable dependencies is a substantial undertaking.

Economic Considerations and Potential Unintended Consequences

Software vendors constantly balance the need to add new features with the effort required to maintain existing dependencies. Financial penalties for vulnerable dependencies might lead vendors to simply pay the fines rather than invest in costly upgrades, especially if those upgrades risk hindering revenue generation or competitive positioning.

Economic realities often dictate decisions; revenue and market capitalization drive compensation, while fines have a minimal impact on the bottom line. Furthermore, vendors may be reluctant to disclose their entire dependency list, as this information could be valuable to both malicious actors and competitors.

Focusing on Vulnerable Dependencies

Customers don’t necessarily need to know every dependency; they need to know which dependencies introduce vulnerabilities. The crucial question is identifying the components that pose an actual risk.

The Power of Software Composition Analysis (SCA)

Prioritizing software composition analysis (SCA) ensures that dependency analysis is focused on identifying those components that create vulnerabilities, significantly reducing the scope of required remediation. Instead of publishing lists of hundreds of dependencies, or even hundreds of vulnerable ones, organizations can provide a far more manageable list – ideally in the single digits.

In some cases, vulnerabilities can be addressed through code modifications without requiring dependency upgrades. This offers a more targeted and efficient approach to security.

A Balanced Approach to SBOM Implementation

The concept of SBOMs should not be dismissed. Vendors should be held accountable for transparency regarding their software’s composition. Numerous organizations have suffered significant consequences due to preventable software vulnerabilities.

The federal government’s commitment to cybersecurity is commendable, and proposals to enhance application and data protection are welcome. However, focusing SBOM requirements on the list of dependencies that *actually* introduce vulnerabilities is crucial.

This approach benefits both vendors and customers by directly addressing the sources of risk, avoiding unnecessary burdens and fostering a more effective cybersecurity posture.