NSA releases guidance on SBOM management to strengthen cybersecurity supply chain

The U.S. National Security Agency (NSA) released the Cybersecurity Information Sheet (CSI) in response to an increase in cyberattacks on supply chains over the past five years, including targeted attacks on software supply chains. The CSI provides network owners and operators with guidance for incorporating effective SBOM management to help protect the cybersecurity supply chain, with a focus on and some additional guidance for national security systems (NSS).

Titled ‘Recommendations for Software Bill of Materials (SBOM) Management, the guidance includes recommended SBOM tool management functionality that supports the Director of the NSA in his role as the National Manager for National Security Systems, namely to provide better Cybersecurity Supply Chain Risk Management (C-SCRM) for NSS owners and operators. The CSI encourages NSS owners to implement a robust C-SCRM SBOM management strategy that ensures the authenticity, integrity, and trustworthiness of software products.

Effective SBOM management leverages the identification of software components to mitigate cyber risk and support improved cybersecurity throughout the software’s lifecycle. According to the CSI, SBOM management should proceed in three steps. First, examine and manage risk before acquiring software. Second, analyze vulnerabilities after deploying new software. Third, implement incident management to detect and respond to new software vulnerabilities during vital operations.

“As Software Bills of Materials become more integral to Cybersecurity Supply Chain Risk Management standards, best practices will become critical to ensuring efficiency and reliability of the software supply chain,” Rob Joyce, NSA cybersecurity director and deputy national manager for the NSS, said in a media statement. “Network owners and operators we work with count on NSA to advise them on shoring up their defenses. These guidelines provide the information they need to select the appropriate tools to reduce an organization’s overall risk exposure.”

Fundamental to C-SCRM is leveraging a ‘list of [software] ingredients’ to understand and mitigate the cyber risks that software can pose to a user organization. SBOMs and SBOM management tools bridge this gap to support an improved cybersecurity posture. Specifically, users should leverage SBOMs, as part of a cybersecurity tool suite, to make risk management decisions about acquiring and deploying software, vulnerability management decisions about software deployment and ongoing operations, and incident management decisions to detect and respond to new software vulnerabilities during vital operations.

The software provider community and their consumers should mature the mode of SBOM exchange to protect the intellectual property and product security of the software suppliers while ensuring authenticity, accuracy, timeliness, and efficiency of SBOM information transfer to software consumers. 

Both industry and government entities should expand SBOM research to better understand the minimum requirements for an SBOM to be beneficial, and share best practices to standardize solutions for other technology platforms susceptible to cyber supply chain attacks (for example, operational technology (OT), cloud/SaaS operations, hardware/firmware).

The NSA guidance also called upon software developers to take ownership of their customers’ security outcomes rather than treating each product as if it carries an implicit caveat emptor. President Joe Biden’s May 2021 Executive Order (EO) 14028 and NSM-8 lay the foundations to enable users of NSS and other critical systems to require software technology providers to make their products ‘Secure by Design and by Default.’

SBOMs and SBOM management tools play a part in enforcing the requirement to make software secure by design, as they provide a mechanism to determine software component risk and establish a level of confidence in the software’s freedom from vulnerabilities. 

The guidance called upon software consumers should leverage the various resources to ensure their suppliers are designing, developing, and delivering secure software. 

It referenced the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-218 that covers Secure Software Development Framework (SSDF), or an alternate secure software development framework that encompasses and expands on it to accommodate NSS-specific considerations. It also covered the Office of Management and Budget (OMB) Memorandum M-23-16, which updates OMB Memorandum M-22-18, requiring all federal agencies to use only software suppliers that comply with NIST SP 800-218. The Software Component Verification Standard (SCVS) provides additional resources that help NSS users drive the requirement for SBOM data upstream to software supplier sources to ensure as complete and accurate as possible information about software component dependencies. 

The NSA guidance identified that software consumers can also leverage controls identified in the Enduring Security Framework (ESF) Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption and from Open Web Application Security Project (OWASP), in addition to the Cybersecurity and Infrastructure Security Agency’s (CISA) draft Secure Software Development Self-Attestation Form.

It also covered further guidance from collaborations among CISA, the National Telecommunications and Information Administration (NTIA), the National Manager for NSS, and the cybersecurity community that establishes common practices and standardization for automation of SBOM management. 

The National Manager recommends that NSS owners develop and require contract language for the inclusion of software component information containing, at a minimum, the NTIA required field for each component in all delivered software. Additional component details should be requested and required as the state of the industry matures. This requirement includes expecting a supplier to enumerate third-party software dependencies (both open source and proprietary) incorporated into the supplier’s product. 

The guidance also called for the identification of runtime or other dependencies for software operation that are not specifically part of the software components listed in the SBOM; inclusion of a container manifest should be required for all software with container components; and the use of digital signatures or authenticated hashes to validate component (and SBOM) integrity. 

It also identified that for NSS-related software specifically developed under contract, the SBOM should be generated using source code from the build stage. “If not included in the SBOM itself, runtime dependency information must also be documented and provided as part of the software deliverable. For all delivered software, whether the software is acquired or developed under contract, NSS owners should verify the accuracy and completeness of the SBOM utilizing an SBOM management tool as part of its delivery acceptance.”

The NSA document also said that for delivered software binaries, NSS owners should seek contract agreements that provide the NSS owners limited rights to reverse-engineer the software for the specific purpose of validating SBOMs and resolving any discrepancies in a mutually agreed-upon manner. “Inclusion of contract metrics that enable tracking and assessment of the software suppliers’ ‘secure by design’ performance,” it added.

Earlier this week, U.S. security agencies published a cybersecurity technical report (CTR) that expands on a June 2023 memo from the Office of Management and Budget (OMB). The memo focuses on strengthening the security of the software supply chain, including open-source software (OSS) and SBOM, by promoting secure software development practices. The report guides individual developers and large industry companies, helping them adopt and maintain secure software supply chain practices to mitigate potential risks.

Anna Ribeiro

Industrial Cyber News Editor. Anna Ribeiro is a freelance journalist with over 14 years of experience in the areas of security, data storage, virtualization and IoT.