Сканер уязвимостей SBOM

Загрузите lockfile или SBOM и проверьте каждую закреплённую версию по известным уязвимостям — разбор выполняется локально, сопоставление — по базе OSV.

Lockfile — это точный список версий, которые реально устанавливает ваша сборка, и каждая закреплённая версия — это ставка на то, что с тех пор в ней не нашли дыру. Этот сканер читает этот список (package-lock.json, requirements.txt, go.mod или SBOM в формате CycloneDX / SPDX), отправляет только пары «имя — версия» в публичную базу уязвимостей OSV.dev и сообщает, у каких пакетов есть известные уязвимости, насколько они серьёзны, какая версия исправляет каждую из них и есть ли какие-либо из CVE в списке известных эксплуатируемых уязвимостей CISA. Сопутствующее руководство скрывает ли ваш lockfile уязвимости? объясняет, что результаты доказывают, а что — нет. Если сканирование выявило CVE, Bulk CVE Triage поместит его в контекст эксплуатации.

Последнее обновление:

Ваш lockfile или SBOM

Принимаются: package-lock.json, requirements.txt, go.mod, CycloneDX JSON, SPDX JSON. Максимальный размер файла — 5 МБ.

Формат определяется по имени файла и содержимому; вы также можете выбрать его самостоятельно ниже.

🔒 Ваш lockfile разбирается в вашем браузере и никуда не загружается. В OSV.dev отправляются только имена и версии пакетов; в наш собственный сканер — только идентификаторы CVE для проверки флагов KEV.

Результаты сканирования

Сканирование ещё не проводилось. Загрузите или вставьте lockfile или SBOM выше и нажмите «Сканировать на уязвимости».

Ваш lockfile никогда не покидает эту страницу

Разбор полностью выполняется в вашем браузере: файл, который вы загружаете, — или текст, который вы вставляете, — читается локально и никуда не загружается. Наружу отправляются только извлечённые имена и версии пакетов — в публичную базу уязвимостей OSV.dev (без учётной записи, без ключа), чтобы она могла сопоставить их с известными уязвимостями. Затем идентификаторы CVE из совпадений отправляются в собственный сканер этого сайта для проверки по списку CISA KEV. Больше ничего страницу не покидает: ни содержимое файлов, ни пути, ни названия проектов.

Ограничения сканирования

За один запуск сканируется не более 500 пакетов — остальные указываются как непроверенные. Загружается не более 200 сведений об уязвимостях. Результаты берутся из базы OSV для точных версий из вашего файла; если версия пакета базе никогда не встречалась, совпадения не будет, а это не то же самое, что подтверждение безопасности.

Честные ограничения

«Уязвимостей не найдено» означает, что их нет в базе OSV для этих точных версий. Это не означает, что код безопасен: уязвимости, о которых ещё никто не сообщил, вредоносные пакеты, имена-тайпосквоттеры и скомпрометированные релизы — всё это невидимо для проверки, основанной на сопоставлении версий.

Совпадение — точное по версии. Если в вашем файле закреплён диапазон, а не точная версия, он пропускается и указывается как таковой — сканер не будет угадывать, какую версию вы реально установили. То же касается пакетов, экосистему которых сканер не может сопоставить: они указываются как пропущенные и никогда не удаляются молча.

Флаги KEV берутся из одного запроса к собственному сканеру этого сайта (данные CISA KEV, обновляются ежедневно). Если этот запрос не удался или был ограничен по частоте, сканирование всё равно завершается — в столбце KEV просто будет указано «неизвестно», вместо того чтобы блокировать ваши результаты.

Почему закреплённая версия — это поверхность атаки

Lockfile существует потому, что «latest» — это не версия. В нём записано точное дерево, установленное вашей сборкой, чтобы каждая машина и каждый деплой получали один и тот же код. Эта детерминированность и делает lockfile пригодным для сканирования: база уязвимостей индексируется по точному пакету и версии, поэтому закреплённую версию можно оценить одним запросом, а плавающий диапазон — нельзя. Следовательно, сканирование настолько хорошо, насколько хорош файл: коммитьте lockfile, держите его актуальным, и сканер сможет рассказать вам правду о том, что вы поставляете.

Сама проверка намеренно узкая. OSV.dev агрегирует записи об уязвимостях из advisories GitHub, NVD и языковых экосистем и сопоставляет их с вашими версиями. Чего он не может — так это оценить код: пакет без известных CVE всё равно может быть вредоносным, заброшенным или похожим на пакет, который вы хотели установить. Сопоставление версий — это быстрый и дешёвый первый фильтр, который ловит тот самый lodash, который вы забыли обновить, — а не аудит безопасности.

Почему флаг KEV важнее высокого балла CVSS

Балл CVSS измеряет, насколько плоха уязвимость, если её эксплуатировать. Каталог известных эксплуатируемых уязвимостей CISA измеряет другое: эксплуатируется ли она на самом деле, в реальных условиях, прямо сейчас. Уязвимость средней серьёзности из списка KEV заслуживает исправления на этой неделе; критическая CVE, которую никто не превратил в оружие, часто может подождать до следующего планового обновления. Именно поэтому этот сканер отдельно помечает строки KEV, а результаты сортирует сначала по худшей серьёзности — но действовать в первую очередь нужно по значку KEV.

Исправленные версии несут и свой риск. Исправление уязвимости обычно выходит в виде минорного или патч-релиза, но «исправлено в 4.17.21» может также означать изменение поведения, которое сломает вашу сборку, а у некоторых уязвимостей вообще нет исправленной версии — сканер прямо так и говорит, вместо того чтобы её выдумывать. Сначала исправьте элементы KEV, затем критические с опубликованным исправлением, а остальное запланируйте; закрепите новые версии, закоммитьте lockfile и просканируйте заново. Тот же цикл должен быть в CI, где он запускается при каждом pull request, а не раз в квартал.

Лицензии в этом SBOM

Лицензии здесь приведены только из полей лицензий, содержащихся в самом SBOM. В lockfile (package-lock.json, requirements.txt, go.mod) данных о лицензиях нет, поэтому для них ничего не показывается — эта страница не ищет лицензии по каждому пакету, потому что нет публичной базы, которая надёжно их предоставляла бы.

Термины lockfile и SBOM — точно

Lockfile. Файл, в котором записана точная версия каждого пакета, устанавливаемого сборкой, — package-lock.json для npm, requirements.txt с закреплениями == для Python, go.mod/go.sum для Go, — чтобы установки были воспроизводимыми.

SBOM. Software Bill of Materials — машиночитаемый перечень всех компонентов программного обеспечения, обычно в формате CycloneDX или SPDX. Это lockfile, обобщённый на всю цепочку поставок.

OSV.dev. Публичная база уязвимостей Google, агрегирующая advisories из GitHub, NVD и языковых экосистем, с запросами по точному имени пакета, экосистеме и версии.

GHSA. Идентификатор GitHub Security Advisory (GHSA-xxxx-xxxx-xxxx). Большинство уязвимостей npm, PyPI и Go в OSV имеют такой идентификатор, обычно вместе с идентификатором CVE.

CVE. Common Vulnerabilities and Exposures — общая система нумерации (CVE-YYYY-NNNNN), позволяющая каждой базе, сканеру и вендору говорить об одной и той же уязвимости.

CVSS. Common Vulnerability Scoring System — шкала от 0 до 10, показывающая, насколько серьёзна уязвимость, если её эксплуатировать. 9.0+ — CRITICAL, 7.0+ — HIGH, 4.0+ — MEDIUM, ниже 4.0 — LOW.

KEV. Каталог известных эксплуатируемых уязвимостей CISA: уязвимости, эксплуатация которых в реальных условиях подтверждена, каждая — со сроком устранения. Флаг KEV означает «исправляйте сейчас», независимо от балла CVSS.

Fixed version. Первая версия пакета, в которой уязвимости больше нет, взятая из событий диапазона affected в advisory. У некоторых уязвимостей такая версия ещё не опубликована.

Purl. Package URL (pkg:npm/[email protected]) — стандартный способ назвать пакет с указанием его экосистемы и версии. SBOM содержат purl, и именно по ним сканер узнаёт, к какой экосистеме принадлежит компонент.

Часто задаваемые вопросы

Покидает ли мой lockfile браузер?

Нет. Файл разбирается локально и никогда не загружается. Только извлечённые имена и версии пакетов отправляются в OSV.dev — публичную базу уязвимостей, а только идентификаторы CVE из совпадений отправляются в собственный сканер этого сайта для проверки KEV. Содержимое файлов, пути и названия проектов страницу никогда не покидают.

Почему пакет указан как «пропущенный»?

Три причины: строка не является точным закреплением (диапазон вроде ~= или >=, включение -r, директива replace), экосистему нельзя сопоставить с поддерживаемыми OSV.dev, или сканирование достигло лимита в 500 пакетов. Пропущенные записи всегда перечисляются с указанием причины — ничего не удаляется молча.

«Уязвимостей не найдено» — я в безопасности?

Не обязательно. Это означает, что для этих точных версий в базе OSV не зарегистрировано уязвимостей. Незарегистрированные уязвимости, вредоносные пакеты или пакеты-тайпосквоттеры, а также скомпрометированные релизы ни в одной базе уязвимостей не отображаются. Относитесь к сканированию как к первому фильтру, а не как к подтверждению безопасности.

Что исправлять в первую очередь?

Начните с того, что несёт значок KEV, — эти уязвимости эксплуатируются прямо сейчас, и CISA устанавливает срок для каждой. Затем — строки CRITICAL и HIGH, у которых есть опубликованная исправленная версия, начиная с пакетов, которые ваше приложение реально импортирует. Используйте Bulk CVE Triage, чтобы получить контекст эксплуатации для каждой CVE.

У уязвимости нет исправленной версии. Что делать?

Сначала проверьте, не существует ли более новая версия, которую advisory ещё не зафиксировало, — advisories отстают от релизов. Если исправления действительно нет, варианты такие: удалить зависимость, заменить её или смягчить уязвимый путь в коде (например, перестать передавать недоверенные данные в затронутую функцию) и следить за обновлениями advisory. После любого изменения просканируйте заново.