SBOMs and regulations?
EU – NIS2 Directive, EU – Cyber Resilience Act & US – Executive Order 14028
We need visibility, we need incentives, and we need resiliency. An SBOM won’t give us those, but they enable all of those. In other words, we can’t move forward without SBOMs.
Software Bill of Materials (SBOM) and Cybersecurity Readiness.
The Linux Foundation, Report 2022
NIS2
The NIS2 Directive itself does not explicitly mention Software Bill of Materials (SBOMs), but it does emphasize the importance of strengthening cybersecurity across critical infrastructure and services. One of the ways organizations can enhance their cybersecurity posture is by having a better understanding of the software components they are using, which is where SBOMs come into play.
According to Article 21 (Cybersecurity risk-management measures), essential and important entities must take appropriate and proportionate technical, operational, and organizational measures to manage the risks posed to the security of networks and information systems.
The measures shall be based on an “all-hazards approach” that aims to protect network and information systems and the physical environment of those systems from incidents and shall include “at least” the following:
(a) policies on risk analysis and information system security;
(b) incident handling;
(c) business continuity, such as backup management and disaster recovery, and crisis management;
(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
(f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
(g) basic cyber hygiene practices and cybersecurity training;
(h) policies and procedures regarding the use of cryptography and, where appropriate, encryption;
(i) human resources security, access control policies and asset management;
(j) the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
Cyber Resilience Act (CRA)
The Cyber Resilience Act (CRA) intends to create, oversee, implement, and standardize essential security requirements for software development and in-market software throughout their entire lifecycle.
As the European Union (EU) engages various organizations to develop standards, a key approach related to forthcoming reporting obligations emerges the significance of a Software Bill of Materials (SBOM) within the scope of the CRA.
Manufacturers, developers, and vendors will be expected to demonstrate due diligence and compliance with the EU, and SBOMs will serve as a crucial instrument in fulfilling the Act’s requirements.
Article 37 of the Regulation places the responsibility for identifying software provenance with manufacturers, who must guarantee their software does not contain third-party vulnerabilities, including SBOMs as a key document:
In order to facilitate vulnerability analysis, manufacturers should identify and document components contained in the products with digital elements, including by drawing up a software bill of materials.
When the Act more precisely describes the exact means by which to mitigate risk, it includes SBOMs as a specific requirement to do, in Section 2 of Annex 1:
Manufacturers of the products with digital elements shall: (1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.
US Executive Order 14028
The order, established in May 2021, aims to enhance the country’s cybersecurity by mandating that software vendors supplying the federal government submit a software bill of materials (SBOM) for each product. This order necessitates the automatic generation of software inventories in a machine-readable format, rendering SBOMs that don’t support automation non-compliant.
The Department of Commerce explicitly emphasizes the need for machine readability and automatic generation to facilitate scalability throughout the software ecosystem. Common data formats for creating and consuming SBOMs are SPDX, CycloneDX, and SWID tags.
SBOMs should not only be automated but also dynamic. When assessing SBOM tools, organizations should consider features such as the capacity to create a live inventory of all software components at any stage in the software development lifecycle; the ability to search and identify vulnerable components among billions of files; the utilization of runtime analysis to determine the exploitability of detected bugs in a specific environment; the capability to export and share SBOMs using standard formats; and the continuous real-time monitoring and updating of SBOMs to reflect any introduced changes.
Such guidance shall include standards, procedures, or criteria regarding:
(i) secure software development environments, including such actions as:
(A) using administratively separate build environments;
(B) auditing trust relationships;
(C) establishing multi-factor, risk-based authentication and conditional access across the enterprise;
(D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;
(E) employing encryption for data; and
(F) monitoring operations and alerts and responding to attempted and actual cyber incidents;
(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;
(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;
(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;
(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;
(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process;
(ix) attesting to conformity with secure software development practices; and
(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.