vibecode.wiki
RU EN
~/wiki / bezopasnost / osv-deb-tvoi-lichnii-hit

OSV.dev is your personal shield against open source vulnerabilities

◷ 6 min read 2/22/2026

Next step

Open the bot or continue inside this section.

$ cd section/ $ open @mmorecil_bot

Article -> plan in AI

Paste this article URL into any AI and get an implementation plan for your project.

Read this article: https://vibecode.morecil.ru/en/bezopasnost/osv-deb-tvoi-lichnii-hit/ Work in my current project context. Create an implementation plan for this stack: 1) what to change 2) which files to edit 3) risks and typical mistakes 4) how to verify everything works If there are options, provide "quick" and "production-ready".
How to use
  1. Copy this prompt and send it to your AI chat.
  2. Attach your project or open the repository folder in the AI tool.
  3. Ask for file-level changes, risks, and a quick verification checklist.

OSV.dev is a distributed database of vulnerabilities specifically for open source. Not a dry NVD with a bunch of false positives, but a precise, developer-friendly thing that says, "This version of the package you have is vulnerable, but this one is no longer." And here's how to fix it.

What is OSV.dev

Imagine a huge warehouse of all known holes in open source packages. But instead of putting everything in a pile (as in normal databases), Google did this:

  • Each bug is described in a special OSV format (JSON diagram from OpenSSF).
  • It specifies which versions of the package or even which git commits are vulnerable.
  • The data is not taken from “where it came from”, but from authoritative sources of each ecosystem: GitHub Security Advisories, PyPA, RustSec, Debian, Ubuntu, OSS-Fuzz and 20+.

As of February 2026, there are more than *585,000 vulnerabilities in the database. The fattest ecosystems:

  • npm - 214k +
  • Debian - 52 k +
  • Ubuntu - 50 k +
  • PyPI - 17k+ etc.

Website: https://osv.dev/ Documentation: https://google.github.io/osv.dev/

Why it's cooler than conventional CVE/NVD

The usual databases say, "The package has a vulnerability, version 1.0 to 10.0." And you're sitting there thinking, "Does my 2.3.4 hit or not?"

OSV says exactly:

json
"affected": [
  {
    "package": { "ecosystem": "PyPI", "name": "jinja2" },
    "ranges": [
      {
        "type": "SEMVER",
        "events": [
          { "introduced": "2.4.1" },
          { "fixed": "3.1.0" }
        ]
      }
    ]
  }
]

Or even on git commits: “Everything from abc123 commit to def456 is vulnerable.”.

Plus there are aliases (CVE-2023-12345 → OSV-2023-XYZ), references, severity, details in human language.

How it works

  1. Authoritative sources (Debian, PyPI, etc.) publish vulnerabilities in OSV format.
  2. OSV.dev aggregates them, enriches them (does bisection by commits, counts versions, adds PURL).
  3. Everything is in the public GCS bundle of gs://osv-vulnerabilities and is available through the API.
  4. Updates every few minutes.

No "manual" database updates - everything is automatic and open.

How to use OSV.dev: 4 levels from beginner to pro

Level 1. Just look at the site

Go to https://osv.dev/ → enter the name of the package or CVE. You will see all known holes, affected versions, fixes, links.

Level 2. OSV-Scanner is your CLI guard

Installation (once):

bash
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@v2
# or via Homebrew (macOS):
brew install osv-scanner

The most useful teams:

Scan the entire project recursively (seeks all lock files yourself):

bash
osv-scanner -r .

Scan a specific lock file (npm, poetry, requirements.txt, Cargo.lock, etc.):

bash
osv-scanner --lockfile=package-lock.json
osv-scanner --lockfile=poetry.lock

Scan Docker image:

bash
osv-scanner scan image --serve alpine:3.12

**Automatically fix * (experimental feature, but already fire):

bash
# Интерактивно
osv-scanner fix -M package.json -L package-lock.json

# Неинтерактивно
osv-scanner fix --non-interactive --strategy=in-place -L package-lock.json

Output in JSON (to feed Claude):

bash
osv-scanner -r . --format json > vulnerabilities.json

Level 3: GitHub Actions

Create a .github/workflows/osv-scan.yml file:

yaml
name: OSV Scan
on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  osv-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: google/osv-scanner-action@v1
        with:
          scan-args: |--lockfile=package-lock.json

Done. Every PR will be checked automatically.

Level 4 API (when you want full control)

Public, no keys, no limits (at 2026).

Examples of curl:

Check the committ:

bash
curl -X POST -d '{"commit": "6879efc2c1596d11a6a6ad296f80063b558d5e0f"}' \
  https://api.osv.dev/v1/query

Check the package version:

bash
curl -X POST -d '{
  "version": "2.4.1",
  "package": {
    "name": "jinja2",
    "ecosystem": "PyPI"
  }
}' https://api.osv.dev/v1/query

Batch query (many packages at once) – look in docs.

How does that fit into AI

**Prompt #1: Make my project safe from scratch **

code
Create a full GitHub workflow with osv-scanner in CI/CD.
Plus add a pre-commit hook that runs the osv-scanner locally.
Plus the update-deps.sh script, which updates dependencies and immediately checks OSV.
All in one message, ready for copypast.

Prompt #2: “Analyze the report and fix it” **

code
Here is the osv-scanner conclusion in JSON: [insert the contents of vulnerabilities]. json
For each vulnerable package:
1. Explain in simple words what's broken.
2. Offer a minimum version update.
3. Write a command to update this particular package.
4. Tell me if you need to change the code after the update.
Answer in Markdown + ready-made command format.

Prompt #3: Integrate the OSV API directly into my bot

code
Write the Python function check dependencies vulnerabilities() that:
Parsite requirements.txt or pyproject.toml
- makes a batch request to https://api.osv.dev/v1/querybatch
If it finds vulnerabilities with severity HIGH/CRITICAL, it sends me a notification in Telegram.
Use aiohttp + pydantic. Add caching to Redis.

**Prompt #4: Make a safety dashboard **

code
Create a streamlit dashboard that every 6 hours:
- launches osv-scanner on my repository
Shows a beautiful vulnerability chart
Send a summary to Telegram if critical.
Full code + Deploy instructions on the Railway.

Claude Opus 4.6 and Codex 5.3 work just fine.

Useful life hacks

  • Running osv-scanner -r . before each git push is a 3-day habit.
  • In pre-commit-config.yaml add hook osv-scanner
  • If your project is on Docker, scan images in CI, not just the source code.
  • Save reports in Git - then easy to track when the hole has closed.
  • For monopos (many packages), use --format json + Python script that parses and outputs beautifully.

Cons

  • Not all vulnerabilities are in the database (but coverage is growing very quickly).
  • For very fresh 0-day can be a delay of 1-2 days.
  • Remediation fix is still experimental - sometimes you need pens.

References: