OSV.dev is your personal shield against open source vulnerabilities
Next step
Open the bot or continue inside this section.
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
- Copy this prompt and send it to your AI chat.
- Attach your project or open the repository folder in the AI tool.
- 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:
"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
- Authoritative sources (Debian, PyPI, etc.) publish vulnerabilities in OSV format.
- OSV.dev aggregates them, enriches them (does bisection by commits, counts versions, adds PURL).
- Everything is in the public GCS bundle of gs://osv-vulnerabilities and is available through the API.
- 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):
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):
osv-scanner -r .
Scan a specific lock file (npm, poetry, requirements.txt, Cargo.lock, etc.):
osv-scanner --lockfile=package-lock.json
osv-scanner --lockfile=poetry.lock
Scan Docker image:
osv-scanner scan image --serve alpine:3.12
**Automatically fix * (experimental feature, but already fire):
# Интерактивно
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):
osv-scanner -r . --format json > vulnerabilities.json
Level 3: GitHub Actions
Create a .github/workflows/osv-scan.yml file:
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:
curl -X POST -d '{"commit": "6879efc2c1596d11a6a6ad296f80063b558d5e0f"}' \
https://api.osv.dev/v1/query
Check the package version:
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 **
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” **
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
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 **
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 eachgit pushis 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: