The Rise of the Software Bill of Materials (SBOM)

Governments continue to make strides towards greater technology supply chain security, particularly related to devices connecting to Federal networks, as we move towards a “zero trust” cybersecurity posture. But what about software? How do we know the code in software is not compromised, particularly as systems become exponentially more complex and integrated.?

In recent years, a "software bill of materials" (SBOM) has emerged as a key building block in software security and software supply chain risk management. A SBOM is essentially a detailed inventory of what makes up a software’s components. The concept isn’t new; it is essentially built on the manufacturing processes utilized by many industries (automotive, telecommunications, etc.). However, the Federal government is driving greater adoption beyond early adopters such as the financial services and healthcare industries. NTIA and CISA will be working to expand the utilization of technologies, scaling, operationalizing, and facilitating community engagement.

The whitepaper from the Atlantic Council aims to address some of the concerns around SBOM adoption and strengthen the argument for them to be utilized as a source of data for important risk management decisions.

?Some of the key takeaways:

·????????An SBOM is a snapshot in time of each component making up a piece of software, with additional metadata tracking provenance (information about component authors and affiliations) and versioning.

·????????SBOMs are intuitively useful but represent just one piece of a larger toolkit for managing risk in software systems.

·????????SBOMs can help compliance officers streamline licensing acquisition and manage the adoption of components produced by sanctioned or entity-listed companies

·????????At the largest scale, they can map out portions of the software ecosystem, highlighting little-known relationships and concentrations of dependence, while shedding light on the benefits of using extant code and the risks of relying on external repositories.

?Foundational use cases:

·????????Procurement: reducing compliance burdens and preventing duplicative purchases

·????????Vulnerability Management: validating vulnerabilities and mitigating risks

·????????Incident Management: mitigating risks and mitigating opportunities

?Vulnerability Management and Incident Response

·????????Vulnerability management: tracking vulnerabilities, relevant threat intelligence around dependencies, preemptive response planning, and determining whether a vulnerability impacts an enterprise.

?Expanding Vulnerability Management and Threat Intelligence

·????????While insufficient for high-security organizations, SBOMs are workable substitutes for medium or small enterprises that lack the in-house expertise to analyze all their software in depth

·????????SBOM unaltered data can serve to inform and define procurement standards and policies alongside risk-management posture

·????????They provide a roadmap through software relationships that enable this degree of dedicated care

As Congress enters the 118th session, it is imperative that the respective authorizing committees investigate the use cases for SBOMs. If effectively tracking physical components has proven to be effective in so many industries, applying similar capabilities to software should be a priority in both the public and private sectors if we are to achieve a viable level of "zero trust."

?#cybersecurity #cloud #software #datasecurity