CVE Tracking Tool for ML Stacks: What to Run in 2026

The best free cve tracking tool for an ML stack is OWASP Dependency-Track fed with CycloneDX SBOMs, backed by OSV-Scanner or pip-audit failing the build in CI. All three match advisories on package name and version via OSV and GitHub data, not NVD CPE strings, and that difference decides whether you hear about the next Ray or MLflow bug.

Put CISA KEV and FIRST’s EPSS on top as the priority filter. Add OpenCVE if you want vendor-level alerts for the parts of the stack that are not pip packages. Most products sold as a “CVE tracker” are a UI over the same handful of feeds, so judge any of them by which feeds it reads and how it matches them.

Which CVE tracking tool should you pick?

Pick by job, not brand. OSV-Scanner or pip-audit gates CI. Dependency-Track is the system of record for what is deployed, re-matched as advisories land. KEV and EPSS rank the queue. OpenCVE watches vendors. Dependabot is fine for repos but only sees the manifest, not the image that shipped six weeks ago.

OSV-Scanner is Google’s official frontend to OSV.dev, which aggregates GitHub Security Advisories, the PyPA advisory database and other OSV-format sources. For Python it reads requirements.txt, poetry.lock, uv.lock, pdm.lock, Pipfile.lock and pylock.toml, and scan image handles container images. Offline mode matters for air-gapped training clusters. One caveat from its own docs: extraction from a requirements.txt with version ranges is best-effort, so feed it pip freeze output.

pip-audit, built by Trail of Bits with Google support and maintained under PyPA, audits a live environment as well as requirements files. That catches the package a notebook installed that never reached requirements.txt. It defaults to the PyPI JSON API and switches to OSV with -s osv. A finding returns exit code 1, and the README states that exit code cannot be suppressed. Waivers go through --ignore-vuln, which accepts GHSA and CVE aliases, so every exception carries an ID someone can grep for.

OWASP Dependency-Track answers the question that matters at 2 a.m.: which deployed images contain ray, and at which versions? It ingests CycloneDX SBOMs, pulls from NVD, GitHub Advisories, OSV, Sonatype OSS Index, Snyk, Trivy and VulnDB, shows EPSS, and pushes notifications to Slack, Teams, Mattermost, webhooks, email and Jira. CycloneDX VEX support lets you record “not exploitable here” decisions instead of re-triaging them every sprint. Turn on the OSV and GitHub sources; an NVD-only configuration inherits every CPE problem below. What belongs in the SBOM you feed it is covered in AI SBOM for ML models.

OpenCVE works the other direction: subscribe to vendors and products, get alerted when matching CVEs appear. It aggregates MITRE, NVD, Red Hat and Vulnrichment data and filters on KEV, EPSS, CVSS and CWE. The community edition is source-available under a Business Source License, self-hosts with Docker, and sends email and webhook alerts. Point it at GPU drivers, container runtimes and vendor appliances, not PyPI dependencies.

Dependabot raises alerts only from GitHub-reviewed advisories, per GitHub’s documentation. Unreviewed advisories, auto-imported from NVD without validity checks, never fire.

Why does CPE matching miss ML vulnerabilities?

CPE matching misses ML bugs because the CPE strings arrive late, cover a few versions, or never arrive. Since April 2026, NIST enriches only CVEs in KEV, in software the federal government uses, or in EO 14028 critical software, and labels the rest “Not Scheduled,” per Help Net Security. Most ML libraries fit none of those buckets.

ShadowRay shows what that looks like in the data. CVE-2023-48022 is the Ray job submission API remote code execution. The OSV record generated from the CVE List entry carries CPE strings for exactly two releases, anyscale:ray:2.6.3 and anyscale:ray:2.8.0, and is flagged isDisputed. Its GitHub-reviewed alias, GHSA-6wgj-66m2-xxp2, maps PyPI ray from version 0 through last_affected 2.49.2 at CVSS 9.8.

Now stack the filters most teams run. A CPE matcher knows about two versions. A KEV filter drops it, because ShadowRay is not in the catalog. A “hide disputed” toggle removes it outright. Meanwhile the EPSS API scored it 0.84 on 7 October 2026, the 99.7th percentile. Only the package-native match flags every install, and only EPSS ranks it where it belongs.

How it works: a minimal pipeline for one serving image

Track what is installed in the artifact you deploy, not what the repo asks for. The sketch below runs in CI against a built serving image and keeps going past findings so the exploitation step still runs.

# 1. Freeze what is actually installed in the image
docker run --rm --entrypoint pip serving-image:2026.10 freeze > serving.lock.txt

# 2. Package-native match; both tools exit 1 on any finding
rc=0
osv-scanner scan source --lockfile 'requirements.txt:serving.lock.txt' --format json > osv.json || rc=1
pip-audit -r serving.lock.txt -s osv -f json > audit.json || rc=1

# 3. Exploitation signal: findings that sit in KEV, plus EPSS for the rest
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | sort -u > kev.txt
grep -oE 'CVE-[0-9]{4}-[0-9]+' osv.json | sort -u > found.txt
comm -12 found.txt kev.txt
curl -s "https://api.first.org/data/v1/epss?cve=$(paste -sd, found.txt)" | jq '.data[] | {cve, epss}'
exit $rc

Then push a CycloneDX SBOM of the same image into Dependency-Track, so next month’s advisory is matched against what is already running. The generators that produce one, model components included, are compared in AI bill of materials tools.

If you build your own feed instead, poll cvelistV5. It refreshes from CVE Services about every seven minutes, and its CISA ADP container carries Vulnrichment CVSS, CWE and CPE data for records NVD may never touch.

What can’t a CVE tracking tool catch?

No CVE tracking tool flags a malicious checkpoint, an unfixable advisory someone muted, or a package installed outside your SBOM. The first is not a CVE at all. The second gets silenced by well-meaning waivers. The third never enters the matcher. All three are where ML incidents actually start.

A pickle checkpoint that runs code on load is working as designed, so no feed will ever page you about it. That is an ingest control, covered in model file format security. Advisories with no fixed version keep firing until someone mutes them; the MLflow advisories that still fail your scanner are the worked example, and the right answer is a VEX statement with a compensating control, not a silent ignore.

What to do

1. Inventory per deployable, not per repo. Freeze or SBOM every serving image, training image and notebook base. Anything a data scientist pip installed at runtime is invisible to manifest scanning.
2. Make package-native sources primary. OSV and GitHub advisories first, NVD as enrichment when it shows up. An NVD-only matcher is now a lagging indicator for ML packages.
3. Never auto-drop DISPUTED or no-fix entries. Route them to a human, read the dispute text, and record the decision as VEX with an owner.
4. Rank with KEV, then EPSS, and treat absence from KEV as “unknown.” ShadowRay was exploited in the wild and still is not listed.
5. Triage on a fixed workflow. The steps from finding to decision are in how to triage an ML-stack CVE, and the broader feed map is in ML model CVE tracking. To check a requirements.txt against tracked ML CVEs by hand, use the ML stack CVE filter.

FAQ

can you track cves for free

Yes. OSV-Scanner, pip-audit and OWASP Dependency-Track are all Apache-2.0 licensed, and the feeds behind them (OSV.dev, the GitHub Advisory Database, CISA KEV, FIRST EPSS and the CVE List) are free to query. Paid products mostly add curation, faster triage and support, not access to vulnerability data you cannot otherwise get.

how do i get alerts when a new cve affects a product i use

Subscribe to the vendor and product in OpenCVE, which sends email or webhook alerts when matching CVEs land and filters by KEV, EPSS and CVSS. For Python dependencies, use Dependency-Track or Dependabot notifications instead, since package-level matching beats vendor-name matching for anything installed from PyPI.

is nvd still reliable for cve tracking

NVD is still a valid source of CVE records, but not a reliable matching source for ML packages. Since April 2026 NIST enriches only CVEs in KEV, federal software or EO 14028 critical software, so many new ML CVEs carry no CPE data. Fill the gap with CNA data, CISA Vulnrichment and package-native advisories.

does dependabot catch cves in python ml libraries

Dependabot catches them only after GitHub has reviewed the advisory, and only for manifests in the repository. Unreviewed advisories imported from NVD never raise an alert, and a package installed at runtime in a notebook or serving image is invisible to it. Treat Dependabot as repo hygiene, not as your tracking system.

what is the difference between osv and nvd

OSV maps vulnerabilities to package names and exact versions or commit ranges in an ecosystem such as PyPI, while NVD maps them to CPE product strings. For Python ML stacks, OSV matches what you actually install. OSV.dev also aggregates GitHub Security Advisories and the PyPA database, so one query covers both.