Automated Vulnerability Monitoring for CRA Compliance

The EU Cyber Resilience Act requires manufacturers to identify and document vulnerabilities in their products and their components — including third-party and open source dependencies. When those vulnerabilities are actively exploited, you have 24 hours to report to ENISA. Manual, periodic vulnerability scanning cannot meet these requirements. You need automated, continuous monitoring.

This guide covers how to build a vulnerability monitoring pipeline that satisfies CRA requirements and actually catches the vulnerabilities that matter.

Why Continuous Monitoring, Not Periodic Scans

A vulnerability scan run once a quarter — or even once a month — leaves dangerous gaps. New CVEs are published daily. The CISA Known Exploited Vulnerabilities (KEV) catalog is updated multiple times per week. An actively exploited vulnerability published on Tuesday and discovered in your quarterly scan on Friday means you missed the 24-hour ENISA reporting window by months.

The CRA does not explicitly mandate continuous monitoring, but the 24-hour reporting obligation for actively exploited vulnerabilities makes it practically necessary. You cannot report what you do not know about, and you cannot credibly claim you were unaware if the vulnerability was public and your product was affected.

The Three Essential Data Sources

Your monitoring pipeline should aggregate intelligence from multiple sources. No single database is comprehensive.

1. OSV.dev (Open Source Vulnerabilities)

OSV.dev is an open, distributed vulnerability database maintained by Google. It aggregates vulnerability data from ecosystem-specific sources (npm, PyPI, RubyGems, crates.io, Go, Maven, and more) and provides version-aware matching out of the box.

Why OSV.dev is essential for CRA compliance:

• It maps vulnerabilities to exact affected version ranges per ecosystem
• It uses Package URLs (purls) — the same identifiers in your SBOM
• It has a free API with no rate limits for reasonable use
• It aggregates from GitHub Advisory Database (GHSA), PyPA, RustSec, and other ecosystem databases

Query OSV.dev with the exact package names and versions from your SBOM. It will return only the vulnerabilities that affect your specific versions — no false positives from keyword matching.

2. GitHub Security Advisories (GHSA)

GitHub Security Advisories is a curated database of vulnerabilities in open source software. Advisories are reviewed by GitHub's security team and linked to specific package versions and ecosystems.

GHSA is particularly valuable because:

• Advisories are linked directly to GitHub repositories, making it easy to verify the affected component
• Many advisories include patch information and workaround guidance
• It feeds into Dependabot alerts for GitHub-hosted projects
• It is cross-referenced with CVE IDs for broader correlation

3. CISA KEV (Known Exploited Vulnerabilities)

The CISA KEV catalog is the most critical data source for CRA compliance because it lists vulnerabilities that are confirmed to be actively exploited in the wild. This is the data source that triggers your 24-hour ENISA reporting obligation.

Monitor CISA KEV separately from your general vulnerability feeds. When a vulnerability in your dependency tree appears on the KEV list, it is not just a patch priority — it is a regulatory reporting event. Your monitoring system should trigger an immediate alert, distinct from routine vulnerability notifications.

Version-Aware Matching

False positives are the enemy of an effective monitoring pipeline. A vulnerability in express@4.17.0 does not affect your product if you use express@4.18.2. Your matching must be version-aware.

Different ecosystems use different versioning schemes:

• npm, Cargo, Go: Semantic Versioning (semver) — compare against semver ranges in advisories
• Python (PyPI): PEP 440 version specifiers — different from semver, be careful with comparison logic
• Linux packages (Debian, Alpine): distribution-specific version comparison — use the distro's own version comparison logic
• NVD/CPE matching: CPE matching uses vendor:product:version tuples — can produce false positives for common package names

OSV.dev and GHSA both provide pre-resolved version ranges, which makes matching more reliable than raw NVD/CPE lookups. Prefer ecosystem-specific sources over NVD keyword matching for application-level dependencies.

Building Your Monitoring Pipeline

A practical CRA-compliant monitoring pipeline looks like this:

1. SBOM as input. Start with your CycloneDX or SPDX SBOM. This is your source of truth for what components are in your product.
2. Daily scan against OSV.dev and GHSA. Extract package names, versions, and purls from the SBOM and query the vulnerability databases. Flag any matches.
3. Continuous CISA KEV monitoring. Check the KEV catalog at least daily (hourly is better). Cross-reference against your SBOM components. Any match is a potential ENISA reporting trigger.
4. Severity enrichment. For each matched vulnerability, pull the CVSS score from NVD using the CVE ID. This helps prioritize remediation and informs your ENISA report severity assessment.
5. Alert routing. Route routine vulnerabilities to your engineering team's backlog. Route CISA KEV matches and critical-severity vulnerabilities to your incident response team immediately.
6. Report generation. When an actively exploited vulnerability is confirmed to affect your product, generate the initial ENISA early warning report with pre-filled product and component information.

Tools and Integration

You do not need to build everything from scratch. Integrate existing tools:

• Dependabot / Renovate: automated dependency update PRs. These help with remediation but do not replace vulnerability monitoring.
• Trivy: scans containers, file systems, and SBOMs against multiple vulnerability databases. Can be run in CI/CD and on a schedule.
• Grype: vulnerability scanner that accepts SBOMs as input. Pairs well with Syft for SBOM generation.
• cra-scanner: assesses overall CRA readiness including vulnerability exposure. Useful for CI/CD integration with minimum score thresholds.

What to Do When a Vulnerability Is Found

Not every vulnerability requires the same response. Triage based on:

• Is it actively exploited? (CISA KEV) If yes, trigger your ENISA reporting process immediately. You have 24 hours.
• Is it reachable in your product? A vulnerability in a function you never call is lower priority than one in a code path your product exercises.
• What is the severity? Critical and high severity vulnerabilities should be patched within days. Medium and low can follow your standard update cycle.
• Is a fix available? If yes, update the dependency. If not, implement a workaround or document the risk acceptance in your technical documentation.

For managing third-party component vulnerabilities across your full supply chain, see our supply chain security guide.

For a complete CRA preparation plan, see our CRA compliance checklist.

Complaro provides continuous vulnerability monitoring against OSV.dev, GitHub Advisories, and CISA KEV, with version-aware matching against your SBOM. When an actively exploited vulnerability is detected, Complaro drafts the ENISA early warning automatically. Get started free.