Check dependencies against OSV.dev

The Vulnerability Check page runs every Composer and npm dependency in your saved SBOMs against the OSV.dev advisory database. OSV is Google's open-source vulnerability feed, aggregating GitHub Security Advisories, RustSec, PyPA, Packagist, npm advisories, and more.

This satisfies CRA Article 14's "monitor for new vulnerabilities" obligation at the point-in-time level. For ongoing monitoring on a cron, see the Monitor.

Prerequisite

You need at least one SBOM saved. Generate SBOMs first from CRA Toolkit → SBOM. The Vulnerability Check page lists every plugin with a saved SBOM in a dropdown.

Run a check

1. Go to CRA Toolkit → Vulnerability Check.
2. Pick a plugin (or All plugins for a multi-product check).
3. Click Run check.

The toolkit batches the dependencies and POSTs them to https://api.osv.dev/v1/querybatch. Response time is usually under 2 seconds even for plugins with 200+ dependencies.

What gets queried

For each component in the SBOM:

• The package ecosystem (Packagist for Composer, npm for npm)
• The package name (vendor/package or scoped @scope/name)
• The exact version installed

OSV returns a list of advisory IDs that affect that version. The toolkit then fetches advisory details (summary, severity, affected version ranges) for any matches.

No site identity, no URL, no license key ever leaves the WordPress install — only {ecosystem, name, version} triples.

Reading the results

For each finding:

• Advisory ID — e.g. GHSA-xxxx-xxxx-xxxx
• Package — which dependency is affected
• Severity — CRITICAL / HIGH / MEDIUM / LOW (when OSV provides a CVSS score)
• Summary — one-line description of the issue
• Affected versions — the range OSV says is vulnerable
• Link — to the full advisory on osv.dev

Zero findings is a clean check. The audit log still records the run so you have evidence of when you last checked.

What to do with findings

CRA Article 14 expects you to "address vulnerabilities without undue delay." In practice, for each finding:

1. Read the advisory and check whether your plugin actually triggers the vulnerable code path
2. Update the dependency to a patched version (or remove it if no patch exists)
3. Ship a new plugin release
4. Document the remediation in your audit trail

The toolkit's audit log records every Vulnerability Check run with a hash, but the remediation evidence has to come from your own changelog and version history.

License-gated

Vulnerability Check requires an active license. The 14-day grace window applies.