Software Bill of Materials (SBOMs) for Supply Chain Risk Management

How to defend against software supply chain attacks?

The recent increase in attacks like Kaseya and SolarWinds prompted the Biden administration’s May 2021 Executive Order on Improving the Nation’s Cybersecurity. The Executive Order specifically addresses software supply chain risks, stating, “the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.” While it won’t be a complete solution, a key aspect of improving the security of the software supply chain is the creation of a Software Bill of Materials (SBOM).

What is a Software Bill of Materials (SBOM)?

The Executive Order defines SBOMs as, “a formal record containing the details and supply chain relationships of various components used in building software… it is analogous to a list of ingredients on food packaging.” 

The benefits of SBOMs are well-documented and Gartner even predicts that by 2024, 50% of enterprise software buyers will require a non-negotiable, regularly updated SBOM. In fact, many best in class software organizations already document their own SBOMs through developer tools, just not in an official capacity. But given the reputational and financial repercussions of attacks, software supply chain risks are no longer confined to developers or CISOs, and SBOMs must now serve CEOs.

The Department of Commerce and the National Telecommunications and Information Administration (NTIA) were tasked with creating SBOM standards. Through collaboration with academia and industry, they developed an initial outline of SBOM elements, including: 

1. Supplier name: The name of an entity that creates, defines, and identifies components

2. Component name: Designation assigned to a unit of software defined by the original supplier

3. Version of the Component: Identifier used by the supplier to specify a change in software from a previously identified version

4. Other Unique Identifiers: Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases

5. Dependency Relationship: Characterizing the relationship that an upstream component X is included in software Y

6. Author of SBOM data: The name of the entity that creates the SBOM data for this component

7. Timestamp: Record of the date and time of the SBOM data assembly

The problem with the SBOM hype and why most solutions don’t offer much value

Software supply chain risk is a pressing national security concern worthy of all of the news coverage, but unfortunately, today’s SBOM offerings don’t actually offer much value. The effort from government agencies to develop SBOM standards and the speed at which industry players are attempting to roll out SBOM solutions is admirable, but the Department of Commerce and NTIA emphasize that these SBOM elements are only the beginning. 

Where most SBOMs fall short:

1. Overwhelming laundry list without intelligence: Identifying software components and mapping vulnerabilities across dependencies is the bare minimum for SBOMs. It’s an important starting point, but without business or threat intelligence, the SBOM quickly becomes useless.

2. Scope is too narrow, critical risks aren’t captured: 

   1. Most SBOM offerings only consider components or component dependencies, but code-level insights are necessary for visibility into vulnerabilities and threats at the code level. 

   2. Since getting access to custom or proprietary code is difficult and requires more sophisticated technology, many SBOMs only consider open source software.

   3. Typically SBOMs only report on public vulnerability databases, which fail to identify architecture that’s susceptible to attack or suspicious contributions from a black-listed country. SBOMs should provide comprehensive risk insights including open source composition, code quality/security, provenance, and quantitative software architecture analysis. 

3. Static, point-in-time assessments are immediately irrelevant: Without constant, live monitoring of supply chain risks, SBOMs are immediately outdated and irrelevant.

4. Delivery and consumption of information is ineffective: Software supply chain risk is an enterprise-wide problem. Existing SBOM offerings are either too developer-centric for executives to act on, or too high-level for developers to take seriously. SBOM solutions must be designed to facilitate transparency between stakeholders within organizations.

5. Lack of shareability: SBOMs inherently span organizations. For SBOMs to be effective, they must be easily accessible to suppliers, customers and partners.

Like any new technology, the market for SBOMs is still maturing. Standards must improve, enterprises must commit, and SBOM solutions must advance. Today, SettleTop leverages its expertise and comprehensive platform to deliver an SBOM with more value.