Compliance with the European Union’s Cyber Resilience Act (CRA) is emerging as one of the biggest technical and organisational challenges facing manufacturers that market embedded devices in Europe. The act came into effect on 10 December 2024, and many of its main obligations will apply to OEMs three years on, from 11 December 2027.
A crucial element of an OEM’s CRA compliance effort is the ability to update a device’s software to protect it against new cyber threats, and particularly to respond to official Common Vulnerabilities and Exposures (CVE) notices.
While the hardware components of a security-compliant system - devices such as a Hardware Security Module (HSM) or Trusted Platform Module (TPM) - are well understood today by OEMs, the process of maintaining the security protection of embedded software and of deploying software updates to devices in the field is new and unfamiliar to many.
It is understandable that the topic of software updating induces feelings of trepidation: it is in some ways a complex and difficult function to manage. In fact, this is an area in which Foundries.io has been providing technology and support to embedded device manufacturers for many years. In our view, there is no reason for any OEM to be troubled by the software update requirements of the CRA. But the rollout of the legislation has shown that, while much of the process can be streamlined and automated, the industry has yet to fill the gap in the provision of some important tools and utilities which would considerably lighten the burden of CRA compliance.
How the CRA requires software updates to be managed
The CRA’s purpose, according to the EU, is ‘to safeguard consumers and businesses buying software or hardware products with a digital component’. The CRA addresses the inadequate level of cybersecurity in many products, and the lack of timely security updates for products and software. The act sets out to achieve its aims by putting new obligations on a product’s manufacturer and retailers. In particular, the act ‘requires manufacturers to provide care during the lifecycle of their products’.
Gone are the days when an electronics product manufacturer could ship a product from its factory and then forget it ever existed: an obligation to maintain protection against the threat of cyber-attack now continues long after the device is shipped to its end user.
The act codifies this continuing security obligation in various ways, the most important of which are:
- Address vulnerabilities identified in applicable CVE notices after shipment
- Maintain a mandatory software bill-of-materials (SBOM) for each production unit, to enable effective CVE tracking
- Fix vulnerabilities ‘without delay’
- Regularly test and review product security
- Have a policy for vulnerability disclosure
- Securely distribute fixes/updates ‘in a timely manner’ and free of charge to the end user
So the OEM now has a duty to make a record, or SBOM, of all the software components of every production unit shipped from the factory, to maintain and update the SBOM to take account of changes to a device’s code base resulting from updates and patches, to know when any part of the device’s code base is exposed to a known vulnerability, and to quickly fix the vulnerability and distribute the fix free to users.
The value of maintenance infrastructure to support lifetime updating
The code base of today’s connected embedded devices, especially those which are based on a Linux® operating system, is large and complex: it is often made up of hundreds or thousands of separate components from commercial and open-source third parties, as well as proprietary software. It is nearly always impracticable to compile an inventory of these components manually: a system is needed to automate SBOM generation during development, in production and after shipment of every product variant.
The complexity extends to security functions such as secure boot, authentication, and cryptographic protection of data and software updates. Records of secret keys that are unique to each production unit need to be securely stored and managed. Public key infrastructure (PKI) management is an essential element of an OEM’s approach to CRA compliance.
In addition, OEMs require a system for fleet management of devices in the field: this provides a foundation for the delivery and deployment of the correct update packages for each individual unit. An effective fleet management system provides a security-focused inventory of all units shipped to customers (apart from those known to be decommissioned), each tagged with a unique secure ID. This can help to protect the fleet from the risk of a cyber attacker introducing a spoof unit into the fleet in an attempt for instance to gain access to critical secrets or code.
These functions call for a systematic approach to the logging, storage and management of data unit-by-unit and end-to-end, from development through production to post-shipment maintenance. Because all of these functions underpin compliance with the CRA, the introduction of this European regulation has given extra impetus to OEMs to deploy a formal DevOps framework - the kind of system of which the FoundriesFactory platform from Foundries.io is an example.
Any such platform should provide an integrated set of utilities and tools to provide for:
- PKI management
- SBOM generation and maintenance
- Fleet management
- A CI/CD flow to support the rapid development and deployment of fixes and patches
- Update development, delivery and deployment backed by strong security features
- By instituting such a framework at the start of a new product development, and using it as the foundation for lifecycle management, OEMs can automate, streamline and simplify device management and security processes which would otherwise be extremely complex, time-consuming, and prone to human error.
Above: The FoundriesFactory platform integrates external open-source resources to provide development, security and operational functions
The missing pieces of the compliance jigsaw
A proven DevOps framework might be necessary for all but the smallest OEMs to manage their CRA compliance effort, but it is not sufficient. Other tools and systems are required, but unfortunately, for some of the crucial elements of the compliance task, effective open-source tools do not yet exist. Two gaps are particularly striking:
- For tracking CVE exposure
- For documenting and auditing compliance actions
Today’s CVE checkers tend to be crude: they produce too many positive results. This is because they straightforwardly match the name and description of a software package identified in a CVE notice with the name and description of software in a device’s SBOM. But this is not the same thing as identifying a specific vulnerability. A CVE notice will normally apply to a specific section or sections of a software product’s code base; the rest of the code base is not at risk.
So, if an embedded device only uses a part of the product to implement a specific function and does not contain the vulnerable part of the code base, there will be no need to create and deploy a fix for it. But a crude CVE checker will flag the device as vulnerable anyway if it uses any part of a software package named in a CVE notice.
This highlights the need for more sophisticated tools, which can scan a device’s source code and find matches with vulnerable code identified in a CVE notice. There is reason to be optimistic that the new availability of advanced AI models could provide the foundation for such a tool in the future.
The second gap in the compliance tool set is a system to support reporting and auditing. The CRA imposes steep financial penalties related to the size of the product manufacturer, for non-compliance. This should strongly motivate OEMs to demonstrate how they have complied with the terms of the act, by reference to every single production unit in the field.
Just as the SBOM utility in software such as the FoundriesFactory platform automates the generation of a list of software components unit-by-unit, an effective compliance reporting tool will need to maintain a record of the reported exposures, and the fixes applied, unit-by-unit.
Ideally, the tools to fill both these gaps will emerge from the open-source community and gain widespread enough adoption to become standardised. Where standard open-source solutions exist, the industry gains by avoiding the need for multiple companies to reinvent the wheel, and by sharing common learning and experiences.
The virtuous circle of open-source standardisation is the reason that the FoundriesFactory platform, for instance, adopted The Update Framework (TUF) as its tool for security-focused software update delivery and deployment. Many other elements of the FoundriesFactory platform have an open-source basis for the same reason.
Software updating: a process, not a package
Under the pressure of requiring compliance with the CRA, OEMs are now grappling with the difficulties of software updating. They are learning that software updates are a crucial element of their compliance effort, but that software updating is not just about the update package: a whole system of device monitoring, security, fleet management and software deployment functions underpin the ability to respond quickly to a new vulnerability or exposure.
Many OEMs will benefit from building their updating infrastructure on a proven DevOps framework, which will provide a sound and automated basis for identifying and maintaining production units in the field in a security-rich way, enabling them to deliver the right update package to the right device at the right time.
Author details: George Grey is VP Technology, Qualcomm Technologies International, member of the Foundries.io team
