With an open source scanner, the data comes from public databases and your team owns the job of pulling updates and noticing when they stall. With a managed platform, a vendor operates the pipeline and should state a freshness target. In both cases you can measure freshness yourself with a simple test.
Two parts of every scanner
A scanner has an engine, which reads your lockfiles or images, and a database, which says which versions are vulnerable. The engine changes slowly. The database changes every day. Most arguments about open source versus managed are really about who is responsible for the second part.
Where the public data comes from
Several public sources feed most scanners. OSV says it aggregates and indexes vulnerability data from databases that use the OSV schema, and its documentation states a target that data sources be no more than 15 minutes stale, 99.5% of the time. That is a service level objective, not a guarantee.
The GitHub Advisory Database draws on advisories reported on GitHub, the National Vulnerability Database, ecosystem databases such as the Python Packaging Advisory database and RustSec, and community contributions. NIST's NVD, for its part, announced in April 2026 that it now prioritises enrichment for CVEs in the CISA KEV catalog, software used in the federal government, and critical software, and labels others "Lowest Priority".
So the raw material is public and mostly free. The work is in collecting, normalising and matching it to your packages.
Who does what
| Task | Open source scanner | Managed platform |
|---|---|---|
| Pull updates from public sources | Your scanner or your scripts, on your schedule | Vendor pipeline |
| Notice when updates stop | You, if you build an alert | Vendor, and you should ask how it is reported |
| Add vendor or curated data beyond public feeds | You, if you wire it in | Varies, ask what is included |
| Fix wrong or missing matches | You, or an upstream issue | Vendor support path |
| Tell you the data age | Often a timestamp you must read | Should be visible in the product or API |
Test freshness yourself
Do not rely on a promise in either model. Run this check once a quarter.
- Pick a recently published advisory for a package you actually use. Write down the time it appeared in a public source.
- Create or use a throwaway project that pins the vulnerable version.
- Scan it and record when the finding first appears.
- Repeat for two or three advisories in different ecosystems.
- Compare the gaps. A gap of hours is a different situation from a gap of days.
If you run open source tooling, add one more step: confirm that the scheduled job that refreshes the database actually ran, and that failure sends someone a message.
What to ask a vendor
Ask for the data sources, the freshness target and how it is measured, what happens when a source is delayed, and whether the data age is exposed in the product. A clear answer matters more than a fast one.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a newly published advisory changes the status of a component that was clean the day before.
Safeguard provides dependency scanning and continuous monitoring, and you can run a free scan at gold.safeguard.sh/scan to compare its results with your current tool.
Quick check
Is the National Vulnerability Database enough as the only data source?
Usually not. NVD itself says it now prioritises enrichment for some CVEs and labels others lowest priority, so ecosystem specific advisories add coverage and speed.
Does a 15 minute OSV target mean my scanner is 15 minutes behind?
No. That target covers OSV's own ingestion of its sources. Your scanner adds its own refresh schedule on top, so measure the end to end gap.
Sources
Last reviewed: 19 October 2026.
