LiMP VPN

Аудит зависимостей по lock-файлу: уязвимости, лицензии и SBOM

Загрузите файлы зависимостей проекта: package-lock.json, yarn.lock, package.json, requirements.txt, pom.xml или build.gradle. Покажем известные уязвимости с версией исправления, лицензии с классом риска, давно не обновляемые и объявленные устаревшими пакеты, зависимость от облачных сервисов и примерный план работ. SBOM в формате CycloneDX можно скачать сразу.

Файлы разбираются в браузере и на сервер не загружаются. Перед проверкой вы увидите, какие пары «пакет@версия» будут отправлены, и сможете исключить внутренние.

Перетащите файлы зависимостей сюда

До 12 файлов, каждый до 15 МБ. Lock-файл даёт самый полный результат.

Поддерживаются: package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json, requirements*.txt, pom.xml, build.gradle, build.gradle.kts. Пока нет: pnpm-lock.yaml, poetry.lock, Pipfile.lock, go.mod, Cargo.lock, composer.lock, Gemfile.lock.

Ваши файлы остаются у вас. Разбор идёт в браузере, файлы не загружаются. На следующем шаге вы увидите, какие пары «пакет@версия» будут отправлены на наш сервер и далее в публичную базу уязвимостей OSV.dev и каталог пакетов deps.dev; внутренние пакеты можно исключить. Мы не сохраняем этот список и не пишем его в журналы.

Что проверяет инструмент

Разбор манифестов идёт в браузере, на сервер уходят только выбранные вами пары «пакет@версия». Каждая находка сопровождается пояснением и следующим шагом.

Известные уязвимости

Сверяем точные версии с базой OSV.dev, которая объединяет GitHub Advisory, PyPA и другие источники. Показываем серьёзность по CVSS, версию исправления и порядок, в котором стоит чинить.

Лицензии

Берём лицензию из lock-файла или реестра и относим её к классу: разрешительная, слабый или строгий копилефт, платная, не определена. Выражения OR и AND разбираются по правилам SPDX.

Свежесть пакетов

Отмечаем пакеты, объявленные устаревшими, давно не выпускавшие релизы и сильно отстающие по версии. Опасно сочетание «не обновляется» и «есть уязвимость без исправления».

Когда пригодится

Приёмка проекта от подрядчика

Перед подписанием акта увидеть состав зависимостей, известные уязвимости и лицензионные риски, а не верить на слово.

SBOM для заказчика или аудита

Быстро собрать перечень компонентов в CycloneDX без настройки инструментов в CI.

Оценка технического долга

Понять, сколько пакетов пора обновить и сколько это займёт часов, перед планированием спринта или бюджета.

Готовы попробовать?

Скачайте LiMP VPN бесплатно и почувствуйте разницу уже через минуту.

Что такое SBOM и зачем он нужен

SBOM (Software Bill of Materials) — перечень всех сторонних компонентов программы с версиями и лицензиями. Его просят при приёмке проекта, в аудитах безопасности и при передаче продукта заказчику: по нему видно, из чего собрано приложение и на что оно опирается.

CycloneDX — открытый стандарт формата SBOM. Файл в CycloneDX JSON понимают Dependency-Track, сканеры уязвимостей и большинство инструментов управления цепочкой поставок ПО.

Что инструмент не делает

  • Не анализирует исходный код (это не SAST) и не определяет, вызывается ли уязвимый код в вашем приложении.
  • Не проверяет образы контейнеров, пакеты ОС и частные реестры.
  • Не открывает pull request и ничего не исправляет сам.
  • Не заменяет постоянную проверку в CI. Если у вас уже работают Dependabot, Renovate, Snyk, OSV-Scanner или Dependency-Track, этот инструмент нужен для разовых задач: приёмки, оценки и документов.

Почему нужен именно lock-файл

В package.json и requirements.txt обычно записаны диапазоны версий, например ^4.17.0. Какая версия установлена на самом деле, знает только lock-файл. База уязвимостей сопоставляет точные версии, поэтому без lock-файла проверка неполная: пакеты с диапазоном версий показываются, но не проверяются.

Частые вопросы об аудите зависимостей

Нет. Файлы читаются в браузере. На сервер после вашего подтверждения уходят только пары «пакет@версия». Мы не сохраняем этот список и не пишем его в журналы.

Имя и версия пакета: в OSV.dev для поиска уязвимостей и в deps.dev для лицензий и дат релизов. Внутренние пакеты можно исключить перед проверкой, а пакеты из частных реестров исключаются автоматически.

Это перечень компонентов программы в стандартном формате (здесь CycloneDX). Он нужен для приёмки проекта, передачи заказчику, аудитов и подготовки документов о сторонних компонентах.

Нет. Запись относится к версии пакета. Вызывается ли уязвимый код в вашем приложении, инструмент не определяет. Но обновить пакет до исправленной версии обычно стоит.

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

Последний релиз пакета вышел давно. Это признак, а не вердикт: законченные небольшие библиотеки годами не меняются. Опасно сочетание «не обновляется» и «есть уязвимость без исправления» — такой пакет придётся заменить.

Библиотека, которая сама свободна, но работает только с сервисом конкретной компании: AWS, Firebase, Sentry, Stripe и т. п. Это справочная пометка о зависимости от поставщика, а не запрет и не юридическое заключение.

Они работают в вашем CI постоянно. Здесь разовая проверка без установки и настройки: удобно при приёмке проекта, оценке техдолга и подготовке SBOM.