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 lets you record Monitoring Sources and checks some of them automatically. This supports the monitoring duties of the Cyber Resilience Act (CRA).

You add sources under Settings → Monitoring Sources. Each source has a name, an optional URL, a type and a check frequency. The types are NVD, GitHub, vendor, CERT, internal and other. The portal checks only NVD and GitHub sources automatically. Use the other types to record the sources that your team checks by hand. Monitoring sources require the Reporting plan or higher.

The result of each check is stored on the source as its last findings. When an NVD check finds new HIGH or CRITICAL CVEs, the portal also adds a note to your most recent open submission. It does not create new submissions.

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 all CVEs published since the previous check, and report how many were rated HIGH or CRITICAL. This count is not filtered to your products or components.
  • 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.

A component that has no ecosystem can still be checked by its CPE 2.3 identifier. This applies to hardware, firmware and vendor binaries, which have no package URL. The portal sends the CPE to the NVD, and the NVD returns the CVEs whose affected version ranges include the version in the CPE. A CVE counts only when the component is the vulnerable part. A CVE where the component is only the platform that vulnerable software runs on does not count. The CPE must give a version. A CPE with *, - or an empty version field names no version, so the component is skipped. Each scan checks a limited number of CPE components. The remainder is counted as skipped, and the scan is marked incomplete, so it does not close any open finding. These findings link to the NVD.

A CycloneDX SBOM can carry VEX statements in its vulnerabilities section. A VEX statement is your own analysis of one vulnerability in one component. The scan reads these statements. It removes a finding when the statement for that component has the state not_affected, false_positive, resolved or resolved_with_pedigree. The statement must not mark the component's version as affected. A statement with the state exploitable or in_triage keeps the finding. If two statements about the same finding disagree, the finding stays. Version ranges in a statement are not evaluated, so a statement that gives only ranges removes nothing. An open finding that a VEX statement removes is closed at the next scan. The SBOM panel on the threat intelligence page shows how many findings VEX statements removed. When several products ship the same component, a scan across the whole account removes the finding only when every product's SBOM makes the same statement. Separate VEX documents (OpenVEX, CSAF VEX) are not read yet.

A component with no version cannot be checked, because an advisory applies to a range of versions. If the component has a package URL or a CPE, the scan still asks OSV or the NVD for every advisory about the package at any version. The SBOM panel on the threat intelligence page lists each such component as a version review item, with the number of advisories. A review item stays out of the findings, the alerts and the Article 14 count. When a scan has no findings but has review items, the panel shows "Version review needed" and not the all-clear. The panel also gives the number of versionless components that the scan could not check. Add the version to the SBOM, or check each advisory by hand. The NVD lookups for these components use only the part of the per-scan limit that the versioned components leave. A component with no version and no identifier is skipped.

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.