Read a dependency's advisory history in the GitHub Advisory Database and OSV, then look at how many advisories exist, how severe they were, how fast fixes followed, and whether the maintainers credited reporters and published clear affected ranges. A transparent record of fixed problems is often a better sign than silence.
Where to look
- The GitHub Advisory Database holds advisories with GHSA IDs. Reviewed advisories are checked by GitHub and require a description plus ecosystem and package information. Unreviewed ones come from the NVD feed without that validation.
- OSV aggregates vulnerability databases that use the OpenSSF vulnerability format. You can query by package and version through its API or its first-party scanner.
- deps.dev indexes advisories from OSV and shows them beside the dependency graph, for ecosystems including npm, PyPI, Maven, Go, Cargo, NuGet and RubyGems.
- The project's own SECURITY.md or release notes, which may list past fixes.
What to measure
| Question | Why it matters |
|---|---|
| How many advisories in the last two years? | Gives a baseline, not a verdict |
| Severity mix | A pattern of critical issues in parsing code is different from minor ones |
| Time from report to fixed release | Responsiveness, if dates are public |
| Are affected and fixed versions precise? | Shows care for downstream users |
| Same class of bug recurring? | Suggests a design problem |
| Are old branches patched? | Matters if you cannot upgrade majors |
Dates can be hard to find. Do not invent a timeline. If the advisory lacks report and fix dates, compare the publication date against the fixed release date and note that it is an estimate.
Zero advisories is ambiguous
A project with no advisories may be small, new, or unused enough that nobody has looked. It can also be a project that fixes bugs quietly without filing advisories. Neither is a clean bill of health. Look for a security contact and a documented process instead. See how to check a project's security policy.
Watch for malware advisories
The GitHub Advisory Database also holds malware advisories, sourced from the npm security team and the OpenSSF Malicious Packages repository, and you can search them with type:malware. Check the package name and any lookalike names your team might mistype. Our write-up of typosquatting campaigns explains why.
Check your own exposure
History tells you about the maintainers. It does not tell you whether you are exposed today. For that, compare the affected range with the version you pin and see whether your code reaches the vulnerable function.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and look at the affected and fixed versions, the same fields you want to see in a candidate's advisory history.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Is a package with many advisories worse than one with few?
Not necessarily. Popular, widely reviewed packages attract more reports. Judge severity, response and recurrence, not the count alone.
Are unreviewed advisories reliable?
They are published automatically from the NVD feed and are not checked for validity or completeness, so verify before acting on one.
Sources
Last reviewed: 19 October 2026.
