Сергей Попов
Администратор
- 30.12.2015
- 6 159
- 6 946
- Специализация
- OSINT
- Веб-безопасность
- Статус верификации
- ✓ Verified
По данным Anchore, число атак на цепочки поставок ПО выросло на 540% за 2019–2022 и удвоилось ещё раз к 2024-му. При этом, согласно Cycode, от 70 до 90% кодовой базы типичного приложения - это open source и сторонние библиотеки. Анализ зависимостей в безопасности приложений при таких вводных - не опциональная практика, а базовый контроль. Если вы не знаете, что запускается в продакшне, вы не контролируете ни поверхность атаки, ни время реакции на свежую CVE. Точка.
Что такое SCA и почему сканер зависимостей - не «ещё один SAST»
Software Composition Analysis (SCA) - класс инструментов, который сканирует кодовую базу на наличие open source компонентов, сторонних библиотек и всех их зависимостей. SAST ищет ошибки в вашем собственном коде. SCA фокусируется на том, что вы не писали, но используете ежедневно. По данным Palo Alto Networks, большинство уязвимостей в ПО находится не в корневых пакетах, а в зависимостях зависимостей - на несколько уровней глубже, чем видно изpackage.json или pom.xml.Место в kill chain: от Supply Chain Compromise до Malicious Library
С точки зрения MITRE ATT&CK атаки через уязвимые зависимости покрываются конкретными техниками:- Supply Chain Compromise (T1195, Initial Access) - атакующий внедряет вредоносный код в компонент, который затем подтягивается в сборку жертвы.
- Compromise Software Dependencies and Development Tools (T1195.001, Initial Access) - компрометация конкретной библиотеки или инструмента разработки.
- Malicious Library (T1204.005, Execution) - загрузка и выполнение вредоносной библиотеки, замаскированной под легитимную (dependency confusion, typosquatting в npm/PyPI).
- Exploit Public-Facing Application (T1190, Initial Access) - эксплуатация CVE в используемом open source компоненте, доступном из сети.
Прямые и транзитивные зависимости: где прячутся CVE в библиотеках
Когда вы добавляетеspring-boot-starter-web в Java-проект, вы не добавляете одну библиотеку - вы тянете десятки транзитивных зависимостей. По данным Endor Labs, транзитивные зависимости составляют от 70 до 90% общего объёма open source в проекте. Уязвимости чаще всего находятся именно в этих компонентах, которые вы даже не выбирали.Проблема глубже: многие SCA-инструменты сканируют только прямые зависимости или дают поверхностный анализ дерева. Endor Labs прямо указывает, что отдельные решения просто пропускают неподдерживаемые языки или пакетные менеджеры без уведомления - создавая слепые зоны в покрытии. А по данным Cycode, без SCA-мониторинга компрометированные библиотеки из npm или PyPI могут красть credentials, создавать бэкдоры или выполнять произвольные действия в продакшне. И вы об этом не узнаете, пока не станет поздно.
SBOM: управление компонентами через инвентаризацию
Software Bill of Materials (SBOM) - структурированный документ, описывающий все компоненты приложения: прямые и транзитивные зависимости, их версии, лицензии и известные уязвимости. По сути, это инвентаризация вашего ПО, которая напрямую соответствует требованию NIST CSF ID.AM-01 (Asset Management): инвентаризация активов ведётся и поддерживается актуальной. Без SBOM любой поиск уязвимостей в зависимостях - гадание на кофейной гуще.CycloneDX и SPDX - два формата SBOM
Два основных формата управления компонентами поддерживаются разными организациями:| Критерий | CycloneDX | SPDX |
|---|---|---|
| Разработчик | OWASP | Linux Foundation |
| Основной фокус | Безопасность, VEX | Лицензионный комплаенс |
| Форматы | JSON, XML, Protobuf | JSON, RDF, Tag-Value, YAML |
| Поддержка VDR/VEX | Нативно | Через расширения |
| Интеграция с Dependency-Track | Нативно | Нативно |
Для задач анализа зависимостей в безопасности приложений CycloneDX удобнее на практике: он проектировался под security use cases и поддерживает VEX (Vulnerability Exploitability eXchange) - формат, позволяющий указать, применима ли конкретная CVE к вашему деплойменту. По данным Anchore, SCA и SBOM - два дополняющих друг друга элемента: SCA обнаруживает компоненты, SBOM хранит результат в стандартизированном формате, пригодном для обмена между командами.
На практике я рекомендую CycloneDX, если ваша задача - безопасность. SPDX - если приоритет лицензионный комплаенс (а он бывает приоритетом чаще, чем хотелось бы).
Генерация SBOM: Syft и практические команды
Syft от Anchore - один из наиболее зрелых open source инструментов для генерации SBOM. Поддерживает контейнерные образы, файловые системы и архивы:
Bash:
# Генерация SBOM из Docker-образа в формате CycloneDX
syft packages registry:myapp:latest -o cyclonedx-json > sbom.json
# Генерация SBOM из локального проекта
syft dir:./my-java-project -o spdx-json > sbom-spdx.json
# Быстрая проверка SBOM на уязвимости через Grype
grype sbom:./sbom.json --only-fixed--only-fixed в Grype показывает только те CVE, для которых есть исправление - иначе на legacy-проектах список будет подавляющим, и вы просто закроете вкладку. Генерация SBOM в CI/CD на каждый билд - минимальная точка входа в SCA-процесс. Без инвентаризации любая работа с уязвимыми библиотеками ведётся вслепую.Dependency-Track: open-source платформа для поиска уязвимостей в зависимостях
OWASP Dependency-Track - платформа для непрерывного анализа компонентного состава ПО. В отличие от одноразовых CLI-сканеров, Dependency-Track хранит историю SBOM, отслеживает появление новых CVE для уже загруженных компонентов и позволяет управлять политиками на уровне организации.Требования к окружению и развёртывание
Требования к окружению:- Docker + Docker Compose (или Kubernetes для production)
- ОС: Linux, macOS, Windows (через Docker)
- RAM: минимум 4 ГБ для API-сервера, рекомендуется 8 ГБ при более чем 50 проектах
- PostgreSQL 15+ для production (встроенная H2 - только для тестирования, серьёзно, не используйте её в проде)
- Интернет-доступ для обновления баз NVD/OSV (или зеркало для air-gapped сред)
YAML:
# docker-compose.yml (минимальная конфигурация)
services:
dtrack-apiserver:
image: dependencytrack/apiserver:latest
ports: ["8081:8080"]
environment:
- ALPINE_DATABASE_MODE=external
- ALPINE_DATABASE_URL=jdbc:postgresql://postgres:5432/dtrack
depends_on: [postgres]
dtrack-frontend:
image: dependencytrack/frontend:latest
ports: ["8080:8080"]
postgres:
image: postgres:15
environment:
POSTGRES_DB: dtrack
POSTGRES_PASSWORD: changemecurl -X PUT -H "X-Api-Key: ..." -F "bom=@sbom.json" https://dtrack/api/v1/bom - и вы получаете полную картину: какие компоненты в каком проекте, какие CVE им соответствуют, какой CVSS-score.Главная ценность - непрерывный мониторинг. SBOM загружен сегодня - всё чисто. Завтра появляется новая CVE в одной из зависимостей - Dependency-Track шлёт уведомление через webhook, email или интеграцию с Jira. Это принципиально отличается от одноразового сканирования в CI/CD, где результат забывается сразу после прохождения pipeline.
Ограничения Dependency-Track и когда не использовать
| Аспект | Сильная сторона | Ограничение |
|---|---|---|
| Мониторинг | Непрерывный, с историей по проектам | Нет inline-интеграции в IDE разработчика |
| Анализ | Корреляция с NVD, OSV, GitHub Advisories | Нет reachability analysis - все CVE помечаются без учёта достижимости |
| Политики | Гибкий policy engine с условиями | Нет автоматической генерации PR с фиксами |
| Масштаб | Подходит для enterprise с сотнями проектов | Требует выделенной инфраструктуры и администрирования |
| Развёртывание | Docker, Kubernetes | Не SaaS - обслуживание и обновления на вас |
Dependency-Track не заменяет SCA-сканер в пайплайне. Его роль - централизованное хранилище SBOM и точка принятия решений по политикам. Для gate-функции в CI/CD нужен Grype, Snyk или OWASP Dependency-Check, а Dependency-Track аккумулирует результаты и обеспечивает видимость на уровне организации. Путать эти роли - типичная ошибка при внедрении.
Snyk: анализ зависимостей в CI/CD пайплайне
Snyk - коммерческая платформа с developer-first подходом к безопасности open source. По данным Cycode, основные возможности: плагины для VS Code, IntelliJ и Eclipse, сканирующие код прямо в редакторе; автоматическая генерация Pull Request с обновлениями уязвимых зависимостей; сканирование контейнерных образов и Kubernetes-конфигураций.Интеграция Snyk в пайплайн
Snyk встраивается в CI/CD через CLI или нативные экшены. Пример шага в GitHub Actions:
YAML:
# .github/workflows/security.yml
- name: Snyk SCA scan
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
command: test
args: --severity-threshold=high --fail-on=upgradable--fail-on=upgradable - практический приём, который стоит взять на вооружение: билд ломается только тогда, когда для уязвимости есть обновление. Блокировать релиз из-за CVE без доступного патча - friction без пользы, разработчики начнут обходить gate через неделю. Snyk также умеет автоматически создавать PR с обновлениями зависимостей, сохраняя совместимость - для небольших и средних команд это ускоряет remediation в разы.Ограничения Snyk и когда нужен другой инструмент
Согласно анализу Endor Labs, у Snyk есть значимые ограничения:- Reachability analysis ограничен. По сравнению со специализированными инструментами Snyk чаще создаёт ложноположительные срабатывания, особенно в проектах с глубокими транзитивными зависимостями.
- Стоимость масштабируется линейно. При росте числа проектов расходы растут существенно. Container scanning, IaC-анализ - только на дорогих тарифах.
- Alert fatigue в legacy-кодовых базах. Согласно Cycode, в унаследованных проектах Snyk генерирует поток уведомлений, на который команда постепенно перестаёт реагировать. Знакомая картина?
- Container scanning уступает специализированным решениям. По данным Cycode, для Docker-образов
trivy image myapp:latestможет дать более полное покрытие, чем Snyk.
Reachability analysis: как отсеять шум в уязвимых библиотеках
Главная боль SCA - alert fatigue. По данным Endor Labs, до 95% уязвимостей, которые находит классический SCA-сканер, unreachable: уязвимая функция в библиотеке существует, но ваш код её никогда не вызывает.Конкретный пример: в популярной утилитной библиотеке обнаружена критическая RCE. Ваше приложение использует только функции форматирования строк, а уязвимость - в модуле парсинга данных, который вы не импортируете и не вызываете ни прямо, ни транзитивно. Классический SCA-сканер пометит это как Critical, потребует немедленного обновления, и разработчик потратит два часа на расследование, чтобы убедиться - угрозы нет. Повторите это 300 раз - и команда перестанет реагировать на алерты вообще. Мальчик, который кричал «волк».
Reachability analysis строит call graph приложения и проверяет, достижима ли уязвимая функция из вашего кода. По данным Cycode, Semgrep Supply Chain сокращает число ложных срабатываний на 98% за счёт dataflow reachability - показывая только те ~2% уязвимостей, которые реально эксплуатируемы в контексте вашего приложения.
| Инструмент | Тип reachability | Ограничения |
|---|---|---|
| Semgrep Supply Chain | Dataflow reachability, 10+ языков | Нет анализа транзитивных зависимостей; статический подход пропускает runtime-уязвимости |
| Endor Labs | Full-stack call graph | Enterprise-ориентирован, требует развёртывания в инфраструктуре |
| Snyk | Базовый reachability | Менее точен, выше false positive rate |
| Dependency-Track | Отсутствует | Помечает все CVE без анализа достижимости |
| Grype, Trivy | Отсутствует | CLI-сканеры без контекста вызовов |
Reachability - это то, что отличает зрелый SCA-процесс от формального сканирования. Без него поиск уязвимостей в зависимостях превращается в генератор шума. Команда учится игнорировать алерты - и вместе с шумом пропускает реальные угрозы.
Сравнение SCA-инструментов для AppSec
| Критерий | Dependency-Track | Snyk | OWASP Dep-Check | Grype + Syft | Trivy |
|---|---|---|---|---|---|
| Тип | Open source, OWASP | Коммерческий | Open source, OWASP | Open source, Anchore | Open source, Aqua |
| SBOM | Центральное хранилище | Частичная поддержка | Отчёт, не SBOM | Syft генерирует, Grype сканирует | Генерирует SBOM |
| Reachability | Нет | Базовый | Нет | Нет | Нет |
| Авто-fix PR | Нет | Да | Нет | Нет | Нет |
| Непрерывный мониторинг | Да | Да (SaaS) | Нет | Нет | Нет |
| Контейнеры | Через SBOM | Да | Нет | Да | Нативно |
| Стоимость | Бесплатно (инфра ваша) | От бесплатного до enterprise-тарифов | Бесплатно | Бесплатно | Бесплатно |
| Когда использовать | Централизация SBOM для enterprise | CI/CD gate + авто-ремедиация | Одноразовое сканирование Java/Maven | CLI-сканирование + генерация SBOM | Универсальный сканер контейнеров |
| Когда НЕ использовать | Нужна авторемедиация и IDE-плагины | Бюджет ограничен, десятки проектов | Нужен непрерывный мониторинг | Нужна централизация и политики | Нужен policy engine |
Типичная комбинация для enterprise: Syft для генерации SBOM в CI/CD + Dependency-Track для централизованного хранения и мониторинга + Snyk или Grype как quality gate в пайплайне. Согласно OWASP DevSecOps Maturity Model (DSOMM), зрелая практика SCA включает автоматизированную генерацию SBOM, непрерывный мониторинг и policy enforcement - ни один инструмент в одиночку не покрывает все три задачи.
Управление рисками третьих сторон: от алерта до исправления
На одном проекте с Java-монолитом и 400+ транзитивными зависимостями OWASP Dependency-Check выдал 1200+ алертов. Приоритизация по CVSS бесполезна, когда половина Critical - unreachable. Только комбинация SBOM в Dependency-Track, reachability-фильтрация и EPSS-score позволила свести actionable backlog до 40 тикетов. Остальные 1160 были закрыты с waiver и документированным обоснованием - это тоже часть процесса, а не «забыли и ладно».
Моя позиция, которую я занимаю уже несколько лет: SCA - это не про «поставить сканер». Это про непрерывное управление software supply chain как активом. Кто относится к open source как к бесплатному ресурсу без учёта - получает моменты вроде Log4Shell, когда никто в компании не может за 30 минут ответить на вопрос «какие наши сервисы это используют». Dependency-Track плюс SBOM закрывают эту проблему, но при одном условии: SBOM генерируется на каждый билд и живёт в централизованном реестре, а не в артефактах CI, которые никто не открывает.
И ещё одна неудобная правда: Sonatype прямо указывает, что бесплатные SCA-решения «typically lack automation, remediation, guidance, policy enforcement, and SBOM support - and more importantly, deliver inaccurate results based on poor datasets». Команда, которая поставила Grype в пайплайн и считает, что «у нас есть SCA», может оказаться в худшей позиции, чем команда без SCA, но с честным пониманием своих слепых зон. Первая имеет ложное чувство безопасности. Выход - комбинировать open source инструменты для генерации и сканирования (Syft, Grype, Trivy) с платформой для управления (Dependency-Track) и по мере роста зрелости добавлять reachability и automated remediation.
Половинчатый SCA хуже отсутствия SCA, потому что он создаёт иллюзию контроля, которого нет. Проверьте прямо сейчас: сколько времени вашей команде нужно, чтобы ответить на вопрос «какие наши сервисы используют библиотеку X версии Y»? Если ответ - больше 15 минут, у вас нет работающего SCA-процесса. Есть сканер в пайплайне. Это разные вещи.
