Understanding the NSA’s latest guidance on managing OSS and SBOMs

Software supply chain security continues to be a critical topic to the cybersecurity and software industry, and for good reason — from continued attacks against large software vendors to attackers’ malicious focus on the open-source software ecosystem by attackers it is front and center for most CISOs and security practitioners. Luckily, organizations continue to produce solid guidance to help practitioners mitigate software supply chain risks. The latest publication, “Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bills of Material,” comes from the US National Security Agency (NSA).

It also builds on previous publications such as the White House Cybersecurity Executive Order (EO) and memos and forthcoming requirements for Federal agencies, such as the Office of Management and  Budget’s (OMB) memos 22-18 and 23-16, which require software suppliers selling to the US federal government to self-attest to aligning with publications such as the National Institute of Standards and Technology’s (NIST) Secure Software Development Framework (SSDF) and even providing SBOMs in some cases.

While the NSA guidance points to previous publications from the White House, NIST, and OMB, this publication is relevant to all organizations producing and consuming software, leveraging OSS, and looking to embrace artifacts such as SBOMs. Here are some of the key areas of the guidance, including recommendations and takeaways from the document.

Structure of the NSA guidance on SBOMs

The NSA guidance focuses on four key areas, as outlined in the table below, and aligned with their respective SSDF Activities. (Area 1 is omitted as it is simply an introduction):

Open-source software management

This section of the NSA guidance defines key roles and responsibilities for developers and suppliers, among others. It notes that developers have responsibilities such as identifying potential OSS solutions to use and integrating OSS solutions into product software, as well as tracking updates to those components. Suppliers are those producing a product or service and performing activities such as monitoring for license changes or vulnerabilities of OSS components included in products, due to the risks they could pass on to downstream consumers.

The NSA lays out primary considerations for using OSS, such as evaluating OSS components for vulnerabilities in sources such as the NVD and other vulnerability databases and ensuring that vulnerable components aren’t being included in products. It also recommends organizations remain aware of licensing considerations such as license compliance, as well as export controls, such as the evolving EU regulations which may impact the incorporation of OSS into products.

The guidance recommends embracing SBOMs as both a means of inventory management of OSS components, as well as transparency for downstream consumers and visibility into the vulnerability posture of the components being included via development into products. SBOMs are a nested inventory of software components and the predominant formats are the Linux Foundation’s SPDX and OWASP’s CycloneDX. The NSA recommends that generated SBOMs meet the minimum element requirements documented in the NTIA’s “Minimum Elements for a SBOM“.

Creating and maintaining a company-internal secure open-source repository

Given how widely organizations are consuming and using OSS, with some studies citing figures from 70-90% of modern codebases being OSS and about 90% of codebases containing some OSS components, another standout recommendation from the NSA guidance is creating and maintaining a company internal secure OSS repository. This repository helps vet OSS components to ensure they meet organizational risk and compliance requirements before being made available to product and development teams.

The NSA recommends using tools such as software composition analysis to identify vulnerabilities as well as licensing concerns before making the OSS components available to developers via the secure repository as demonstrated in their image below:

This of course means the organization needs to define processes to add packages for consumption and the security analysis and documentation needed to allow the addition of packages to the secured repository. It also notes that there may be different policies for environments such as development compared to production releases and recommends aligning with industry frameworks such as the Secure Supply Chain Consumption (S2C2F), which focuses on empowering developers with secure OSS consumption and use.

The OSS adoption process should include activities such as software composition analysis, virus scanning and fuzz testing, occurring in isolated secure environments. There are also recommendations for developers to take other factors into consideration such as licensing, vulnerability history, and the benefits of adopting the components in terms of time and decreased internal development costs. The NSA also recommends using tools such as the OpenSSF Scorecard to analyze the component or The OpenSSF Scorecard of course looks beyond lagging indicators of risk such as known vulnerabilities and looks at aspects such as project code reviews, contributor density, maintenance upkeep and more.

It’s noted that small organizations may have a single secure repository and have developers implementing governance, whereas larger organizations may utilize open-source review boards to review adoption requests and involve a number of stakeholders such as development, management, and security. Recommendations include monitoring repositories of authorized components for new vulnerabilities and remaining aware of which developer groups and product teams have adopted a component so that they can be part of any necessary incident response activities should a component subsequently become vulnerable or compromised.

In an effort to provide context and prioritization to downstream product and software consumers, the guidance recommends suppliers and developers adopt Vulnerability Exploitability eXchange (VEX) documents to help consumers and customers know which components are actually impacted by a vulnerability, which have been resolved, and what should potentially be addressed via compensating controls.

The NSA also recommends suppliers and vendors adopt attestation processes to demonstrate the secure development of a product throughout the building, scanning, and packaging of product development and distribution. This of course is being led by industry efforts such as in-toto and SSDF and self-attestations when machine-readable artifacts are not generated and used. This helps provide assurance of not just the components of an end product but the security of the development process as well.

To address vulnerabilities the NSA recommends using not just CVE and NVD but also other vulnerability databases such as OSV as well as vulnerability intelligence sources such as the CISA Known Exploited Vulnerability (KEV) catalog and Exploit Prediction Scoring System (EPSS). This provides insight into not just vulnerability base scoring and severity but known or likely exploitation as well.

Open-source software maintenance, support, and crisis management

Another key activity emphasized is secure code signing requirements, such as performing code signing, using proven cryptography and securing the code signing infrastructure itself. The NSA also recommends having a crisis management plan in place, building on guidance such as NIST’s Incident Handling Guide. It includes activities such as defining a crisis, structuring how your organization will respond and who will be involved. This is critical to have in place in the event of active exploitation in the wild of an OSS component. This also involves creating and maturing a Crisis Management Team (CMT) along with roles and responsibilities. This team will investigate potential incidents tied to active exploitation, determine if a system or application is affected if the component is within the execution path and determine if a vulnerability can be patched or if compensating controls are necessary.

SBOM creation, validation, and artifacts

This section of the guidance focuses on tools, processes, and considerations for creating and utilizing SBOMs. To effectively use SBOMs, suppliers need to understand how products are built and what components they contain. The NSA guidance breaks SBOM tools into the four categories of source, binary, package, and runtime extractors, given that SBOMs can be created at various phases of the SDLC.

The NSA recommends that an organization verify SBOM contents for accuracy before signing. It also reiterates that SBOMs can be accompanied by documents such as VEX to provide clarity around vulnerable components, activities suppliers have taken to address vulnerabilities, and components that potentially remain vulnerable or exploitable. Since SBOM is an emerging and evolving topic, the NSA points to various resources from SPDX, CycloneDX, and the Linux Foundation, where organizations can learn more about SBOMs, their role, and how they can be used to mitigate organizational risk.

The guidance stresses the speed of malicious exploits, occurring on average 5.5 days after a vulnerability is found and disclosed and recommends utilizing SBOMs within automation pipelines such as CI/CD to automate SBOM generation. It also advises viewing CISA’s resources for SBOM and VEX. For a detailed visualization of how VEX documents and SBOMs work together, see the image below:

This demonstrates how an SBOM can provide transparency of software components and VEX can accompany that from software suppliers to communicate what components are affected or not by vulnerabilities and may require action and mitigating controls by customers and consumers. SBOMs and accompanying VEX documents can be provided to consumers to clearly communicate what OSS components are within a product or application and the VEX can help maximize the use of resources to focus on what aspects of the product are actually vulnerable and the details of potential actions taken by the supplier or vendor.

This addresses a longstanding lack of transparency that has existed between software suppliers and consumers and offers an opportunity to bolster software supply chain security across the ecosystem. For further details on SBOM processes for suppliers, the NSA guidance recommends the NTIA’s “Software Suppliers Playbook: SBOM Production and Provision“.