Cyber Resilience Act · product security
Vulnerability management under the Cyber Resilience Act.
The CRA requires manufacturers to identify and document components and vulnerabilities, handle and remediate vulnerabilities during the support period, and report certain actively exploited vulnerabilities and severe incidents. Vellaci connects SBOM exposure, intelligence, human review, remediation, VEX and evidence in one product workflow.
Intelligence with provenance
CVSS, EPSS, known-exploitation signals (CISA KEV), fix availability, references and source feeds, each with the time it was fetched. KEV is a signal, never a legal determination.
Triage states
New, needs review, affected, not affected, mitigated, fixed, accepted risk, false positive, archived — with reasons required for not affected, accepted risk and false positive.
CRA review
Could this qualify as an actively exploited vulnerability under Article 14? Not reviewed → potentially reportable → confirmed or not reportable, with rationale, reviewer, timestamp and awareness time.
Remediation
Owner, deadline, fixed version, mitigation and ticket links (Jira, Linear, GitHub); tasks can be created from any finding and tracked to closure.
VEX
Assessments map to affected / not affected / fixed / under investigation with justification, ready for CycloneDX VEX export per product version.
Immutable history
Every status change, review and remediation update is appended to the decision history and the hash-chained audit log.
From alert to decision
What the CRA expects vulnerability handling to look like.
Annex I Part II of the Cyber Resilience Act lists the vulnerability-handling requirements manufacturers must meet for the whole support period: identify and document vulnerabilities and components (the SBOM), address and remediate them without delay, apply effective and regular tests and reviews, publicly disclose fixed vulnerabilities with advisories, enforce a coordinated vulnerability disclosure policy, provide a contact address, distribute security updates securely and free of charge. Vellaci turns each of those into a workflow with evidence:
| Annex I Part II | Requirement (summary) | Vellaci workflow |
|---|---|---|
| (1) | Identify and document vulnerabilities and components, including an SBOM | SBOM ingestion per version, deduplicated component catalogue, continuous matching |
| (2) | Address and remediate vulnerabilities without delay, including security updates | Triage states, remediation owner and deadline, fixed-version tracking, release gates |
| (3) | Apply effective and regular tests and reviews | Readiness controls with evidence and review dates; scan results attached as evidence |
| (4) | Publicly disclose information about fixed vulnerabilities | Advisory drafts from the finding; VEX export; disclosure log |
| (5) | Put in place and enforce a coordinated vulnerability disclosure policy | CVD policy template, intake channel, SLAs, security.txt status |
| (6) | Facilitate information sharing, including a contact address | Published contact point, researcher acknowledgements, reporter communication log |
| (7)–(8) | Secure update distribution; timely, free security updates with advisories | Update mechanism documented per product; fix release linked to findings and advisories |
FAQ
Triage questions, answered.
- How is this different from a dependency scanner?
- A scanner tells you a component has a CVE. Vellaci tells you which products and versions on the EU market ship it, whether exploitation evidence exists, who owns the decision, what was decided and why, whether Article 14 could apply, and what evidence supports all of that. Scanners produce alerts; manufacturers need decisions with names and timestamps.
- What does 'priority' mean in Vellaci?
- An explainable score combining CVSS severity, EPSS exploitation probability, CISA KEV listing, fix availability and your product's exposure context (network-exposed, safety-relevant, placed on the market). Every factor is shown next to the score; nothing is a black box, and the score never replaces the human reportability review.
- Why are reasons mandatory for 'not affected' and 'accepted risk'?
- Because those are the decisions an auditor, a customer or a market surveillance authority will ask about. A 'not affected' without a justification is a liability; with one — the vulnerable function is not reachable, the component is compiled out, a compensating control exists — it is a VEX statement and evidence of due diligence.
- Does Vellaci decide what is 'actively exploited' under the CRA?
- No. It surfaces evidence — a KEV listing, a high EPSS score, an exploitation report — and asks a named reviewer to record whether the vulnerability is potentially reportable, confirmed reportable or not reportable, with rationale and the awareness time. The regulation's definition (Article 3(42)) and your legal advisers govern the threshold.
- Can we export VEX?
- Yes. Assessments map to affected / not affected / fixed / under investigation with justification codes and are exported as CycloneDX VEX documents per product version, so downstream customers can consume your statements automatically.
Read next
- Guide
SBOM guide for the CRA: formats, minimum content and operations
CycloneDX versus SPDX, what a CRA-oriented SBOM must contain, which tools generate one per ecosystem, how to keep it current per release, how to share it, and how it feeds vulnerability handling and VEX.
- Guide
VEX vs SBOM: component inventory and exploitability context
A concise technical comparison of SBOM and VEX, how component matching leads to product-specific exploitability statements, and what each artifact can and cannot establish.
- Guide
CRA Article 14 reporting obligations: a practical guide for manufacturers
What must be reported under Article 14 of the Cyber Resilience Act, by whom, to whom and when — the 24-hour early warning, 72-hour notification and final report — and how to operationalise it now that the obligation is in force (since 11 September 2026).
- Guide
Coordinated vulnerability disclosure under the CRA: policy, intake and security.txt
Annex I Part II requires manufacturers to enforce a coordinated vulnerability disclosure policy and publish a contact address. What the policy must contain, how to align it with ISO/IEC 29147 and 30111, how to run intake, and how it connects to Article 14.
- Docs
Triage workflow
Statuses, reasons, bulk actions, tickets.
- Docs
Intelligence and priority
Sources, provenance, EPSS, exploitation evidence, priority model.
- Docs
VEX
Per-product exploitability statements and signed CycloneDX VEX documents.
Stop triaging in spreadsheets.
Connect exposure, decisions, deadlines and evidence.