SBOM Management

A look at the NSA's "Recommendations for SBOM Management"

Dec 18, 2023

SBOM’s continue to be a hot topic in the discussion around software supply chain security. For those who aren’t familiar with SBOM’s, they are defined as CISA as:

“A nested inventory, a list of ingredients that make up software components”

Essentially SBOM’s help enumerate the components within a product, software or application, including proprietary and OSS/third-party components. The two predominant formats are The Linux Foundation’s SPDX and OWASP CycloneDX.

For a more detailed deep dive on the two formats and SBOM’s, you can find my article “SBOM Formats SPDX and CycloneDX Compared” on CSO Online.

Despite tremendous media and industry attention to SBOM’s as well as efforts by U.S. Federal agencies such as NTIA and CISA, most organizations are still in their infancy of exploring the concept of SBOM’s and integrating these artifacts into broader Cybersecurity Supply Chain Risk Management (C-SCRM) programs.

If you’re unfamiliar with C-SCRM, I recommend digging into NIST’s “Cybersecurity C-SCRM Practices for Systems and Organizations”, aka 800-161.

This guidance from the NSA looks to equip organizations with guidance on SBOM Management specifically. To produce the guidance the NSA says they researched and tested various SBOM management tools. The guidance aims to help organizations integrate SBOM’s into various C-SCRM activities, such as Risk, Vulnerability and Incident Management, as they depict below:

They define the three as follows in the context of SBOM/Software Supply Chain:

Risk Management - determining the authenticity, completeness, and trustworthiness of software being acquired and used to determine software suitability for use.
Vulnerability Management - allows IT security teams to adopt a more proactive security posture by identifying and resolving vulnerabilities before they are exploited.
Incident Management - Aims to reduce the organizations overall risk exposure, whether that occurs as part of the procurement process or operationally, once an incident has occurred.
Thanks for reading Resilient Cyber! Subscribe for free and join nearly 4,000 other readers to receive new posts and support my work.

Recommendations

The recommendations section is brief, with some key takeaways for software suppliers and consumers.

Suppliers:

NSA recommends suppliers look to mature SBOM exchange to enable transparency to consumers while also protecting IP.
Calls for both gov and industry to expand SBOM research to determine minimum requirements to make SBOM beneficial and share those best practices
Pushes for software suppliers to take ownership of customers’ security outcomes rather than treating products as they have an “implicit caveat emptor”. Points to efforts such as CISA’s push for “Secure-by-Design/Default”, and the National Cybersecurity Strategy, each of which call for suppliers to take more ownership rather than pushing the burden downstream to consumers. I cover the CISA Secure-by-Design publication in-depth in my article “Secure-by-Design (and Demand)”
One misstep I noted is they used language around using SBOM’s to enforce requirements to make software Secure-by-Design and “establish a level of confident in software’s freedom from vulnerabilities”.
Let’s be very clear here, there are no “requirements” for Secure-by-Design software as of now, it is largely a voluntary push being called on by organizations such as CISA and right now cybersecurity is still largely considered a market failure. Secondly, no software used at scale is ever likely to be “free from vulnerabilities”.
All software is potentially vulnerable and ages like milk, as new research and exploitation activities help uncover previously undisclosed vulnerabilities. The push shouldn’t be for “vulnerability free software” but instead allow consumers to make risk-informed decisions about the vulnerability posture of products and software. It’s also worth noting the 2023 NDAA originally included similar language, before being stripped due to industry outcry.

Software Consumers

NSA recommends the following for software consumers to ensure their suppliers and providing secure products:

Suppliers are using NIST’s Secure Software Development Framework (SSDF) or something similar. I cover SSDF in-depth in this article, for those not familiar with it. The federal government is actually moving via OMB to have ALL software suppliers selling to the U.S. Federal government start to self-attest to following SSDF practices in their software development activities.
Utilizing OWASP’s Software Component Verification Standard (SCVS)

National Security Systems (NSS)

While not applicable to all readers, the NSA guidance goes on to enumerate several recommendations for NSS system owners to integrate such as:

providing SBOM’s that meet the NTIA minimum element guidance
Identify runtime components not captured in an SBOM
Include container manifests for containerized applications
Digitally sign components and SBOM’s for integrity
Require SBOM’s for software developed under contract with NSS’s
Inclusion of contract metrics to ensure suppliers are aligning with “Secure-by-Design” performance objectives

Recommended SBOM Tool Functionality

This section of the guidance is dedicated to recommended SBOM tool functionality for consumer-side SBOM tools. It also points out that most current tools do include all of the functionality they discuss, as the space is in its infancy and continuing to evolve.

It also calls out that not just technical capabilities for SBOM tools should be assessed but also ease of use, reporting for the appropriate various stakeholders etc.

We will briefly touch on many of the recommendations below but I recommend digging into the source publication for more depth.

SBOM Input - Ability to support all SBOM format versions such as SPDX and CycloneDX, support for JSON, XML and CSV, SBOM syntax compliance, and SBOM normalization and correcting for files being imported.
SBOM Output - Output in both CDX and SPDX, along with exporting into JSON, XML and CSV. Ability to convert between SBOM formats and file types and aggregate multiple SBOM’s into one overarching repository.
SBOM Generation - Generate SBOM’s from various software development process outputs such as build, analysis of binary and so on.
SBOM Component Handling - Display NTIA minimum element fields, enrich SBOM’s with additional sources, graphically represent components and display provenance information
Validation of SBOM and Component Integrity - Capture and display component hashes and digital signatures for SBOM’s, as well as PURL and CPE pointers.
Vulnerability Tracking and Analysis - Provide daily updates from NVD and other vulnerability data, and enrich with cyber threat intelligence and SBOM data enhancement services. Notify users of new vulnerabilities or emerging risks, and enrich with various sources of threat intel as well as provide a dynamic policy engine for customization. Also be able to identify specific endpoints and assets where impacts components exist with associated vulnerabilities. Be able to distinguish between identified versus exploitable vulnerabilities using VEX formats.
User Interface (UI) - Provide information in an easy to assess format and allow further analysis. Support graphical representation of assets of associated vulnerabilities and ability to drive down into components for provenance and vulnerability, licensing and risks.

Conclusion

This publication from the NSA represents some solid guidance for organizations looking to make use of SBOM’s as part of their C-SCRM activities in areas such as Vulnerability, Incident and Risk Management. It also provides key recommendations as organizations look to analyze various SBOM platforms and tools to assist in their management of SBOM’s, including ingestion, enrichment, analysis and reporting.

Thanks for reading Resilient Cyber! Subscribe for free and join nearly 4,000 other readers to receive new posts and support my work.