Vulnerability workflow

CRA Evidence manages the full vulnerability lifecycle from scan to ENISA reporting.

How it works

SBOM Upload -> Scan -> Triage Queue -> Promote or Dismiss -> Active Tracking -> Remediation -> History
                                              |                                       |
                                              +--- VEX auto-created ----------> VEX Review tab

Uploading an SBOM triggers automatic CVE matching. Findings enter the triage queue based on your sensitivity settings, where you promote (track) or dismiss (suppress) each finding. Promoted vulnerabilities move to active tracking with a status lifecycle and per-version remediation records. Dismissals auto-generate draft VEX statements for the selected product versions. All resolved items move to history.

Scanning

• Upload triggers CVE matching against NVD, GitHub Advisory DB, and CISA KEV.
• PURL coverage determines scan quality. Higher PURL coverage means better detection. See SBOM Guide.
• Re-scanning happens automatically when the vulnerability database updates. New uploads are scanned immediately.

Threat intelligence

CISA KEV (Known Exploited Vulnerabilities): daily-refreshed catalogue of CVEs with confirmed exploitation. KEV CVEs always enter triage regardless of sensitivity settings and automatically trigger the ENISA 24-hour deadline when promoted.

EPSS (Exploit Prediction Scoring System): Probability of exploitation in the next 30 days (0.0 to 1.0). Used in triage sensitivity gating and priority scoring.

Security events hub

Unified view of all vulnerabilities and incidents across your products.

Severity filter cards (Critical, High, Medium, Low, KEV) and ENISA overdue/pending badges appear at the top of the hub.

Triage

What enters triage

Sensitivity levels configured in Settings > Organisation:

KEV items always enter triage regardless of sensitivity level.

Priority scoring

Items are ranked by combining CVSS severity, EPSS probability, and KEV status. KEV items always rank highest. Higher EPSS boosts priority for items at the same severity level.

Actions

Promote: Moves to Active tab. If the CVE is in CISA KEV, the ENISA 24-hour deadline starts automatically.

Dismiss: Removes from queue with a reason. All dismiss reasons can create VEX statements for your manufacturer products. The dismiss modal shows checkboxes for each affected product version (pre-checked by default). Uncheck to skip VEX for specific versions. See VEX Management for details.

Temporary dismissals

Set a defer period (in days). After expiry, the CVE can re-enter triage on the next scan. Use for "revisit later" situations.

Suppression

Dismissed CVEs create a suppression record. They will not re-enter triage on future scans unless the dismissal expires.

For more granular control, use Suppressed Findings which support scoping at four levels: Organisation > Product > Version > Component.

Active tracking

Vulnerability status lifecycle:

Active tab shows non-resolved statuses. History tab shows Fixed, Won't Fix, and False Positive.

ENISA reporting (Track A)

Article 14(2) of Regulation (EU) 2024/2847. Required for actively exploited vulnerabilities.

The clock starts when you become aware of active exploitation. KEV items auto-trigger these deadlines.

Record each submission in CRA Evidence for the audit trail. The dashboard shows overdue and pending ENISA badges.

The ENISA Single Reporting Platform launches September 2026. Until then, submit through the ENISA portal and record the submission here.

Remediation (per version)

Each affected version tracks remediation independently:

Not Started -> In Progress -> Fixed (Unverified) -> Verified -> Released

This is the per-version remediation status. It tracks progress for each affected version independently. The vulnerability itself has a separate top-level status (Identified through Fixed) that reflects the overall investigation state.

CRA Evidence calculates time-to-fix and time-to-release automatically. These metrics demonstrate "without delay" compliance under Article 13(7).

Manual vulnerabilities

Not all vulnerabilities come from scans. Create them manually via Security Events > Report Vulnerability. Link affected product versions and set ENISA reporting flags as needed.

User notification

The CRA requires notifying users about vulnerabilities and available fixes (Article 14). Record notifications in CRA Evidence: method, recipients, and content summary. This creates an audit trail.

Organisation settings

API

# List vulnerabilities
curl "https://api.craevidence.com/api/v1/vulnerabilities" \
  -H "Authorization: Bearer $API_TOKEN"

# List pending remediations
curl "https://api.craevidence.com/api/v1/vulnerabilities/pending-remediations" \
  -H "Authorization: Bearer $API_TOKEN"

# Start remediation for a version
curl -X POST "https://api.craevidence.com/api/v1/vulnerabilities/{vuln_id}/versions/{version_id}/remediation/start" \
  -H "Authorization: Bearer $API_TOKEN"

See API Overview for the full reference.

Key dates

Related documentation

• Incident Reporting, security incidents and ENISA Track B
• VEX Management, VEX automation and CSAF advisories
• SBOM Guide, SBOM quality and upload
• Technical File Export, compliance bundles
• API Overview, full API reference