Advisories come from a mix of package maintainers, registry teams, volunteer curators, government databases and community contributors. A scanner does not write them. It reads them from aggregated sources, so the quality of its findings depends on how those sources are curated and how often the scanner refreshes them.
The chain from flaw to finding
A vulnerability reaches your scan report through several hands. A maintainer or researcher reports a flaw. Someone publishes an advisory. An aggregator normalises it. Your scanner downloads it, matches it against your dependency list and prints a result.
Each step can add delay or error. That is why two scanners can disagree about the same repository on the same day.
Where the records originate
The GitHub Advisory Database README lists the sources it draws on: security advisories reported on GitHub, the National Vulnerability Database, the npm advisory database, the FriendsOfPHP database, the Go vulnerability database, the Python Packaging Advisory Database, the Ruby Advisory Database, the RustSec database, and community contributions. The advisories are stored as files in the Open Source Vulnerability format.
OSV.dev goes one step further. Its data sources page lists dozens of ecosystem and distribution databases that publish in the OSV format, and notes a conversion pipeline for others, including Debian security advisories, Alpine's security database and NVD records for open source software. It also provides bulk exports, which many scanners consume.
Can anyone fix a wrong advisory?
Largely yes, within limits. The GitHub database invites pull requests and says its internal curation team reviews them and either merges or closes them. It also states that it cannot accept community contributions for ecosystems outside its supported list, because the team needs to be able to assess each change.
For a buyer, this matters in two ways. A wrong version range can be corrected, which is good. But a correction takes time, and your scanner will keep reporting the old range until it refreshes.
Questions to put to any scanner project
| Question | Why it matters |
|---|---|
| Which databases do you read? | Coverage differs by ecosystem |
| Do you use curated records or raw CVE data? | Curated records usually name package versions |
| How often is data refreshed? | Stale data means missed fixes |
| What happens with withdrawn records? | Old false alarms should disappear |
| Can I see the source for each finding? | You need a way to verify |
The answers are usually in the documentation. If they are not, that is a finding in itself.
Try it yourself
Open the demo and look at how a single advisory is tied to a package, a version range and a fix. Notice how many separate facts have to be right for one alert to be correct.
Click through it at your own pace, or open it full screen.
What to do with this
Pick three packages you use and compare what two sources say about each. Differences point to where your scanner's answer depends on a choice someone else made. Safeguard's SBOM and dependency scanning is one way to keep your inventory in one place while you do that, and you can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Does the scanner author the vulnerability records?
Usually not. Most open source scanners consume records from public databases and match them to your dependencies.
Is a curated database always more accurate than raw CVE data?
Curation tends to add package names and version ranges, which make matching easier, but errors still happen. Verify important findings against more than one source.
Sources
- GitHub, Advisory Database README
- OSV.dev, Data sources
Last reviewed: 19 October 2026.
