Vulnerability Workflow

This guide explains how CRA Evidence helps you track vulnerabilities, meet ENISA reporting deadlines, and demonstrate "without delay" remediation per CRA requirements.

Overview

CRA requires manufacturers to:

1. Identify vulnerabilities in their products (Art. 13.6)
2. Remediate without delay (Art. 13.7)
3. Report actively exploited vulnerabilities to ENISA (Art. 14)
4. Notify users about security issues (Art. 14)

CRA Evidence provides tools to manage all of these requirements.

---

Automatic Vulnerability Scanning

When you upload an SBOM, CRA Evidence automatically scans it for known vulnerabilities.

How It Works

SBOM Upload --> Component Extraction --> Trivy Scan --> Results Display
                                              |
                                              v
                                    CVE Database Matching

1. Component extraction: CRA Evidence parses your SBOM and extracts component identifiers (PURLs)
2. Trivy scanning: Components are checked against the Trivy vulnerability database
3. Results stored: Vulnerabilities are associated with your SBOM and version

What You'll See

After upload, the version page shows:

• Vulnerability count by severity (Critical, High, Medium, Low)
• Component list with affected components highlighted
• CVE details for each vulnerability

Why SBOM Quality Matters

Vulnerability matching depends on Package URLs (PURLs):

See SBOM Guide for improving quality.

---

Understanding Scan Results

Severity Levels

CRA Evidence uses standard severity levels based on CVSS:

CVE Information

For each vulnerability, CRA Evidence shows:

• CVE ID: e.g., CVE-2024-12345
• Description: What the vulnerability is
• Affected component: Which component in your product
• CVSS score: Severity rating
• References: Links to advisories

---

ENISA Reporting (Article 14)

CRA requires reporting actively exploited vulnerabilities to ENISA and your national CSIRT.

When Reporting Is Required

Reporting is required when:

1. You become aware of an actively exploited vulnerability in your product
2. The vulnerability affects products you have placed on the market

"Actively exploited" means someone is actually using the vulnerability to attack systems, not just a theoretical risk.

Reporting Timeline

The clock starts when you become aware of active exploitation.

CRA Evidence Deadline Tracking

When you mark a vulnerability as "actively exploited," CRA Evidence:

1. Calculates deadlines (24h, 72h, 14d from discovery)
2. Tracks notification status (pending, sent, overdue)
3. Alerts you to approaching and missed deadlines

Recording ENISA Notifications

CRA Evidence tracks your notifications for audit purposes:

1. Navigate to the vulnerability
2. Click Record ENISA Notification
3. Select notification type (Early Warning, Detailed, Final)
4. Add the notification content
5. Save

This creates an audit record showing when you notified authorities.

Note: CRA Evidence does not automatically submit to ENISA. You must submit notifications through the ENISA Single Reporting Platform (available September 2026). CRA Evidence tracks that you did it and when.

---

Remediation Workflow

CRA Article 13(7) requires fixing vulnerabilities "without delay." CRA Evidence provides a structured workflow to track and demonstrate this.

Remediation Status Lifecycle

NOT STARTED --> IN PROGRESS --> FIXED --> VERIFIED --> RELEASED

Tracking Remediation

For each affected version:

1. Start Remediation: Click "Start Remediation" to record when work began
2. Mark Fixed: Record when the fix was implemented
3. Verify: Document how you verified the fix (scan, test, review)
4. Release: Record when the fix was released to customers

Metrics for "Without Delay" Compliance

CRA Evidence automatically calculates:

• Time to Fix: Hours from discovery to fix implementation
• Time to Release: Hours from discovery to customer availability

These metrics demonstrate your responsiveness to regulators.

---

Managing Vulnerabilities

Creating Manual Vulnerabilities

Not all vulnerabilities come from scans. To add a manually discovered vulnerability:

1. Navigate to Vulnerabilities in the main menu
2. Click New Vulnerability
3. Enter:
   • Title and description
   • CVE ID (if assigned)
   • Severity
   • Affected components
   • Discovery source (internal, researcher, advisory)
4. Click Create

Linking to Affected Versions

Connect vulnerabilities to specific product versions:

1. Open the vulnerability
2. Click Add Affected Version
3. Select the product and version
4. Add notes about how it's affected

False Positives

If a scanner reports a vulnerability that doesn't actually affect your product:

1. Review the vulnerability details
2. Document why it's not applicable (e.g., affected code path not used)
3. Mark as False Positive or use VEX

Using VEX (Vulnerability Exploitability eXchange)

VEX statements document which vulnerabilities actually affect your product:

VEX can be included in your CycloneDX SBOM or tracked separately.

---

User Notification

CRA requires notifying users about vulnerabilities and available fixes.

When to Notify Users

• When you release a security update
• When users need to take action
• When a vulnerability may impact their security

Recording User Notifications

CRA Evidence tracks that you notified users:

1. Open the vulnerability
2. Click Record User Notification
3. Enter:
   • Notification method (email, advisory, etc.)
   • Number of recipients
   • Summary of notification content
4. Save

Security Advisories

Create formal security advisories for significant vulnerabilities:

1. Navigate to Security Advisories
2. Click New Advisory
3. Link relevant vulnerabilities
4. Write advisory content
5. Publish when ready

Advisory IDs follow format: SA-YYYY-NNN (e.g., SA-2025-001)

---

Scheduled Re-scanning

Vulnerabilities are discovered continuously. CRA Evidence can automatically re-scan your SBOMs:

Re-scan Frequency Options

Configuring Re-scans

Organisation admins can configure in Settings > Organisation:

1. Enable/disable automatic re-scanning
2. Select frequency
3. Configure notification preferences

---

Dashboard and Alerts

Vulnerability Dashboard

The dashboard shows:

• Total vulnerabilities by status
• Critical/High requiring immediate attention
• ENISA deadlines approaching or overdue
• Pending remediations across products

Overdue Alerts

CRA Evidence highlights:

• ENISA notifications past deadline
• Vulnerabilities with no remediation progress
• Old vulnerabilities not yet resolved

---

Best Practices

1. Enable re-scanning: Automatically catch new CVEs in existing components — triage new findings within 24-48 hours.
2. Start tracking immediately: Begin the remediation record when work starts; don't skip the verification step before marking fixed.
3. Prepare ENISA processes before September 2026: Establish who handles notifications, configure CSIRT contacts, and register for the ENISA Single Reporting Platform when available.

---

API for Automation

Get Vulnerabilities

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

Get Pending Remediations

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

Start Remediation

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

See API Overview for the complete API reference.

---

Next Steps

1. Technical File Export - Generate compliance bundles
2. FAQ - Common questions answered

---

Glossary