Let us get the big decisions right - early.
Instead of fixing hundreds of CVEs, manufacturers can provide enough security measures to make the exploitation unlikely. The decrease of the CVSS metrics is a useful indicator how effective the security measures are. This post is about understanding the CVSS metrics.
From now on, I'll use heat pumps in private homes as the running example for my CRA articles.
WRONG: substantial modification => new placing on the market. Logical somersaults needed to avoid infinite support periods and full conformity assessment for all legacy products. --- RIGHT: substantial modification => update conformity assessment. No trickery needed.
Do suppliers of FOSS components like Qt LGPL, Weston/Wayland, Linux BSPs, containers and OTA update solutions have to perform no, light-touch or full CRA compliance? The answer affects how much due diligence machine and device manufacturers must exercise for these components in their CRA compliance.
Stop managing risk! It doesn't work! Official bodies shall tell manufacturers which security measures are needed to meet the minimum bar. Telling them to figure it out themselves is a waste of time. Safety doesn't use risk assessment but more effective people. What can security learn?
The definitions for making available on the market, placing on the market, intended purpose and substantial modification are crucial for understanding the CRA. The CRA, Blue Guide and Commission guidance interpret them differently. I am trying to sort out this mess.
The Commission guidance creates an infinite support period: Substantial modifications imply new placing on market, which restarts the support period over and over again. I refute the first implication with the CRA itself and show how to legally shorten the support period.
Big architecture decisions have big business impact. Wardley maps help us identify money pits in product development. They show us the way how to save money by commoditising hardware and software that is not part of our core business.
The CRA guidance treats placing on the market differently for standalone software and embedded systems. Longer support periods and workarounds cause higher costs for machine and device manufacturers. It would be simple to treat all products the same.
The Yocto recipe gives GPL as the license of MariaDB. The Qt Sql library implements its MySQL driver with MariaDB. Hence, it would be under GPL - and so would be all applications linking Qt Sql. Businesses would have to open-source their code. A disaster! So, what's wrong?
A device violates essential CRA requirements. Although simple state-of-the-art security measures are available, the manufacturer mitigates the violations with legal disclaimers. This goes against the intention of the CRA: improving cybersecurity in real life and not just on paper.
A manufacturer blatantly violates the licenses of the FOSS components in its cars. Using the software and the car becomes illegal. The owner must not drive the car and files a lawsuit. Remedies of the legal defect include compliance, price reduction, replacing the car and sales reversal.
Per definition, embedded devices are products with digital elements and, hence, must comply with the CRA. I'll give examples whether to classify devices as default, important or critical. The classification decides how expensive CRA compliance is. So, we better get it right.
Courts will do it! Cybersecurity experts throw a lot of security measures at the wall and see which ones stick. They seriously suggest that manufacturers must only do a "proper" risk assessment and all is fine. Manufacturers define what "proper" means. Isn't that circular reasoning?
If a machine sold in 2015 receives a feature update in 2028 or later, it must undergo full CRA compliance (Article 69.2). The best bet for the manufacturer might be to argue that the CRA violates legal certainty and non-retroactivity of law - constitutional rights in most EU countries.