Companies developing software intensive products for the European Union market are scratching their heads as to what to do with the recently-approved EU Cyber Resilience Act (CRA) developed to “ensure safer software and hardware.” In the works since 2020, the CRA does not come as a surprise, but companies are now scrambling to align their internal processes and procedures.
The good news is that product companies have time to comply. Approved by the European Parliament in March 2024, enforcement of the act won’t start until 36 months from its approval by the European Council, which is expected in early-to-mid 2024.
For those who haven’t been following, the EU’s goals with the CRA are to address “the inadequate level of cybersecurity inherent in many products, or inadequate security updates to such products and software,” and “the inability of consumers and businesses to currently determine which products are cybersecure.” The CRA will meet these goals by “harmonizing rules for bringing to market products or software with a digital component” through a cybersecurity requirements framework and software lifecycle “duty of care” controls.
SBOMs and the CRA
As you would expect, SBOMs (Software Bills of Materials) are a big part of the new CRA requirements. The CRA is explicit in its expectations for SBOMs: they MUST be provided as described in Germany’s Technical Guideline, TR03183 cyber resilience requirements for manufacturers and products.
As standards documents go, the TR03183 Technical Guideline is very readable and sufficiently detailed without being overly so. It makes manufacturer compliance to compile an SBOM mandatory, but does not enforce public distribution of SBOMs. It states that an SBOM is static and does not contain vulnerability information (which would be inherently changing over time), but it does call for a new SBOM for every software change, which makes sense. It mentions VEX, but does not require it. Allowed formats include CycloneDX 1.4 or higher, or SPDX version 2.3 or higher. The attributes in the SBOM are directly derived from the NTIA work on the minimum SBOM elements.
There is some interesting language as to recursive dependencies that, if I read it correctly, explains that if you deliver an application A with components B, C and D, you need to at least include the subcomponents that make up B, C and D. In other words, if your application includes a database, you need to list components that make up the database component.
The Technical Guideline is very clear that an SBOM can be created during the build phase, but can also be an “Analysed SBOM” (as per section 6.3.4). This makes sense: an SBOM can be created from source, but that would exclude third-party binaries, which is always the challenge in providing needed SBOM information.
In Practice
The EU CRA states that an SBOM needs to be compiled, but not published. Still, the it clearly states that that users of the product need them to understand their cyber security exposure. Users here could be hospitals, automakers, manufacturing floors, but also individual consumers that purchase, say, a smart thermostat.This means that users, as well as government bodies, regulatory bodies and industry experts, may request an SBOM from a manufacturer.
The goal is to achieve transparency, accountability, compliance, and security in the digital ecosystem. Failure to provide an SBOM will be problematic and may lead to significant financial penalties, lawsuits, or even exclusion of the product from EU markets.
EU CRA covers other requirements besides the SBOM, including provisions that a manufacturer needs to inform the European Union Agency for Cybersecurity (ENISA) within 24 hours of an actively exploited vulnerability. Another requirement calls for manufacturers to ensure that vulnerabilities in their products are ‘handled’ for at least five years, unless the product lifetime is shorter.
What Does This Mean?
Any company that builds products for the European market in which software is a critical component needs to develop a program to build a SBOM, either by integrating SBOM creation into the build process or performing analysis on the final binaries. In the build process, this includes third party components that are delivered as binaries.
Integrating SBOM creation into the build process is the better DevSecOps approach in order to generate these types of artefacts early in the development lifecycle. However, this option does require additional investment in tooling and development time. Secondly, it still needs to address binary components from third-party code used in the build process, as well.
For products in active production, this is doable when there is sufficient time to think about it. However, for larger companies with a lot of legacy products that are in the maintenance cycle but still bringing in significant revenue, building SBOMs into the DevOps process can be an issue. In these cases, building SBOMs during Binary Composition Analysis (BCA) is the better approach. Developing SBOMs using BCA is a lot easier, less effort, and faster than trying to integrate SBOMs into development cycles.
By scanning third-party components, CodeSecure CodeSentry BCA generates SBOMs from binaries to help developers understand the security of their third-party code elements so they can make informed decisions on what third-party code to use before integrating it into the final product. Additionally, CodeSentry builds SBOMs for legacy products, such as in medical and vehicle systems where updating and patching is particularly sensitive.
Conclusion
Companies that build digital assets for the EU market need to be aware that the CRA will be confirmed soon, starting the timer to enforcement. The responsibilities for manufacturers are well defined. Better to get ahead of it now, rather than wait untill the last minute and miss a critical window.
