Skip to main content

Configuring Monitoring Sources

To maintain a proactive security posture, organizations must continuously monitor external sources for newly discovered vulnerabilities that may impact their products or infrastructure. The CVD Portal allows you to configure automated Monitoring Sources, ensuring you are immediately aware of relevant security disclosures and fulfilling the continuous monitoring requirements of the Cyber Resilience Act (CRA).

You can configure the portal to monitor specific CVE feeds, vendor security advisories, open-source project mailing lists, and specialized security forums. By defining specific keywords, product names, or component identifiers, the portal filters this massive volume of information and only alerts you to disclosures relevant to your environment. These automated alerts can be directly ingested into the portal as new triage tickets, streamlining the intake process.

How each source type is checked​

Sources are polled once per day at 06:00 UTC, on the schedule you set (daily, weekly or monthly). Sources set to ad hoc are never polled automatically.

  • NVD sources query the National Vulnerability Database for CVEs published since the previous check, and report how many were rated HIGH or CRITICAL.
  • GitHub Security Advisories sources match your uploaded SBOM against OSV.dev, which aggregates GitHub Security Advisories along with the language ecosystems' own databases. Only advisories whose affected version ranges actually include the versions pinned in your SBOM are counted, so the result reflects your components rather than the whole advisory feed.

Reading the coverage note​

A component can be checked when its SBOM entry carries both a version and an ecosystem. Well-formed SBOMs state the ecosystem through each component's package URL (purl).

When an entry names no ecosystem, the portal works it out in two steps. It first reads the name itself, which is conclusive for shapes like @scope/package (npm) or com.google.guava:guava (Maven) but not for a bare name like picocolors. Failing that, it falls back to the ecosystem of the SBOM as a whole, applied only when every component it can identify agrees on one and enough of them do so to count as evidence. An SBOM that mixes ecosystems, or that states a conflicting ecosystem through a purl, gets no fallback and its unidentifiable entries stay skipped.

Anything still unresolved is skipped rather than guessed at, because a wrong ecosystem would hide a real advisory.

When anything is skipped, the result says so, for example:

Auto-scan: 4 advisories affecting your SBOM components since 2026-07-27, 2 HIGH/CRITICAL (249 of 844 components checked, 595 skipped for missing ecosystem or version, or for exceeding the per-scan component cap)

Read a zero-advisory result together with that count. Uploading an SBOM that carries purls is still the way to get full coverage, and it is the only option for a genuinely mixed SBOM. Both CycloneDX and SPDX support them.

If OSV.dev does not answer for some components, the result says that separately. Those components are unknown rather than clean, and re-running the check usually resolves it.

If no SBOM has been uploaded, the source reports that instead of a finding count.

This automated monitoring reduces the reliance on manual intelligence gathering and minimizes the window of exposure between a public disclosure and your organization's awareness of the threat. By staying ahead of the news cycle, you can initiate triage and remediation processes before external researchers or attackers begin probing your systems for newly announced vulnerabilities.