When a vulnerability is reported in a shared software component, a manufacturer should not assign one impact verdict to its entire product portfolio. A component vulnerability impact matrix separates each affected product, variant and supported release, records what is actually present, evaluates whether the vulnerable behaviour matters in that context, and links the decision to remediation and evidence. It is a practical way to answer the operational question: which shipped versions need action, and why?
The Cyber Resilience Act (CRA) does not prescribe a spreadsheet or matrix format. It does require manufacturers to identify and document vulnerabilities and components, address and remediate vulnerabilities in relation to product risk, perform effective security tests and reviews, and systematically document relevant cybersecurity aspects. The matrix described here is an engineering implementation pattern for those obligations, not an official CRA form or a substitute for the manufacturer's cybersecurity risk assessment.
Why one CVE can produce several product decisions
A component can be shared by multiple products without being used in the same way. One firmware release may include the vulnerable function; another may compile it out. A desktop application may expose a network interface that an embedded variant never enables. A later release may contain a fix while an older supported version remains deployed.
This creates three separate questions that must not be collapsed:
- Inventory: Is the component and relevant version present in the actual shipped artifact?
- Impact: Can the vulnerability affect this product in its intended or reasonably foreseeable use, configuration and threat context?
- Response: What remediation, mitigation, user communication or further investigation is needed for this specific release?
A scanner match is a candidate, not a proven exploit path. Conversely, the absence of a scanner match is not proof that a release is unaffected when the software bill of materials (SBOM) is incomplete or component identity is uncertain.
What the CRA requires, and what the matrix adds
Annex I Part II point (1) requires manufacturers to identify and document vulnerabilities and components in products with digital elements, including an SBOM in a commonly used machine-readable format covering at least top-level dependencies. Point (2) requires addressing and remediating vulnerabilities without delay in relation to the risks posed to the products, including through security updates. Other points address testing, disclosure of fixed vulnerabilities, coordinated disclosure and secure update distribution.
Article 13(7) separately requires systematic documentation of relevant cybersecurity aspects, including known vulnerabilities and relevant third-party information, with updates to the cybersecurity risk assessment where applicable. Article 13(6) addresses coordination with a component manufacturer or maintainer when a manufacturer identifies a vulnerability in an integrated component.
These are legal requirements. One row per vulnerability and release, the column names below, the triage states and the review cadence are recommendations, not extra statutory obligations. The Commission's July 2026 implementation guidance helps explain CRA scope, risk assessment and lifecycle questions, but does not turn this matrix into a prescribed compliance artifact. ENISA's October 2026 SBOM technical advisory provides additional implementation guidance on SBOM lifecycle and data flows; it is guidance rather than a conformity certificate.
Build a release-level impact matrix
Use a stable row key such as vulnerability ID + product ID + variant + release ID + artifact digest. Where one release contains several distinct affected component instances, add the component instance or package identifier. This prevents a decision for one image or deployment from overwriting a different one.
| Field | Purpose | |---|---| | Vulnerability and source | CVE, supplier advisory or internal finding, with source date and revision | | Product, variant and release | Exact supported or deployed product baseline under investigation | | Artifact and SBOM reference | Immutable digest or build identity, plus SBOM location and generation date | | Component identity | Package URL, CPE or other justified identifier, version and dependency path | | Inventory confidence | Confirmed present, confirmed absent, or unresolved identity/coverage | | Impact state | Under investigation, affected, not affected with rationale, or fixed in this release | | Exposure and evidence | Reachability, configuration, attack preconditions, tests and supporting links | | Decision owner and date | Accountable reviewer, approval and next reassessment trigger | | Response and rollout | Patch, mitigation, validation, update availability and affected users | | Related obligations | Upstream coordination, disclosure and separate Article 14 trigger assessment |
Keep the raw discovery result separate from the reviewed impact state. For example, a scanner's severity rating should remain source data; the manufacturer's product-specific priority is an assessed decision that also considers exposure, consequences and the product risk assessment.
Illustrative matrix: one library, four release contexts
The following example is fictional and is not a vulnerability advisory or a CRA classification.
| Product / release | Inventory and exposure | Current decision | Next action | |---|---|---|---| | Controller A / 2.4 | Vulnerable library confirmed; exposed parser reachable | Affected | Patch and validate 2.4 maintenance release | | Controller A / 2.5 | Fixed library confirmed in signed artifact | Fixed in this release | Preserve verification and update evidence | | Gateway B / 1.8 | Library present; vulnerable feature disabled in documented build | Under investigation | Verify binary contents and bypass paths before any not-affected conclusion | | Gateway B / 1.9 | SBOM lacks transitive dependency detail | Unknown inventory | Reconstruct build inventory; do not close the finding |
The point is not to maximise the number of green cells. It is to make uncertain cases, older deployed versions and differing exposure paths visible to the people making release and remediation decisions.
A seven-step triage workflow
1. Identify every candidate release
Begin with the vulnerability's affected package and version ranges, then query the SBOMs or component inventories for all relevant products and releases. Include supported versions, maintained branches, variants and products already placed on the market where the vulnerability may matter. Do not limit the search to the latest development branch.
Record which inventories are missing or have limited coverage. An empty search result from an incomplete inventory must remain an open question. ENISA's SBOM implementation guidance is useful for establishing the lifecycle and data flows needed to maintain dependable inventories.
2. Resolve component identity and actual shipped content
Normalize package names and identifiers, account for forks and vendor-patched versions, and distinguish build-time dependencies from delivered code. Confirm the release artifact when package metadata alone is ambiguous. For embedded systems, the deployed firmware image, optional features and runtime configuration can matter more than the repository dependency declaration.
Retain the evidence behind a confirmed-absent decision, such as a build manifest, artifact inspection or reproducible component analysis. Do not infer absence solely from a changed package name.
3. Evaluate impact separately for each release
Determine whether the vulnerable code path exists and is reachable under the product's relevant threat model. Review attack preconditions, exposed interfaces, privileges, deployment assumptions, configuration and mitigations. Where possible, use targeted tests, static analysis or architecture evidence.
A shared codebase does not justify copying a not-affected conclusion to every variant. Reuse the analysis only when the team can demonstrate that the relevant build, configuration and exposure assumptions are equivalent. Record both the reasoning and its boundaries.
4. Make unknown states explicit
Use a small set of reviewed operational states: under investigation, affected, not affected, and fixed. These are internal triage labels, not CRA legal categories. If inventory is incomplete or the exploit path cannot yet be evaluated, keep the case under investigation with a named owner and review date.
A not affected result needs a product-specific rationale and supporting evidence. A fixed result needs verification of the actual release artifact, not merely a merged source-code patch. These distinctions are consistent with the purpose of Vulnerability Exploitability eXchange (VEX), although the CRA does not mandate VEX.
5. Prioritise remediation and track each supported line
For affected releases, assess the product risk and choose an appropriate response: update the component, apply a downstream patch, change configuration, add a tested mitigation or take another documented measure. Track the implementation, test result and delivery path for each release line.
Avoid marking the portfolio fixed because the newest release contains a patch. Older supported or deployed releases may still require a security update, mitigation, support decision or user-facing information. Where an upstream component is implicated, evaluate the separate Article 13(6) coordination duty.
6. Assess disclosure and reporting independently
Annex I Part II contains requirements concerning information about fixed vulnerabilities and secure dissemination of updates. Article 14 establishes a distinct notification regime for actively exploited vulnerabilities and severe incidents affecting product security; its reporting obligations have applied since 11 September 2026. A vulnerability match or an affected matrix row does not automatically establish an Article 14 reporting trigger.
Assign a separate decision owner to the Article 14 assessment and retain the basis and awareness timeline. Do not use the matrix as a substitute for the reporting process or assume that upstream notification discharges any regulatory reporting duty.
7. Reassess when the facts change
Reopen relevant rows when a supplier advisory changes, new exploitation evidence appears, a release is rebuilt, a mitigation is removed, or the product's configuration or deployment changes. Preserve previous decisions and their evidence rather than silently replacing them. A date-stamped history allows a reviewer to distinguish what was known at the time from later intelligence.
Keep the matrix tied to release evidence
A useful investigation package does not need to duplicate every binary or engineering document. It should contain stable references that allow a reviewer to reconstruct the decision:
- vulnerability source and revision, including the date it became known;
- component identity, affected version range and inventory coverage;
- exact product, variant, release and artifact digest;
- relevant SBOM and build metadata;
- reachability or exploitability analysis and supporting tests;
- decision owner, rationale, date and superseded states;
- remediation or mitigation ticket, verification and rollout status; and
- any upstream notification, user advisory or separate regulatory reporting decision.
The matrix can live in an issue tracker, a database or a controlled table. The important controls are identity, ownership, access, change history and reproducible evidence links. The ENISA/JRC requirements-to-standards mapping is useful background on lifecycle-oriented security controls, but it is not itself a harmonised standard or a presumption-of-conformity mechanism.
Where VEX helps, and where it does not
VEX can communicate a product-specific vulnerability status and justification in a machine-readable form. CycloneDX supports VEX in the context of product components, and the OASIS Common Security Advisory Framework (CSAF) VEX profile defines product-specific states and supporting impact statements. That makes VEX useful for sharing a reviewed result with customers or downstream tooling.
It does not replace the investigation. A VEX document is only as reliable as the product identity, release mapping, evidence and review process behind it. Treat the matrix as the working decision register and VEX, where useful, as one possible exchange representation. Neither is a CRA conformity verdict.
Connect decisions to the correct lifecycle context
As product lines evolve, SBOM matches, vulnerability decisions and release evidence can become separated across systems. AA-sec is designed around connecting SBOM and component information, vulnerability work, security evidence and decisions to exact product and lifecycle context. That model is intended to help teams preserve the reasoning behind release-specific impact decisions while complementing existing engineering and CI/CD tools; AA-sec does not automatically determine exploitability or CRA conformity.
Practical next steps
Start with one recently disclosed component vulnerability that appears in more than one release. Inventory the candidate products, create a separate row for each relevant release, investigate at least one ambiguous case, and verify that the final record identifies the affected artifacts, evidence, decision owner and remediation path. Then test whether the same record can be reopened when new information arrives.
The outcome to aim for is not a perfect-looking dashboard. It is an auditable answer to four questions: where is the component, which releases are actually affected, what action was taken, and what evidence supports each conclusion? That answer is useful for engineering operations today and for the manufacturer's CRA vulnerability-handling preparation ahead of the broader requirements applying from 11 December 2027.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act, Article 13 and Annex I — EUR-Lex
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- ENISA Technical Advisory for Software Bill of Materials — ENISA
- Cyber Resilience Act Requirements Standards Mapping — ENISA and European Commission Joint Research Centre
- Vulnerability Exploitability eXchange (VEX) — CycloneDX
- Common Security Advisory Framework Version 2.0 Errata 01 — OASIS Open