Building CRA-Ready Vulnerability Management Infrastructure

When the CRA's reporting obligations kick in (September 2026), you must report actively exploited vulnerabilities to ENISA within 24 hours. That's not a policy document — it's an infrastructure challenge. You need automated detection, intelligent triage, and streamlined reporting. Here's the architecture.

The Detection Layer

• Dependency scanning — Continuous scanning of all dependencies against CVE databases (Grype, Trivy, Snyk)
• Container image scanning — Every deployed container image scanned on build AND continuously in production
• Runtime vulnerability detection — Agent-based monitoring for zero-day exploitation indicators
• Threat intelligence feeds — Automated correlation of your SBOM components against active exploitation reports (CISA KEV, EPSS scores)

The Triage Engine

Not every CVE triggers a 24-hour report. You need automated triage:

• Is the vulnerable component actually reachable in your product? (Reachability analysis)
• Is there evidence of active exploitation? (Threat intelligence correlation)
• What's the blast radius? (Impact assessment based on product classification)
• Is this a CRA-reportable event or a standard patch cycle item?

The Reporting Pipeline

When a reportable vulnerability is confirmed:

1. Auto-generate early warning report (24h deadline) with required fields
2. Route to security team for review and approval
3. Submit to ENISA reporting platform via API
4. Track detailed notification (72h) and final report (14 days) deadlines
5. Coordinate with affected customers and downstream distributors

Infrastructure Stack

This requires: a vulnerability aggregation platform (DefectDojo, Dependency-Track), an SBOM management system, automated triage rules engine, ENISA reporting integration, and a notification system for stakeholders. Build it once, use it across all products.