Найти в Дзене
Vibecode Wiki

OSV.dev — твой личный щит от уязвимостей в open source

OSV.dev — это распределённая базу уязвимостей специально под open source. Не сухую NVD с кучей ложных срабатываний, а точную, понятную разработчикам штуку, которая говорит: «Вот эта версия пакета у тебя уязвима, а вот эта — уже нет. И вот как пофиксить». Представь огромный склад всех известных дыр в open source пакетах. Но вместо того чтобы сваливать туда всё в кучу (как в обычных базах), Google сделал так: На момент февраля 2026 в базе больше 585 000 уязвимостей. Самые жирные экосистемы: Сайт: https://osv.dev/ Документация: https://google.github.io/osv.dev/ Обычные базы говорят: «У пакета уязвимость, версия от 1.0 до 10.0». А ты сидишь и думаешь: «А моя 2.3.4 попадает или нет?» OSV говорит точно: "affected": [ { "package": { "ecosystem": "PyPI", "name": "jinja2" }, "ranges": [ { "type": "SEMVER", "events": [ { "introduced": "2.4.1" }, { "fixed": "3.1.0" } ] } ] } ] Или даже по git-коммитам: «уязвимо всё от коммита abc123 до def456». Плюс есть алиасы (CVE-2023-12345 → OSV-2023-XYZ), сс
Оглавление

OSV.dev — это распределённая базу уязвимостей специально под open source. Не сухую NVD с кучей ложных срабатываний, а точную, понятную разработчикам штуку, которая говорит: «Вот эта версия пакета у тебя уязвима, а вот эта — уже нет. И вот как пофиксить».

Что такое OSV.dev

Представь огромный склад всех известных дыр в open source пакетах. Но вместо того чтобы сваливать туда всё в кучу (как в обычных базах), Google сделал так:

  • Каждый «баг» описан в специальном OSV-формате (JSON-схема от OpenSSF).
  • Там точно указано, какие версии пакета или даже какие git-коммиты уязвимы.
  • Данные берутся не «откуда попало», а из авторитетных источников каждой экосистемы: GitHub Security Advisories, PyPA, RustSec, Debian, Ubuntu, OSS-Fuzz и ещё 20+.

На момент февраля 2026 в базе больше 585 000 уязвимостей. Самые жирные экосистемы:

  • npm — 214k+
  • Debian — 52k+
  • Ubuntu — 50k+
  • PyPI — 17k+ и т.д.

Сайт: https://osv.dev/ Документация: https://google.github.io/osv.dev/

Почему это круче, чем обычные CVE/NVD

Обычные базы говорят: «У пакета уязвимость, версия от 1.0 до 10.0». А ты сидишь и думаешь: «А моя 2.3.4 попадает или нет?»

OSV говорит точно:

"affected": [

{

"package": { "ecosystem": "PyPI", "name": "jinja2" },

"ranges": [

{

"type": "SEMVER",

"events": [

{ "introduced": "2.4.1" },

{ "fixed": "3.1.0" }

]

}

]

}

]

Или даже по git-коммитам: «уязвимо всё от коммита abc123 до def456».

Плюс есть алиасы (CVE-2023-12345 → OSV-2023-XYZ), ссылки, severity, детали на человеческом языке.

Как это работает

  1. Авторитетные источники (Debian, PyPI и т.д.) публикуют уязвимости в OSV-формате.
  2. OSV.dev агрегирует их, обогащает (делает бисекцию по коммитам, считает версии, добавляет PURL).
  3. Всё лежит в публичном GCS-бакете gs://osv-vulnerabilities и доступно через API.
  4. Обновления — каждые несколько минут.

Никаких «ручных» обновлений баз — всё автоматически и открыто.

Как использовать OSV.dev: 4 уровня от новичка до про

Уровень 1. Просто посмотреть на сайте

Зайди на https://osv.dev/ → введи название пакета или CVE. Увидишь все известные дыры, affected версии, фиксы, ссылки.

Уровень 2. OSV-Scanner — твой CLI-охранник

Установка (один раз):

go install github.com/google/osv-scanner/v2/cmd/osv-scanner@v2

# или через Homebrew (macOS):

brew install osv-scanner

Самые полезные команды:

Сканировать весь проект рекурсивно (ищет все lock-файлы сам):

osv-scanner -r .

Сканировать конкретный lock-файл (npm, poetry, requirements.txt, Cargo.lock и т.д.):

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

osv-scanner --lockfile=poetry.lock

Сканировать Docker-образ:

osv-scanner scan image --serve alpine:3.12

Автоматически фиксить (экспериментальная фича, но уже огонь):

# Интерактивно

osv-scanner fix -M package.json -L package-lock.json

# Неинтерактивно

osv-scanner fix --non-interactive --strategy=in-place -L package-lock.json

Вывод в JSON (чтобы скормить Claude):

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

Уровень 3. GitHub Actions

Создай файл .github/workflows/osv-scan.yml:

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

Готово. Каждый PR будет проверяться автоматически.

Уровень 4. API (когда хочешь полный контроль)

Публичный, без ключей, без лимитов (на момент 2026).

Примеры curl:

Проверить коммит:

curl -X POST -d '{"commit": "6879efc2c1596d11a6a6ad296f80063b558d5e0f"}' \

https://api.osv.dev/v1/query

Проверить версию пакета:

curl -X POST -d '{

"version": "2.4.1",

"package": {

"name": "jinja2",

"ecosystem": "PyPI"

}

}' https://api.osv.dev/v1/query

Batch-запрос (много пакетов сразу) — смотри в docs.

Как это всё вписать в ИИ

Промпт №1: «Сделай мой проект безопасным с нуля»

Создай полный GitHub workflow с osv-scanner в CI/CD.

Плюс добавь pre-commit hook, который запускает osv-scanner локально.

Плюс скрипт update-deps.sh, который обновляет зависимости и сразу проверяет OSV.

Всё в одном сообщении, готово к копипасту.

Промпт №2: «Проанализируй отчёт и почини»

Вот вывод osv-scanner в JSON: [вставь содержимое vulnerabilities.json]

Для каждого уязвимого пакета:

1. Объясни простыми словами, что сломано.

2. Предложи минимальное обновление версии.

3. Напиши команду для обновления именно этого пакета.

4. Скажи, нужно ли менять код после обновления.

Отвечай в формате Markdown + готовые команды.

Промпт №3: «Интегрируй OSV API прямо в мой бот»

Напиши Python-функцию check_dependencies_vulnerabilities(), которая:

- парсит requirements.txt или pyproject.toml

- делает batch-запрос к https://api.osv.dev/v1/querybatch

- если находит уязвимости с severity HIGH/CRITICAL — отправляет мне уведомление в Telegram.

Используй aiohttp + pydantic. Добавь кэширование на Redis.

Промпт №4: «Сделай дашборд безопасности»

Создай простой Streamlit-дашборд, который каждые 6 часов:

- запускает osv-scanner на моём репозитории

- показывает красивую таблицу уязвимостей

- отправляет summary в Telegram если есть critical.

Полный код + инструкция деплоя на Railway.

Claude Opus 4.6 и Codex 5.3 работают с этим отлично.

Полезные лайфхаки

  • Запускай osv-scanner -r . перед каждым git push — привычка за 3 дня.
  • В pre-commit-config.yaml добавь hook osv-scanner
  • Если проект на Docker — сканируй образы в CI, а не только исходники.
  • Сохраняй отчёты в Git — потом легко трекать, когда дыра закрылась.
  • Для монопо (много пакетов) используй --format json + скрипт на Python, который парсит и красиво выводит.

Минусы

  • Не все уязвимости ещё в базе (но покрытие растёт очень быстро).
  • Для совсем свежих 0-day может быть задержка 1–2 дня.
  • Remediation fix пока экспериментальный — иногда нужно ручками.

Ссылки: