1. Design phase
The CRA does have some concrete requirements for products that need to be taken into account very early on. "Secure by design” is a guiding principle. When designing your product, you should make sure that:
- All of your suppliers are prepared for CRA compliance themselves
As the manufacturer, you have the sole responsibility for the security of your product. So if you choose a silicon vendor that doesn’t release security updates to their Linux BSP, or a wifi chip vendor that doesn’t commit to patching firmware vulnerabilities, you could be at risk. Choosing a cheaper vendor could wind up costing big in recalls or product re-designs if they end up being the source of a vulnerability that they won’t fix. - You have a software update system built in
This applies to embedded Linux devices, of course, but also to microcontrollers and RTOSes. The CRA doesn’t discriminate; you have to have updates. Plan for it from the beginning; adding an update system late in development can be a nightmare. You should also make sure that your update system is capable of updating everything: bootloader, kernel, external chip firmwares, etc. No matter where an exploitable vulnerability comes from, you have a responsibility to patch it, so make sure your update system is up to the task. - Evaluate if you need Secure Boot
The CRA mandates integrity protection for the software running on the device. There are a number of approaches to integrity protection, but one commonly implemented measure is Secure Boot. Secure boot uses hardware security features to disallow any unsigned software from running at boot time. If you aren’t implementing Secure Boot, or if you have elements of your system that are not covered by secure boot (for example, if you have an application that is updated independently from the rest of the firmware image), you should make sure that your software update system is performing robust integrity checks as part of its built-in protection. - Define the threat model for your product
Your obligations under the CRA are dependent on the actual threats and risks your product faces in its intended use. So one of the most important things you can do in the design phase is produce a formal threat model as one of your design documents. STRIDE is one common framework for doing so. Once you’ve accurately defined the threats you need to protect against, development can focus on the security elements that are truly relevant.
2. Implementation phase
- Automatically generate accurate SBOMs
The CRA mandates the production of an accurate and comprehensive Software Bill of Materials. This should be in a standard, machine-readable format; generally SPDX or CycloneDX. Since it’s not really feasible to manually create an SBOM, you should make sure that your build tooling is creating your SBOM(s) for you. A device might have several different SBOMs for different components: for example, one for the base operating system, another for an application running in a container or hypervisor, and a third for an RTOS running as a sidecar. Those can also be combined into a single aggregated SBOM. But either way, you need to list all of the software components and libraries that are used in your device. Yocto has tooling for generating SBOMs of the images you build; you may also need to ask your software suppliers for SBOMs of any parts that are provided to you externally. - Secure-by-design
The CRA mandates that devices be “secure by design”. This means that they need to already be secure as-purchased. You generally can’t use, for example, a shared set of default credentials on first startup. There are exceptions to this, especially where the product is expected to be set up and installed by IT or system integration professionals, but it’s always a good idea to limit your possible attack surface from the start. - Start doing your automated vulnerability scans
We’ll get into this more in the release phase, but since products can’t be released with any “known exploitable vulnerabilities”, it’s important that you remain aware of potential problems throughout the development phase. If a new vulnerability in some underlying component arises a month before launch, you’ll have to fix it before you place the product on the market. The sooner you can find out about possible vulnerabilities, the better. - Implement the software update system
It’s considered a best practice to start using your software update system very early in your development process, if possible. If the update system is good, it will accelerate your development activities: for example, allowing developers to use an API to automatically push software updates as they develop greatly reduces the build-flash-test cycle. Making sure your update system is both secure and flexible is an important criterion here. - Regularly consult your threat model, and do security reviews
Make sure that your development team is aware of the official threat model, so potential design issues are caught early. Security reviews should be an integrated part of the development process.
3. Release and post-release support
- Continue monitoring for vulnerabilities
You have a responsibility to be proactive about potential security issues: you aren’t allowed to just sit back and wait until the product is actually exploited. After the launch of the product and throughout its support period, you should be regularly checking for emerging threats that might affect your product. Having an accurate and comprehensive SBOM will help here. There is tooling, both commercial (e.g. Snyk, Security Pattern, Timesys, Onekey) and open source (e.g. OWASP DependencyTrack), that can help you monitor for security threats based on an SBOM. If your software suppliers provide SBOMs with VEX (Vulnerability EXchange) data, that can help ease your burden of monitoring. - Respond in a timely manner to any actual threats that appear
Although you must be proactive in dealing with potential exploits before they are exploited in the real world, it’s not possible to be perfect. Security incidents can happen, eventually, regardless of how much work you put into security beforehand. When that does happen, you have a notification responsibility to ENISA (link to ENISA article on this). The deadlines for this are quite short: initial incident reports are due within 24 hours of your initial discovery. - Keep track of your support period obligations
You must support your product for at least 5 years after it is placed on the market. That 5-year support obligation applies to each individualized product as it is placed on the market, as well. So if you launch a product on Jan. 1 2028, you must support it at least until 2033. But if you produce and place on the market a second production run of the same device in 2030, those devices have to be supported until at least 2035. You can decide whether to distinguish between production runs by assigning different SKUs, but you should always keep in mind what your longest support obligation is.
Conclusion
If you would like to know more about how the CRA impacts your product development, you can reach out to us. If you are using Toradex hardware and/or Torizon software and software updates, several of these steps above become much easier, because we’ve done a large part of the work already.
Contact us to learn how!