The role of regulation in driving global adoption for software bill of materials (SBOM) may have started with U.S. Executive Order 14028, but make no mistake; this is not a U.S.-only initiative. We have seen regulations from the Payment Card Industry (PCI DSS 4.0), signals from the Australian government, and other global initiatives along with U.S. requirements (like the aforementioned Executive Order along with guidelines from the Food and Drug Administration).
The Cyber Resilience Act (CRA) — a set of rules elevating security standards for digital products in the European Union — is another significant security regulation with a prominent SBOM requirement.
The CRA applies to manufacturers of digital products selling in the EU and any entity such as distributors or importers that market a digital product under their brand. It requires them to share a top-level SBOM with market surveillance authorities as part of the technical documentation provided. Open source software is specifically exempt from these requirements, as are products from certain specific industries, which we’ll discuss later in this blog post.
Some of the details of the CRA’s SBOM requirements are still being worked out through a standards drafting process with CEN/CENELEC (the European Committee for Electrotechnical Standardization) But, at this stage, we know that SBOMs will not need to be publicly shared nor include all dependencies.
CRA Background
The European Cyber Resilience Act is a pivotal piece of legislation aimed at bolstering cybersecurity across the European Union (EU). This act sets forth comprehensive cybersecurity standards for hardware and software products featuring digital elements, ensuring that manufacturers prioritize security throughout the entire lifecycle of their products.
Prior to the introduction of the CRA, cybersecurity efforts in the EU were fragmented, tackled by various national and Union-level initiatives that only addressed these challenges partially. This led to a patchwork of regulations that not only confused manufacturers but also burdened them with inconsistent requirements for similar products.
The CRA specifically targets two pressing issues:
- The generally low cybersecurity levels of products with digital elements, marked by prevalent vulnerabilities and inadequate security updates
- The lack of accessible information for users, which hampers their ability to choose or use products securely
Interestingly, the act acknowledges that any product with digital components, even those deemed non-critical, can be a potential gateway for cyber threats. These products can be the starting point for an attack, allowing cybercriminals to infiltrate a network and move laterally to exploit more systems. This is somewhat in contrast to what we saw in the U.S. government’s EO 14028, where NIST was tasked with defining critical software. The EU recognized that all software can be critical, even if it was not intended to be.
However, the CRA does distinguish between two classes of critical software products known as class I and class II. Digital products contain software, and a product, or product category, represents a specific implementation of software. This is a useful distinction because it is less ambiguous than trying to classify software without an understanding of what it will be used for.
The CRA classifies class II, the more critical of the two definitions, as
“... categories of important products with digital elements which are defined by their core functionality as firewalls or intrusion detection or prevention systems in class II.”
Additionally, it states:
“... categories of critical products with digital elements set out in this Regulation have a cybersecurity-related functionality and perform a function which carries a significant risk of adverse effects in terms of its intensity and ability to disrupt, control or damage a large number of other products with digital elements through direct manipulation.”
Class II products also require more rigorous third-party conformity assessment than the internal control procedures for class I products. The CRA further states these assumptions are predicated upon a harmonization of standards that will occur during the transition period. Like other elements of the CRA, we have a good grasp of where this is going, but there are still some details to work out. The reality is that there is still some time before the applicability date.
The CRA applies to devices like laptops, smartphones, and consumer devices such as IoT, as well as the aforementioned cybersecurity products. It also covers digital electronics such as peripheral devices and graphics cards and even firmware, operating systems, and other software. In short, almost everything we use!
The CRA also has a few notable exceptions, such as heavily regulated industries like automotive since they already have quite stringent requirements. And, software such as software-as-a-service (SaaS) falls under Directive (EU) 2022/2555, otherwise known as the NIS 2 Directive. NIS 2 does not explicitly require SBOM, but it does highlight “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers…”
The CRA marks a significant step forward in unifying cybersecurity standards across the EU, reducing legal uncertainties for manufacturers, and enhancing overall security for users. However, what is most germane to our discussion is that the CRA calls for software bills of materials to be provided by manufacturers selling digital goods in the EU.
Breaking Down the CRA’s SBOM-Related Provisions
The CRA empowers “market surveillance authorities” to request SBOMs as a means of furthering security objectives.
Let’s examine some of the act’s SBOM-specific provisions:
“(22) In view of the public cybersecurity objectives of this Regulation and in order to improve the situational awareness of Member States as regards the Union’s dependency on software components and in particular on potentially free and open-source software components, a dedicated administrative cooperation group (ADCO) established by this Regulation should be able to decide to jointly undertake a Union dependency assessment. Market surveillance authorities should be able to request manufacturers of categories of products with digital elements established by ADCO to submit the software bills of materials (SBOMs) that they have generated pursuant to this Regulation. In order to protect the confidentiality of SBOMs, market surveillance authorities should submit relevant information about dependencies to ADCO in an anonymised and aggregated manner.”
Of note, the following passage and many other references in the CRA highlight vulnerability disclosure as a primary use case for SBOMs. We know that SBOMs are useful for many use cases such as software licensing and software maintainability, but it is the security concerns around vulnerabilities that are driving the focus for the CRA. This is very similar to how we saw SolarWinds driving the U.S. government’s executive order efforts as well. Anyone who says our governments do not care about security must not be paying attention!
“(78) In order to facilitate vulnerability analysis, manufacturers should identify and document components contained in the products with digital elements, including by drawing up an SBOM. An SBOM can provide those who manufacture, purchase, and operate software with information that enhances their understanding of the supply chain, which has multiple benefits, in particular it helps manufacturers and users to track known newly emerged vulnerabilities and cybersecurity risks. It is of particular importance that manufacturers ensure that their products with digital elements do not contain vulnerable components developed by third parties.”
But note the following clause, which is important. The CRA does recognize that SBOMs can be considered as sensitive data and is not trying to force manufacturers into risk management practices they would be uncomfortable with. That includes unnecessary transparency of software components. We’ve seen similar approaches from the FDA and others. And while, certainly, this creates a blind spot for some stakeholders that feel they have a right to know what is in their software, the CRA took an approach that considers the needs of manufacturers as well and lays the groundwork for transparency. In fact, what you will see in the SBOM formats is the concept of a license for the SBOM document itself, including restrictions on re-sharing the SBOM.
“Manufacturers should not be obliged to make the SBOM public.”
“(119) In order to ensure uniform conditions for the implementation of this Regulation, implementing powers should be conferred on the Commission to specify the technical description of the categories of important products with digital elements set out in an annex to this Regulation, specify the format and elements of the SBOM, specify further the format and procedure of the notifications of actively exploited vulnerabilities”
and
“(24) The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Annex I, Part II, point (1). Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 62(2).”
CRA SBOM Formats and Data Fields
The CRA does not explicitly call out SBOM formats or provide much specificity around requirements, with one notable exception. The section I’ve highlighted below states the minimum level of SBOM will include the “top-level dependencies,” which is to say not subcomponents. This is akin to a software inventory, and in cases like log4shell where many instances were compiled inside other libraries, may not be sufficient to identify the risky components.
“... identify and document vulnerabilities and components contained in products with digital elements, 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 products;”
This lack of specificity could create some concerns until you consider the guidance the EU is soliciting and plans to clarify further in the months ahead. One such example is BSI Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products Part 2: Software Bill of Materials (SBOM), which proposed a set of recommendations for SBOM.
These are recommendations, not requirements at this point, but it has been suggested by some in the SBOM community that these may be adopted once the commission is formed. This document was produced while the CRA was undergoing legislative approval, and version 1.1 was published in November of 2023.
This is an important document, and I’m glad to see that while they took some lessons learned from the NTIA SBOM initiative, they did not stop there. One example is the definition of Minimum Elements. Using “Must” and “May”-based language, the BSI defined a set of criteria that exceeded what the NTIA effort called for and provided additional guidance to optionally mature beyond these requirements.
For instance, the minimum elements and adherence to CycloneDX and SPDX formats, as well as most of the document are mandatory “Must,” while some suggestions such as adding vulnerability information into the SBOM or other non-required fields are optional “May.” Essentially, TR-03183 states what you need to do, but does not restrict you from going beyond these requirements.
The table below shows an example mapping the two sets of minimum elements.
SBOM Minimum Elements
Additionally, the guidance prescribes CycloneDX 1.4 or SPDX 2.3 or greater. This is also important because it recognizes that SPDX has evolved beyond the point at which it achieved ISO certification in 2.2.1 and clearly defines the minimum versions of these specifications that must be used.
The recommendations also convey information about how often SBOMs should be issued, under what circumstances, and even preferred formats for VEX attestations. This document forms the basis of some very solid practices for EU stakeholders to follow and puts this on equal footing with the U.S. efforts, and in some cases, exceeds the guidance put forth by existing guidance globally.
It does remain to be seen if this all becomes part of the requirements for the CRA, but regardless, it’s a positive sign of where the industry at large is headed with regard to software transparency. And perhaps, this just becomes part of the updates by BSI to The German IT Security Act 2.0.
What's Next for the CRA
As mentioned previously, there are really two obstacles at this time:
- The EU Council adopted the CRA on Oct. 10, 2024. The next steps are a) signatures from the presidents of the Council and Parliament and b) publication in the EU's official journal. This is all expected to happen within the next few weeks. The regulation will then be entered into force 20 days after publication in the EU journal.
- CEN/CENELEC still needs to draft standards that will formalize the detailed requirements.
But if you are waiting to get started on your SBOM program, you may want to consider getting started now with what we do know. When these details come to light, you will need time to implement the requirements. The CRA is coming regardless if you are ready or not. It is likely in your best interest to start showcasing your cybersecurity leadership and commitment to your consumers today.
FOSSA has extensive experience helping organizations navigate SBOM-related regulatory requirements, and their SBOM management solutions make compliance easier at multiple stages. You can import SBOMs from third-party suppliers, generate application-level SBOMs, analyze and act on vulnerabilities surfaced in your SBOMs, and securely share SBOMs with market surveillance authorities.
For more information on FOSSA SBOM management, reach out to their team. Or, you can try their free product for yourself.
