June 16, 2026

Wardex v2.0: CRA Article 14 Evidence, KEV Correlation, and Risk-Driven Release Gates

Turning vulnerability scanners into CRA-compliant audit evidence without changing how your team ships.

The problem with scanner output

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.

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.