How Can Manufacturers Address and Remediate 1000+ CVEs?

Clever Filtering Will Not Do!

The latest Torizon Minimal image (version 7.7.0) enriched by the Qt LGPL libraries has 1122 unpatched vulnerabilities. Images that have been less aggressively minimised have well over 1500 unpatched CVEs.

The CRA requires manufacturers to "address and remediate vulnerabilities without delay" (Annex I.II.2) and to make products available on the market "without known exploitable vulnerabilities" (Annex I.I.2a) - relative to the risk that the vulnerabilities pose to the product.

Manufacturers have four traditional options to address and remediate the risk emanating from the 1000+ CVEs:

• They can eliminate a risk by removing the component containing the CVE or by fixing the vulnerability in the code. Note: Removing, for example, the CVEs referring to modules not contained in the kernel nearly halves the number of CVEs.
• They can reduce a risk by introducing security measures that restrict the attack vector, increase the attack complexity or require higher privileges.
• They can transfer a risk to suppliers or to users. For the CRA, this is only possible through the backdoor of the "specific context" and "conditions of use" in the intended purpose.
• They can accept a residual risk by doing nothing about it.

Eliminating the risk would be the best option. But it would already be too expensive for 50 CVEs and even more so for hundreds of CVEs. As the CRA condones transferring the risk only with gritted teeth, we are left with reducing or accepting the risk. This leads to the next question.

We cannot do a risk assessment for 1000+ CVEs - estimating their likelihood to be exploited and the damage of an exploitation (see my newsletter Stop Managing in Cybersecurity why this kind of risk assessment is futile). Even if we could estimate each CVE in 15 minutes, it would take us 167 hours times the number of people doing the estimation. This would easily sum up to 3-5 person months. We haven't even considered the 100-200 new CVEs every month. This approach is far too expensive.

What we need is a metric that tells us when we must do something about a CVE and when not. Two well-known metrics try to help with this decision.

• The CVSS metrics measure the severity of a CVE as a value from 0.0 (no severity) to 10.0 (critical severity). Its exploitability metrics describe how easily the CVE can be exploited. The higher the score the more easily exploitable the CVE is.
• The EPSS score measures the likelihood of exploiting a CVE in the next 30 days as a percentage.

We could, for example, stipulate that we reduce the risk for all critical (9.0 <= severity <= 10.0) and accept the risk for all non-critical CVEs. This filter would result in 59 critical and unpatched CVEs for the Qt-enriched Torizon Minimal image from the beginning. By removing the CVEs from modules not in the kernel, we can get the number down to 32.

Assessing the risk for 32 CVEs for the initial risk assessment (when placing the product on the market) seems doable. But this "clever" filtering has some serious issues.

• The CVSS scores published for CVEs don't take product-specific security measures into account. We would have to adapt the CVSS scores of all critical CVEs to the operating environment of our product. The effort for going from general scores like AV:N to modified scores like MAV:L is in the same ballpark as the effort for the risk assessment.
• The threshold severity >= 9.0 is arbitrarily chosen. The "reason" for choosing critical CVEs is simple: Assessing the risk for 211 CVEs with high or critical severity (severity >= 7.0) is not feasible. Such a randomly chosen threshold wouldn't hold up against the scrutiny of the market surveillance authorities.
• Not all known exploited vulnerabilities (KEVs) have critical severity. In other words, severity and known exploitation are not correlated, which is not surprising for a randomly chosen severity threshold.
• NIST decided to enrich only KEVs with CVSS scores from April 2026. 356 CVEs in the Torizon image have no CVSS score - most of them from 2026 and some from late 2025. Most CVEs in the National Vulnerability Database (NVD) don't contain a CVSS score any more. NIST's review of the maintainers' CVSS score is gone.

The EPSS score suffers from the first two issues of the CVSS score as well: not product-specific and arbitrarily chosen thresholds. The EPSS score is calculated from approximately 2850 signals. Hence, adapting the EPSS score to a specific product is highly impractical.

These observations lead to the following answer to the title question.

There is a corollary, which the vendors of vulnerability management tools will hate.

So, we should save the 2500-5000 Euros per month for these tools and spend them on something more meaningful like "effective and regular tests and reviews of the security of [our] product" (Annex I.II.3).

Addressing 1000+ CVEs one by one is too costly. Addressing the critical CVEs or the CVEs that are exploited with 95% probability in the next 30 days might miss the CVEs relevant to our product. This approach feels more like gambling than a systematic engineering approach. Let us get some inspiration from medieval castles.

Defence in Depth by a Medieval Castle

The medieval castle above shows multiple barriers that make the capture of the castle very difficult and very unlikely.

• The mountains make an approach from this side close to impossible.
• The defenders cleared the forests far around the castle to see the attackers early.
• The palisades protect the only bridge to the castle and the village. Men with longbows and crossbows defend the castle from the top of the palisades.
• The gooseneck bend of the river covers three quarters of the moat around the castle. The last quarter of the moat was built manually.
• The ring walls, rocks and the steep slopes of the hill are the next barriers. The stone walls host catapults, bowmen and crossbowmen. Soldiers and villagers can dump rocks, hot pitch and excrements from the walls.
• The inner castle is protected by another wall and contains the keep as the last refuge.

Defence in depth is a tried-and-tested military strategy. It tries to delay the attackers' advance rather than prevent it completely. The goal is to cause the attackers such high losses that they give up before they capture the inner castle with the keep.

Making the Exploitation of 1000+ CVEs Unlikely

• Layered Protection: Defense-in-depth uses multiple, independent security controls.
• Friction and Containment: The primary goal is to slow down attackers and limit lateral movement.
• Redundancy is Key: No single point of failure protects critical assets from compromise.

This could be the main characteristics of the defence-in-depth strategy for our medieval castle. However, this quote is from Palo Alto Networks describing defence in depth for cybersecurity.

Let us transfer defence in depth from the medieval castle to taming the CVE flood. The castle's multiple barriers like palisades, moat, ring walls and the hill translate into multiple independent security measures for embedded devices. Even if the attackers overcome the moat, they still face four walls and a steep rocky hill. Each barrier slows the attackers down and decimates them further - until they give up. It's the same with cybersecurity attacks. Each security measure makes a successful exploitation less likely, increases the attacker's cost and the odds of being caught. The attackers are more inclined to give up and look for an easier-to-exploit target.

After doing the risk assessment mandated by the CRA, we have a list of security measures. Some of the measures are already implemented and some will have to be implemented until 11 December 2027. At this point, we don't know whether our security measures are good enough to make the exploitation of 1000+ CVEs unlikely. We must be able to demonstrate to the market surveillance authority in a verifiable way that our defence-in-depth strategy is effective.

This is where CVSS exploitability metrics become useful again. CVSS metrics are poor at telling us which CVEs to ignore. But they are useful for demonstrating why our security measures make classes of CVEs difficult to exploit.

For each security measure, we verify that it changes at least one exploitability metric for the better. For example, a security measure restricts the attack vector from network to local (AV:N -> MAV:L) and the privileges from none to normal-user privileges (PR:N -> MPR:L). If our product has multiple security measures improving the metrics in the same way, we have defensible evidence that an attack of this type (e.g., a network attack with no privileges) has become less likely. Now, this is risk assessment!

Let us try out this approach with a heat pump as our example product.

Restricting the Attack Vector

The following security measures make attacks from a remote or adjacent network unlikely and restrict attackers to local or physical attacks. Together they move the attack vector from AV:N or AV:A down to MAV:L.

• The heat pump has a private IP address. On power-on, it establishes an encrypted connection (MQTT over TLS) with the fleet management server of the manufacturer. Devices in a remote or adjacent network cannot connect with the heat pump directly but must go through the server.
• The SSH server is disabled by default. A technician can log in to the heat pump via SSH, only after the local user has started the SSH server. As the SSH server only runs sporadically for a short time, network attacks (AV:N and AV:A) on the SSH server become very unlikely.
• For OTA updates, the heat pump temporarily establishes an encrypted connection with the fleet management server. It closes the connection once it has downloaded the update image and switches to the new image by rebooting. Similar to the SSH server, this makes network attacks (AV:N and AV:A) very unlikely.
• All network connections are outbound from the heat pump to the fleet management server. The only permanent network connection is the long-lived MQTT-over-TLS connection over TCP port 8883. The SSH and HTTPS connections are established only temporarily over TCP ports 22 and 443 when needed for debugging and OTA updates, respectively. All other ports are closed, which is automatically tested before every release.

The first three security measures share a good security practice.

But this good practice wouldn't be worth much without the fourth security measure.

Increasing the Attack Complexity

The attack complexity moves from low to high, if the attacker must "invest some measurable amount of effort in preparation or execution". The extra effort can come from different sources. For example:

• The attacker must figure out shared secrets or special configuration settings.
• The attacker must overcome other security measures.
• The attacker must be able to read or modify network communication (e.g., by a man-in-the-middle attack).

Many security measures restricting the attack vector or requiring higher privileges will also increase the attack complexity. Note that the definition of attack complexity explicitly excludes "any requirements for user interaction in order to exploit the vulnerability".

Taken together, the following security measures increase the attack complexity from AC:L to MAC:H.

• The security measures restricting the attack vector to MAV:L and requiring higher privileges up to MPR:H force attackers to spend considerable effort on exploiting CVEs.
• Address space layout randomisation (ASLR), position-independent executables (PIE), stack canaries and other hardening techniques make the exploitation of memory corruption vulnerabilities a lot harder and more unlikely (see Linux Kernel ASLR, PIE, and Exploit Mitigation Hardening Beyond the Defaults).
• We configure U-Boot such that users can't stop the boot process at the U-Boot prompt. In other words, we disable the U-Boot command-line interface. This makes it more difficult for attackers to boot a different malicious kernel.

We could add secure boot as another security measure. A chain of trust rooted in secure boot would drive up the attack complexity significantly. Instead of targeting the heat pump, attackers would focus on getting their hands on the signing keys - stored more or less securely on some company computers. However, we don't need secure boot to make default products CRA-compliant. We can also achieve CRA compliance by combining several security measures. This gives us options at different price and effort levels.

Requiring Higher Privileges

The following security measures make the exploitation of CVEs with no privileges (PR:N) or low privileges (PR:L) unlikely. The privileges required increase from PR:N to MPR:L for normal users and to MPR:H for technicians. Users only get the least privileges needed for their tasks.

• A systemd service starts our application as a normal user instead of as root. As described in the article Optimising a systemd service for security, systemd provides numerous sandboxing and hardening options that can prevent the application process from gaining new privileges and restrict its access to the filesystem, kernel interfaces and devices.This helps establish the least privilege principle and makes higher privileges necessary.
• The fleet management server uses role-based authentication. The resident and the service technician use different credentials to log in to their applications. Hence, each user is assigned the least privileges required for their tasks. This increases the required privileges for an exploitation.
• Before technicians can log in to the heat pump via SSH, they must authenticate with a temporary OpenSSH certificate, which expires after two hours. Technicians gain high-privilege access, but not necessarily root access. This increases the required privileges for an exploitation.
• Even if technicians interact with the heat pump physically, they must authenticate with a short-lived SSH certificate to enter the diagnostic mode of the heat pump. We have removed authentication by a publicly known service code or an easy-to-guess password. Again, this increases the required privileges.

If we go through the risk assessment, we'll probably find many more security measures (already existing or still to be implemented) that increase the privileges required.

Requiring User Interaction

• A technician can log in to the heat pump remotely via SSH, only after the local user has started the SSH server. This requires user interaction (MUI:R).
• We could also require the local user to start the VNC server, if our heat pump supported a VNC connection for remote debugging. This would require user interaction (MUI:R).

Requiring user interaction is a lot like two-factor authentication - except that the two factors come from different persons. It is a pretty effective way to make unauthorised remote access to a device very difficult.

Continuous Re-Assessment of Our Defence-In-Depth Strategy

As 100-200 new CVEs come out every month for our device, our defence-in-depth strategy needs continuous re-assessment. This is where the EPSS score comes in handy. The EPSS score tells us the probability that a CVE will be exploited in the next 30 days. It is a real number in the range from 0.0 to 1.0. If we sum up the scores for all CVEs, we get the expected number of CVEs exploited in the next 30 days: XNX30, for short.

The re-assessment looks at the XNX30-many CVEs most likely to be exploited in the next month. This set will normally contain all KEVs. We perform the re-assessment every month. We check for these CVEs that our security measures still have the desired effect. We might find out that we missed a security measure in the risk assessment or that our measures don't help against a new type of attacks. In both cases, we add the appropriate security measures. Most of the time, we'll be able to remediate the CVE before it is exploited on our device.