How CVE Scanning Works
This page explains, in plain language, what happens after an SBOM upload, how components are checked against our local vulnerability database, and why findings are always tied to exact component versions.
For implementation detail and governance context, see the SBOM Best Practices and Vulnerability Management Guide.
1. What we scan
We scan the component list in your uploaded SBOM, including package names, versions, and available package metadata (for example purl). The scanner then evaluates each component entry against the local CVE cache and only keeps vulnerabilities that apply to that specific component and version.
2. Where vulnerability data comes from
- NVD (National Vulnerability Database) is the primary source.
- GitHub Advisories can also be included when GitHub advisory sync is enabled and data is present in cache.
Both sources are stored in the same local CVE cache, so scans run locally first. In normal operation, your SBOM is not matched by repeatedly calling external APIs during every scan.
GitHub advisory coverage is currently strongest for npm ecosystems. If GitHub sync is not configured or stale, results effectively reflect NVD-backed coverage.
3. How matching works
- After upload, the SBOM is normalized (CycloneDX/SPDX), stored, and a scan job is queued.
- For each unique component+version, the scanner searches the local CVE cache for likely matches.
- Candidate CVEs are filtered using CPE/configuration logicCPE (Common Platform Enumeration) and CVE configuration data describe which products and version ranges are actually affected. We use this to confirm a CVE truly applies to the same component and version, instead of matching on name similarity alone. to confirm the CVE targets the same product or package, not only a similar name.
- The component version is then checked against affected version ranges from CVE data.
- A triage pass removes non-applicable and duplicate candidates.
- Only validated findings are persisted and shown in results.
If local data has no match for a component, the platform can optionally perform controlled external fallback lookups (depending on configuration). This improves coverage while keeping local-first behavior.
4. How we reduce false positives and misses
The scanner uses version-aware matching and post-scan triage filters to reduce noisy matches. We continuously harden this flow with oracle-based regression testsRegression tests that compare scanner output against a trusted, deterministic oracle (the local NVD cache + isVersionAffectedByCve matcher) to precisely detect false positives and negatives. that include both vulnerable and clean versions of the same component.
5. What you can expect in results
- Findings are scoped to specific component versions, not package names alone.
- Severity is normalized so teams can prioritize quickly.
- When available, affected ranges, CVE identifiers, and fix hints are included to support remediation planning.
- Scan status moves through queued, running, and completed/failed so progress is visible.
6. Transparency commitment
We publish this process so teams understand how findings are produced, what data sources are used, and where known coverage limits exist. This helps security and compliance teams make informed decisions during CRA readiness and ongoing operations.
If you have additional questions or suggestions to improve this process, please use our contact form.