Every SCA finding is only as good as the advisory data behind it. Ask each vendor which sources they ingest, how they merge records that describe the same flaw, how quickly updates arrive, and what they do when sources disagree. A vendor that can answer plainly has usually thought about it.
The common source types
| Source type | What it offers | Typical gap |
|---|---|---|
| Ecosystem databases | Advisories written by or for a package community | Coverage differs by ecosystem |
| Aggregated open data | Many databases in one format | Quality varies by contributor |
| Government listings | Broad CVE coverage and exploited-in-the-wild lists | Package mapping can be loose |
| Vendor research | Faster or deeper entries for some flaws | May not be public |
The OSV project documents its current data sources, which include the GitHub Advisory Database, the Go Vulnerability Database, the Rust Advisory Database, and the OpenSSF Malicious Packages data, among others. It also converts some other feeds. This shows how many places an advisory can originate.
Why merging matters
The same flaw can appear under several identifiers, such as a CVE number and a GitHub advisory number. The OSV schema has an aliases field for exactly this. If a tool does not merge them, you can see one flaw as two findings or miss that two records are the same.
Questions to ask
- Which sources do you read for each ecosystem we use?
- Do you add your own research, and how is it labeled?
- How do you merge aliases, and how do you show them?
- How soon after a source publishes does the record reach my results?
- If two sources give different severity or affected ranges, which wins, and can I see both?
- How do you treat withdrawn records? The OSV format has a withdrawn field, and findings built on withdrawn records should clear.
- Do you include malicious package data as well as vulnerabilities?
A test you can run
Pick three recent advisories from different ecosystems. Note when each was published at its source. Check when each appears in each candidate tool. Record the gap in hours or days. Also find one withdrawn record and see whether the tool still reports it.
Use KEV as a separate signal
CISA's Known Exploited Vulnerabilities catalog is not an advisory feed for packages. It is a list of flaws with evidence of exploitation, and CISA recommends it as an input to prioritization. Ask whether the tool shows KEV status next to each finding.
A worked example: one flaw, three records
A flaw is reported in a JavaScript library. Three records may exist.
- A national listing assigns a CVE number and a general description.
- An ecosystem or community advisory database records a GHSA identifier with package names and version ranges specific to the registry.
- A vendor research feed adds a note on exploitability and a fix that backports to an older line.
In the OSV format, the second record can list the CVE and other identifiers under aliases, so a consumer can tell they describe the same issue. If your tool shows three findings, it merged nothing. If it shows one finding with three identifiers, it merged well. If it shows one finding and loses the backport information, it merged poorly.
Ask to see this on a real advisory during your trial.
Step by step: audit a tool's data handling
- Pick one advisory published in the last month in each ecosystem you use.
- Find the original record and note publication time, affected ranges, and aliases.
- In each candidate tool, find the finding on a test project that uses the affected version.
- Compare the identifiers shown, the affected range, the severity, and the fixed version.
- Record the time between publication and appearance.
- Find one record that has been withdrawn and confirm the tool does not report it.
- Look for a record with a range that ends in a "last affected" value rather than a fixed version, and see how the tool presents it.
- Ask the vendor to explain any differences.
Severity is not one number
Records can carry severity scores from several sources, with different scoring versions. OSV allows a severity entry at the vulnerability level and at the affected package level. When a tool shows one score, ask which source and version it came from. Two tools can both be right and still show different numbers.
Licenses on the data itself
Advisory data has licenses of its own. The OSV data source list notes licenses for each source, such as CC-BY 4.0 for several and CC0 for others. If you plan to export or republish advisory data, such as in a customer report, check attribution requirements. This is a compliance detail that is easy to overlook.
Coverage by ecosystem
Not all ecosystems are equally covered. The OSV list of covered ecosystems includes many, such as npm, PyPI, Maven, Go, crates.io, NuGet, Packagist, RubyGems, and Pub, but your stack may include something less common. List your ecosystems and ask each vendor to show coverage for each, with an example advisory.
Keep a source map
Write a short table of ecosystem, primary advisory source, secondary sources, and known gaps. Update it when you add a tool or ecosystem. It makes incident response faster, because you know where to look when something is announced.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and look for where its identifier, severity, and fix information are shown, then ask where each piece came from.
Quick check
Is more sources always better?
Not by itself. More sources help only if the tool merges duplicates and shows where each value came from.
Why do findings disappear after a rescan?
A source may have withdrawn or corrected a record, or you may have upgraded a package. Check the record history.
What should a tool show when sources disagree on severity?
It should show each source and score, say which one it uses by default, and let you see the others. Hiding the disagreement makes triage harder.
Sources
Last reviewed: 19 October 2026.
