Applying CVSS v4.0 to CAN and CAN FD Vulnerabilities

Vulnerability Scoring vs. Risk Assessment

Risk assessment and vulnerability scoring are two distinct activities, and confusing them obscures what each is for. A risk assessment is a process: identify assets, frame threats, rate exposure and impact, select mitigations, document residual risk. It is done up front, at system or product scope, and produces a traceable analysis. Vulnerability scoring is what you do per finding: given one specific weakness, produce a comparable severity number that can be communicated to ENISA, to customers, and to the wider community. CVSS v4.0 is the de facto scoring scheme the CRA expects. The risk assessment frames the system; CVSS scores findings within it, both during development and across the product lifecycle as new vulnerabilities surface.
See IEC 62443-Style Risk Assessment for the process side.

Why CVSS Matters for CAN Product Manufacturers

CRA Article 13 requires vulnerability handling, including communication of severity to users. CVSS is the industry standard for severity scoring. For CAN-based products, scoring inconsistently across the industry would defeat the purpose; WP-103 proposes conventions that have been used in real CAN vulnerability disclosures.

How CVSS v4.0 Works — A CAN-Specific Primer

CVSS v4.0 has four metric groups: Base (intrinsic to the vulnerability), Threat (exploitation maturity), Environmental (deployment-specific), and Supplemental. Base metrics produce the headline score. The Base metrics most relevant to CAN are AV (Attack Vector, typically Physical), AC (Complexity, typically Low for CAN bus access), AT (Attack Requirements), PR (Privileges Required, typically None on classical CAN), and the impact triad VC/VI/VA on the vulnerable system plus SC/SI/SA on subsequent systems.

Scoring a Classical CAN Node: Baseline (5.2 / Medium)

An unprotected classical CAN node baseline is:

CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Base score: 5.2 / Medium

Rationale: physical attack vector (AV:P) with low complexity (AC:L) and no special prerequisites (AT:N, PR:N, UI:N). Confidentiality of the typical control payload is rated N because the data itself is usually not confidential. Integrity (VI:H) and availability (VA:H) are High because frame injection and DoS are unconstrained. The Subsequent System metrics are None for a single CAN node; they would change if the analysis covered the wider system the CAN node controls.

How Defense-in-Depth Layers Reduce the Score

Each layer of Defense in Depth reduces a different CVSS metric. The reductions stack; that is the point of layering:

• Access Limitation (physical enclosure, perimeter shell): Eliminates the attack vector entirely for the common case, reducing AV from P to "not exploitable", effectively dropping the score to 0 for that scenario, though insider and supply-chain risk remain documented separately.
• Bus Load Monitoring: Reduces VA from H to L for flooding and error-frame attacks; availability events are surfaced and operators can respond.
• Local Injection Detection: Reduces VI from H to L by giving the legitimate sender a way to detect impersonation of its own CAN IDs.
• Anomaly Event Monitoring: Reduces VI/VA from H to L for many attack classes; the attack is no longer silent and operators can respond.
• Frame Security (CANcrypt / SPsec): Reduces VC, VI, and VA all to N for in-band CAN attack scenarios. The score drops near 0; residual risk is on the cryptographic implementation and key management.
• Secure Object Fieldbus Access (configuration locking, protected OD entries): Reduces VA from H to L or N for configuration-tampering scenarios specifically.
• Secure Bootloader: Closes the firmware-tampering vector, removing the highest-impact subsequent-system scenarios from scope.

Who Scores What

The component manufacturer scores the vulnerability against its own product. The integrator may re-score it in the context of the integrated system using Environmental metrics. The operator may further adjust based on deployment-specific compensating controls. WP-103 recommends that manufacturers publish the Base score and clearly state the assumptions, leaving Environmental refinement to the integrator.

Reference: EmSA-WP-103

The full derivation of vector strings and worked examples is in EmSA-WP-103, available from the esacademy.com white papers library.

Frequently Asked Questions

What CVSS score does an unprotected classical CAN node get?

5.2 (Medium) under CVSS v4.0, with vector CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N. Source: EmSA-WP-103.

Does the CRA require CVSS specifically or just "a scoring system"?

The CRA requires manufacturers to use a recognized vulnerability scoring scheme and to communicate severity with each reported vulnerability. CVSS is the de facto scoring scheme for this purpose, and the version expected at the time of writing is CVSS v4.0. ENISA's reporting templates assume CVSS.

Can I reduce my CVSS score by adding a security event monitor?

Yes. A security event monitor that detects and reports anomalies reduces the integrity and availability impact metrics from High to Low for many threat classes, because the attack is no longer silent. The total score drops accordingly. See Anomaly Event Monitoring.

What is the CVSS score if CAN FD with SPsec encryption is used?

When SPsec authenticated encryption is in place across the bus, the integrity, availability, and confidentiality impact metrics for the typical CAN-borne attack scenarios all drop to None, yielding a baseline near 0.0. Residual risk shifts to attacks against SPsec itself or its key material; those are scored separately.