What to compare
- package, ecosystem and installed version
- advisory identifier and aliases
- affected and fixed version ranges
- evidence of known exploitation
- fix, mitigation and verification step
Read the sources
OSV API ↗
Queries for known open-source vulnerabilities by package version, commit or advisory identifier, with a batch endpoint.
Public API documentation. Its FAQ says the API currently has no rate limits; use batch queries for long dependency lists. OSV aggregates records from many source databases, each with its own licence listed on the OSV data page. Keep the advisory ID and fixed version with each finding.
GitHub global security advisories API ↗
Endpoints for listing and reading GitHub Advisory Database entries, filtered by ecosystem, affected package and advisory type.
Use the documented API with its authentication and request limits. Malware advisories are excluded unless requested. GitHub publishes the advisory data under CC BY 4.0 in a public repository. Distinguish reviewed advisories from unreviewed ones in any report.
CISA Known Exploited Vulnerabilities catalog ↗
Vulnerabilities that CISA lists as known to be exploited, with dates added, remediation due dates, required actions and ransomware-use flags.
Public catalog with CSV and JSON downloads and a JSON schema. Its due dates apply to US federal civilian agencies, not to other organizations. Absence from the catalog does not make a vulnerability safe to ignore. Match the exact product and version before acting on an entry.
When to look again
Before a release, after adding a dependency or MCP server, and when an advisory source publishes a matching entry.
Give your agent this question
Check the supplied dependency list against the advisory sources. Report exact matches with advisory links and fixed versions, mark uncertain matches, and propose the smallest safe update with a test. Do not change dependencies.