OSV-Scanner 2026: Find & Patch AI-Discovered Vulnerabilities Fast

An AI-driven security sweep just flagged nearly 500 vulnerabilities across open source projects written in C, Java and Python. One of them had gone unnoticed for 21 years. Fixes are now going out to maintainers through the “Patch the Planet” effort, and every published advisory also tells attackers exactly where to look. If you depend on open source, and nearly everyone does, OSV-Scanner vulnerability scanning is the fastest free way to find out whether your dependencies are affected and to patch them before someone exploits the gap.

What’s new: AI-found flaws meet OSV-Scanner vulnerability scanning

The headline is scale. Security researchers have used fuzzers and static analyzers for years, but AI-assisted auditing now reads code like a patient human reviewer and runs like a machine. This sweep covered widely used libraries in three ecosystems and produced close to 500 confirmed issues. As expected, many are memory-safety bugs in C. Others are logic and deserialization flaws in Java and Python packages. The 21-year-old bug matters because it shows that “battle-tested” and “audited” are different things. These tools find problems in exactly the old code nobody has touched in years.

Patch the Planet handles the step after discovery. Instead of dumping a list of CVEs and walking away, the effort pushes coordinated fixes to maintainers so patched releases ship upstream. Those fixes then become advisories in public databases, including OSV.dev, the open vulnerability database that aggregates GitHub Security Advisories, PyPI, Maven, Go, Rust, OSS-Fuzz and Linux distro feeds into one schema.

That is where OSV-Scanner comes in. Google built it as the open source client for OSV.dev. It reads your lockfiles, manifests, SBOMs and container images, matches every resolved package version against OSV data, and reports what’s vulnerable. Version 2 added container image scanning, layer-aware results, an HTML report, and a fix command for guided remediation. As AI-discovered open source vulnerabilities reach the database, a scan you rerun today returns different results than the same scan last month. Your code didn’t change. The world’s knowledge about it did.

Why it matters

• The disclosure window is shrinking. Once a fix ships and the advisory is public, attackers can diff the patch and build an exploit, sometimes within days. AI speeds up both discovery and weaponization, so your patch cycle has to speed up too.
• Transitive dependencies are the real exposure. You probably didn’t pick the vulnerable XML parser or compression library. Something you depend on did. Scan the full resolved lockfile, not just your direct imports.
• Volume will keep climbing. If one sweep produces about 500 findings, more will follow. Expect noticeably more advisories through 2026. Manual triage won’t scale, so you need scanning in CI and automated fix PRs.
• C and C++ are the blind spot. Package-manager ecosystems like npm, PyPI and Maven are easy to scan. Vendored C code copied into a repo years ago often isn’t tracked by any manifest, and those bundled libraries are where old bugs hide.
• Upstream fixes don’t reach you automatically. Patch the Planet can get a fix merged upstream, but you keep running the old version until you bump it, rebuild and redeploy.
• Compliance pressure is rising. SBOM requirements, the EU Cyber Resilience Act and customer security questionnaires all assume you can answer “are we affected?” within hours, not weeks.

How to use it today: scan dependencies for vulnerabilities in 15 minutes

This workflow takes you from zero to a working scan, a patch, and a CI gate. It assumes OSV-Scanner v2.

1. Install OSV-Scanner. Pick the install method that matches your setup. Prebuilt binaries for Windows, macOS and Linux are also on the project’s GitHub releases page.

   # Go toolchain
   go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
   
   # macOS / Linux with Homebrew
   brew install osv-scanner
   
   # Verify
   osv-scanner --version

2. Scan your whole repo recursively. OSV-Scanner finds lockfiles and manifests on its own, including package-lock.json, pnpm-lock.yaml, poetry.lock, uv.lock, requirements.txt, Pipfile.lock, pom.xml, gradle.lockfile, go.mod, Cargo.lock and more.

   osv-scanner scan source -r .

   The output is a table of package, version, ecosystem and advisory ID. A non-zero exit code means it found vulnerabilities, which is exactly what CI needs.

3. Target a specific lockfile or SBOM when you need precision.

   # Single lockfile
   osv-scanner scan source -L ./backend/poetry.lock
   
   # Java with Maven (resolves transitive deps)
   osv-scanner scan source -L ./pom.xml
   
   # An SBOM from your build system (SPDX or CycloneDX)
   osv-scanner scan source -L ./dist/app.spdx.json

4. Scan container images too. Many of the C-library findings will reach you through OS packages in your base image, not your app’s manifests.

   osv-scanner scan image myorg/api:2026.10.1
   
   # Or a saved image tarball
   docker save myorg/api:2026.10.1 -o api.tar
   osv-scanner scan image --archive ./api.tar

5. Catch vendored C/C++ code. If you’ve copied library source into third_party/ or vendor/, OSV-Scanner can match it by git commit when that directory is a git checkout or submodule. Initialize submodules before scanning:

   git submodule update --init --recursive
   osv-scanner scan source -r .

   The scanner can’t reliably identify a plain tarball vendored without git history. Keep a manual inventory of those libraries and versions, and check them first against new advisories.

6. Generate a report people will read.

   # Interactive HTML report in your browser
   osv-scanner scan source -r . --serve
   
   # Machine-readable output for dashboards or tickets
   osv-scanner scan source -r . --format json --output osv-results.json
   
   # SARIF for GitHub code scanning
   osv-scanner scan source -r . --format sarif --output osv-results.sarif

7. Patch with the osv-scanner fix command. Guided remediation works today for npm and Maven. It calculates the smallest set of upgrades that clears the most vulnerabilities and avoids breaking major-version bumps unless you allow them.

   # npm: bump versions in place inside the lockfile
   osv-scanner fix --strategy=in-place -L package-lock.json
   
   # npm: relock from the manifest (allows more upgrades)
   osv-scanner fix --strategy=relock -M package.json -L package-lock.json
   
   # Maven: override versions in pom.xml
   osv-scanner fix --strategy=override -M pom.xml
   
   # Limit risk: skip dev deps, cap upgrade depth
   osv-scanner fix --strategy=relock -M package.json -L package-lock.json \
     --ignore-dev --max-depth=3 --upgrade-config=major:false

   fix doesn’t support Python yet, so upgrade directly with your package manager and rescan:

   # Poetry
   poetry update vulnerable-package
   # uv
   uv lock --upgrade-package vulnerable-package
   # pip-tools
   pip-compile --upgrade-package vulnerable-package requirements.in
   
   osv-scanner scan source -r .

8. Suppress false positives explicitly, with an expiry date. Some advisories won’t apply to your code path. Document that in osv-scanner.toml instead of disabling the scanner.

   [[IgnoredVulns]]
   id = "GHSA-xxxx-xxxx-xxxx"
   ignoreUntil = 2026-12-31
   reason = "Vulnerable parser function is never called; tracked in SEC-412"

9. Gate it in CI. Google maintains an official GitHub Action with reusable workflows for pull requests and scheduled scans. Pin it to a release tag.

   # .github/workflows/osv-scanner.yml
   name: OSV-Scanner
   on:
     pull_request:
       branches: [main]
     schedule:
       - cron: "30 6 * * 1-5"
     push:
       branches: [main]
   
   permissions:
     actions: read
     contents: read
     security-events: write
   
   jobs:
     scan-scheduled:
       if: ${{ github.event_name == 'push' || github.event_name == 'schedule' }}
       uses: "google/osv-scanner-action/.github/workflows/osv-scanner-reusable.yml@v2.0.0"
     scan-pr:
       if: ${{ github.event_name == 'pull_request' }}
       uses: "google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.yml@v2.0.0"

   The PR workflow fails only on newly introduced vulnerabilities, so existing debt won’t block every merge on day one. The scheduled run catches advisories published after code ships. At the current rate of new advisories, you need that daily run.

10. Pair it with Dependabot security updates for automatic PRs. OSV-Scanner finds problems and Dependabot opens fix PRs. Running both is not redundant.

    # .github/dependabot.yml
    version: 2
    updates:
      - package-ecosystem: "pip"
        directory: "/"
        schedule:
          interval: "daily"
        open-pull-requests-limit: 10
      - package-ecosystem: "maven"
        directory: "/"
        schedule:
          interval: "daily"
      - package-ecosystem: "docker"
        directory: "/"
        schedule:
          interval: "weekly"

    Then enable “Dependabot security updates” under the repo’s Code security settings so you get PRs for vulnerable versions, not just routine version bumps.

How OSV-Scanner compares to other dependency scanners

OSV-Scanner isn’t the only option, but it covers the most ground for the price, which is zero. Here’s how it fits next to the tools most teams already use.

Tool	Cost	Data source	Auto-fix	Containers	Best for
OSV-Scanner	Free, open source	OSV.dev (aggregates GHSA, PyPI, OSS-Fuzz, distros)	Guided fix for npm and Maven	Yes (v2)	Multi-ecosystem repos, CI gates, offline scans
Dependabot	Free on GitHub	GitHub Advisory Database	Yes, opens PRs	Dockerfile base-image bumps	Hands-off patch PRs on GitHub repos
Trivy	Free, open source	Multiple feeds incl. GHSA and distro trackers	No	Yes, a core strength	Container, IaC and Kubernetes scanning
Snyk Open Source	Freemium, paid tiers	Proprietary curated database	Yes, fix PRs	Yes (Snyk Container)	Teams wanting a managed dashboard and support
pip-audit / npm audit	Free	PyPA advisories / GHSA	Partial (--fix)	No	Quick single-ecosystem checks

Our recommendation: use OSV-Scanner as the CI gate and source of truth, Dependabot to open patch PRs, and Trivy if containers and infrastructure-as-code make up a big part of what you ship. Pay for a commercial tool only when you need reachability analysis or a compliance dashboard that free tools can’t provide.

What’s next

AI-discovered vulnerabilities will become a steady flow, not a one-off event. The tooling behind this sweep will get cheaper and more widely available, and defenders and attackers alike will run it against the same popular libraries. The bottleneck is shifting from discovery to maintainer capacity. One or two volunteers maintain many critical projects, and Patch the Planet works because it sends them ready-made fixes instead of bug reports. Watch whether that model gets lasting funding. If it doesn’t, the backlog of known-but-unpatched issues will grow.

On the tooling side, watch for fix support beyond npm and Maven, with Python the obvious next candidate. Also watch for better call-graph reachability analysis, which tells you whether vulnerable code is reachable from your code at all. OSV-Scanner already offers experimental reachability for some languages, and as advisory volume climbs, this feature will cut alert fatigue more than any other. Better detection of vendored C and C++ code is the remaining gap, since that’s where the oldest bugs hide.

Open source dependency patching in 2026 is becoming an operations discipline, not a quarterly chore. The teams that come out ahead will run scheduled scans, merge automated PRs, keep a documented ignore policy, and assign an owner who merges security bumps within days. Set that up now, while the queue is still manageable.

Frequently Asked Questions

Is OSV-Scanner vulnerability scanning really free?

Yes. OSV-Scanner is open source under the Apache 2.0 license, and the OSV.dev database is free to query. There are no seat limits or paid tiers. You can also download the database and scan fully offline with the --offline flag.

Will OSV-Scanner catch the AI-discovered open source vulnerabilities from this sweep?

Yes, once they’re published as advisories in OSV.dev, which happens as Patch the Planet fixes ship and receive CVE or GHSA IDs. That’s why a scheduled daily scan matters more than a one-time scan. The main exception is vendored C code with no git metadata, which the scanner can’t reliably identify.

How is the osv-scanner fix command different from Dependabot security updates?

osv-scanner fix runs locally or in CI and calculates the minimal set of upgrades across your whole dependency graph, with controls over upgrade depth and major-version bumps. Dependabot runs on GitHub’s side and opens one PR per vulnerable package. Use fix for a deliberate cleanup sprint and Dependabot for continuous upkeep.

What about Python projects, since fix doesn’t support them yet?

Scan with OSV-Scanner, upgrade with your package manager (poetry update, uv lock --upgrade-package or pip-compile --upgrade-package), then rescan to confirm. Dependabot also supports pip, Poetry and uv lockfiles for automatic PRs.

How do I handle a vulnerability with no fixed version yet?

Check whether your code reaches the vulnerable function. If it doesn’t, add a time-limited entry to osv-scanner.toml with a reason and a ticket reference. If it does, mitigate with input validation, feature flags or network isolation, and watch the upstream repo so you can upgrade as soon as a patch lands.

How often should we scan?

Scan on every pull request to block newly introduced vulnerabilities, and daily against your main branch and deployed images to catch new advisories. With advisory volume rising, a weekly scan leaves too large a window.