Navigating Compliance Requirements with Software Bill of Materials

A software bill of materials has quickly become one of the most important tools for tackling compliance and improving software supply chain risk management. They provide a comprehensive breakdown of a software’s components, dependencies, and open-source licenses, enabling stakeholders to identify vulnerabilities and take proactive steps to mitigate risks.

In this article, we’ll dive into the significance of SBOMs for cybersecurity and look at the compliance landscape and the industries requiring SBOMs, their formats and essential features, and the best practices for implementing SBOMs.

SBOM compliance landscape overview

The regulatory landscape surrounding SBOMs is evolving rapidly, with various frameworks and standards mandating their use across industries and regions. Entities like the National Institute of Standards and Technology (NIST), the Food and Drug Administration (FDA), and the EU Cybersecurity Act have all issued guidelines or regulations requiring SBOMs in specific contexts. Let’s look at each in more detail.

National Institute of Standards and Technology SBOM guidance

As part of NIST’s SBOM guidance, federal agencies must ensure that any software supplier or contractor can produce SBOMs that conform with the EO and NTIA’s “The Minimum Elements for a Software Bill of Materials (SBOM).”

This means that SBOMs must contain

• Data fields that document baseline information about each component that should be tracked
• Automation support that allows for scaling across the software ecosystem through automatic generation and machine readability
• Practices and processes that define operations of SBOM requests, generation, and use

You can read more about NIST’s guidance here.

FDA software bill of materials guidance

The FDA’s cybersecurity guidance relating to SBOMs requires medical device manufacturers to produce a software bill of materials that conforms to the NTIA requirements outlined above. Under this new guidance, the FDA can refuse to accept submissions that don’t possess the proper cybersecurity controls.

The guidance states that applicants must

• Have a plan in place to monitor, identify, and address post-market vulnerabilities swiftly
• Maintain strong, reliable processes to ensure devices and systems are secure, updating as needed
• Provide an up-to-date SBOM that covers all commercial, open-source, and off-the-shelf software components

You can read more about the FDA’s cybersecurity guidance here.

The European Union’s Cyber Resilience Act

Under proposed changes to its Cyber Resilience Act (CRA), the EU outlines a number of cybersecurity regulations, including providing a Software Bill of Materials documenting vulnerabilities and components in the product. This documentation must be accompanied by

• A description of the design, development, and vulnerability handling process
• An assessment of cybersecurity risks
• A list of harmonized EU cybersecurity standards the product meets
• A signed EU Declaration of Conformity that the above essential requirements have been met

The guidelines also outline obligations relating to risk assessments, vulnerability reporting, and conformity assessments, which you can read more about here

What industries require SBOMs?

There are a number of industries that require (or heavily encourage) the use of SBOMs. These include (but are not limited to)

• Healthcare
• Government agencies and contractors
• Critical infrastructure sectors like energy, transport, and finance
• Automotive, where SBOMs are being implemented more frequently as software-driven features in vehicles increase
• Software (not mandated by specific regulations at the time of writing)

Essential features and components of an SBOM

In an effort to improve collaboration and distribution, software bills of materials have two prevalent formats: SPDX (Software Package Data Exchange) and Cyclone DX.

To meet compliance requirements, all SBOMs must (at minimum) include the following:

• Author and timestamp — The document must include who created it and when it was first published/last updated.
• Component version — SBOMs must identify the version numbers of software components to facilitate vulnerability management and patching.
• Supplier information — The document should provide insights into the software components’ origins and sources.
• Unique identifiers — SBOMs should employ standardized identifiers to distinguish between different components.
• SBOM part dependency relationship — The document should lay out the relationships and dependencies between software components to help readers understand the impact of changes or vulnerabilities.

Related: 6 Predictions for the Future of SBOM and Software Supply Chain Security

SBOM best practices

To maximize the effectiveness of SBOMs, organizations should implement the following best practices.

1. Conduct regular audits and assessments of SBOM processes to ensure accuracy and completeness.

2. Integrate SBOMs into their cybersecurity posture and risk management frameworks.

3. Implement mechanisms for ongoing monitoring of the software supply chain, including vulnerability scanning and threat intelligence feeds.

4. Provide ongoing training and educational resources to stakeholders involved in SBOM management to enhance awareness and proficiency.

5. Implement access controls to prevent unauthorized modifications or access to SBOMs.

6. Make SBOMs readily available to relevant stakeholders to facilitate transparency (this includes developers, security teams, customers, and regulatory authorities).

7. Track SBOM changes by implementing version controls and change-tracking mechanisms to maintain a clear audit trail.

Looking to create your first SBOM?

Create, import, manage, and distribute SBOMs in minutes with Finite State.