On December 3rd, the EU's new Cyber Resilience Act (CRA) got a big step closer to being adopted when the European Parliament and the EU Council reached an agreement on the legislation. It is now only one step away from being officially adopted. Unless lobby groups manage to derail final approval by the European Parliament and the Council, it will likely enter into force sometime before summer. Organizations affected by the CRA will then have 36 months (and in some cases just 24 months) to adapt to the new requirements.
First proposed by the EU Commission in September 2022, the CRA has been controversial due to its massive sector-agnostic scope. It will introduce stringent security requirements for all "connected device manufacturers" selling “products with digital elements” in the EU, which means it will impact almost every major company that sells OT, IoT, or IIoT products.
Securing the software supply chain and addressing device vulnerabilities are two of the major goals of the CRA. To help our readers understand this regulation, I thought I’d highlight a few of the key clauses pertaining to software supply chain security.
Just as it featured heavily in recent US cybersecurity legislation, “software bill of materials” recurs frequently in the EU CRA. SBOMs are cited primarily in the context of facilitating vulnerability analysis. One of the first mentions of SBOMs states:
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. A software bill of materials can provide those who manufacture, purchase, and operate software with information that enhances their understanding of the supply chain, which has multiple benefits, most notably it helps manufacturers and users to track known newly emerged vulnerabilities and risks. It is of particular importance for manufacturers to ensure that their products do not contain vulnerable components developed by third parties.
The EU has correctly recognized that identifying risks — particularly those associated with vulnerabilities — requires transparency into all the components comprising a “product with digital elements” (which I’ll just call “product” herein for brevity). SBOMs provide that transparency. Manufacturers in the EU will now need to provide SBOMs for the products they sell, and they should be able to obtain SBOMs for the components that go into those products.
Judging from what we’ve seen here in North America, manufacturers have historically been hesitant to produce SBOMs — due either to fear of exposing their IP or reluctance to incur additional cost when no one knew exactly how SBOMs were to be put to practical use. (To learn more about the early days of SBOMs in the US, read our blog on The Minimum Components of an SBOM.) But SBOMs have long since emerged from the academic discussion stage and are now actively being produced and consumed, not just to satisfy regulators but to satisfy a growing appetite for them in the marketplace. I expect to see a similar pattern in the EU.
It’s not 100% clear in the Act what level of depth manufacturers are responsible for with respect to product components. In the Vulnerability Handling Requirements section of Annex 1, the Act states that Manufacturers shall:
…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;
“Top-level” dependencies seems like a low bar. Our own research has uncovered plenty of serious vulnerabilities buried far deeper than the top level. But the EU Commission may share the philosophy of Dr. Allan Friedman: “not letting the perfect be the enemy of the good.” (Dr. Friedman from CISA is SBOM’s biggest proponent in North America.) Knowing the top-level dependencies is better than knowing nothing. The rest will follow.
The Act also specifies that the EU Commission retains the power to:
…specify the format or elements of the reporting obligations and of the software bill of materials.
I’m not sure if this will result in yet another SBOM format in addition to SPDX, CycloneDX, and SWID. (Let’s hope not. The SBOM initiative is too important to get overly bogged down by a format war.) In our global economy, it doesn’t make sense to have regional formats. But the phrase “commonly used and machine-readable format” is encouraging and suggests the EU isn’t looking to start from scratch on their own bespoke format.
The Act specifies that products must be accompanied by:
…the correct identification of the type, batch, version or serial number or other element allowing the identification of the product.
Like an iceberg with 90% of its mass hidden below the surface, this requirement appears straightforward but is actually extremely challenging. There isn’t currently a standard for uniquely identifying these kinds of products, and likely for now, this will need to be done on a company by company basis. Subscribe to our blog and we’ll dive into the challenges in a future post as this is a big topic.
The Act also states that some of the obligations of manufacturers are to:
include a cybersecurity risk assessment in the technical documentation…
and
exercise due diligence when integrating components sourced from third parties in products with digital elements. They shall ensure that such components do not compromise the security of the product with digital elements.
Producing a “cybersecurity risk assessment” isn’t well defined in the Act but one important thing to note is that an SBOM does not provide a risk assessment. An SBOM is simply a list of ingredients: the components and subcomponents that make up the product. To perform a risk assessment, you also need to know the specific risk associated with each subcomponent.
Our FACT platform performs exactly that kind of analysis. Armed with an SBOM that it produces via binary code analysis, FACT hunts for a wide range of risk factors, including (but not limited to) vulnerabilities. Our visibility reports provide detailed cybersecurity risk assessments with a high degree of granularity. They offer easy-to-use risk scores on a component by component basis as well as on a product by product basis. So if a component is harboring vulnerabilities — or malware or a compromised certificate chain or some other risk factor — FACT will score it accordingly, and that score will also bubble up to all the products containing that component.
I wouldn’t want to say FACT’s cybersecurity risk assessment reports are a silver bullet for fulfilling this requirement… but manufacturers who sell products in the EU may want to give us a call. 🙂
There is another requirement in the Act that FACT addresses that eliminates a lot of burdensome manual research. With respect to vulnerability handling, manufacturers will need to:
…apply effective and regular tests and reviews of the security of the product with digital elements.
While they don’t explicitly define “regular,” FACT’s continuous monitoring of public vulnerability databases, vendor websites, and other sources would meet and most likely exceed this requirement. And this capability is useful not just for checking a regulatory box — continuous monitoring ensures that manufacturers and operators are alerted to critical vulnerabilities and can take remedial action before attackers exploit them.