The Cyber Resilience Act Article 14 enters force in September 2026. If your software ships to the EU market, you need a notification pipeline for actively exploited vulnerabilities — not just a policy, but demonstrable evidence of detection, assessment, and decision.
Wardex v2.0 implements the full notification path. It takes what your scanner already produces and transforms it into signed, dated, chained audit artifacts that survive regulatory scrutiny.
The problem with scanner output
A Grype or Trivy JSON output tells you what CVEs exist. It does not tell you:
- Which of those CVEs are being actively exploited right now
- Whether the asset context (criticality, exposure, compensating controls) changes the risk calculus
- Who decided what, when, and with what criteria
For CRA compliance, the third point is the one that matters most. The regulation does not ask for the patch — it asks for the record of who assessed the risk, when, and what was decided.
KEV correlation: from noise to signal
The first step is knowing which CVEs in your inventory are being actively exploited. Wardex correlates scanner output against the CISA Known Exploited Vulnerabilities catalog:
$ curl -sSL https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
-o kev-catalogue.json
$ wardex convert grype grype-output.json --kev kev-catalogue.json
The output is a structured YAML file with each vulnerability annotated with actively_exploited: true/false, KEV dateAdded, and CISA notes. This is the input to the release gate evaluation.
Active exploitation hard stop (exit code 12)
When a vulnerability is actively exploited, Wardex introduces a hard stop distinct from normal gate blocking:
$ wardex evaluate --evidence vulns.yaml --config wardex-config.yaml # Exit code: 12 (ActivelyExploited) # This cannot be overridden by risk acceptance
The 12 exit code is intentional — it must be handled explicitly in CI/CD pipelines. Unlike the standard gate block (exit 10), an active exploitation stop:
- Generates a CRA Article 14 notification artifact signed with HMAC-SHA256
- Records a chained audit entry tracking the three CRA deadlines: early warning (72h), detailed report, and final report
- Cannot be silenced by risk acceptance
The Article 14 artifact lifecycle
Once an active exploitation is detected, Wardex manages the full notification lifecycle:
$ wardex art14 list $ wardex art14 show <artifact-id> $ wardex art14 verify <artifact-id> $ wardex art14 mark-dispatched <artifact-id> --phase early-warning $ wardex art14 finalize <artifact-id> --patch-date 2026-06-09T12:00:00Z
Each artifact is HMAC-signed and chained to the previous one, producing an append-only audit trail. This is what a regulator asks for — not a screenshot of a Jira ticket, but a cryptographic chain of custody from detection to notification to patch confirmation.
Risk-driven release gates
Outside active exploitation, the release gate evaluates risk using asset context:
R(v, α) = (CVSS/10) × EPSS × C(α) × E(α) × (1 − Φ(α))
Where C is asset criticality, E is exposure, and Φ is compensating control effectiveness (capped at 0.80). The same CVE produces different outcomes depending on where it lives:
| CVE | CVSS | EPSS | Bank | SaaS |
|---|---|---|---|---|
| Log4Shell | 10.0 | 0.94 | BLOCK | BLOCK |
| curl SOCKS5 | 9.8 | 0.26 | BLOCK | WARN |
| minimist | 9.8 | 0.01 | ALLOW | ALLOW |
The same CVE-2024-1234 with EPSS 0.01 is ALLOW in every profile. The gate blocks based on risk, not on CVSS panic. This reduces unnecessary pipeline failures while maintaining regulatory coverage.
What this means for CRA compliance
By September 2026, any manufacturer of products with digital elements sold in the EU must demonstrate:
- Active monitoring for exploitable vulnerabilities
- Notification to ENISA within 72 hours of confirmed exploitation
- Audit trail of all decisions
Wardex v2.0 covers the pipeline from scanner output to signed notification artifact. It does not replace your vulnerability scanner or your SIEM — it sits between them and produces the evidence that makes the regulation auditable.