Безопасная разработка: Часть 4 — SCA: проверка зависимостей

Большая часть кода в современном приложении написана не вами. Фреймворк, драйвер базы данных, библиотеки для логирования, разбора JSON и работы с изображениями — всё это чужой открытый код, и каждая из этих библиотек тянет за собой ещё несколько. Уязвимость в любой из них становится уязвимостью вашего приложения. Проверять эту часть проекта — задача SCA.

Что такое SCA

SCA (Software Composition Analysis, анализ состава ПО) — инструменты, которые составляют полный список зависимостей проекта и сверяют его с базами известных уязвимостей. Многие из них заодно проверяют лицензии библиотек.

Главная сложность — транзитивные зависимости. Добавив в проект один пакет, например requests в Python или express в Node.js, вы получаете и все пакеты, от которых зависит он сам. SCA-сканер читает манифесты и lock-файлы (package-lock.json, poetry.lock, go.sum, pom.xml) и строит всё дерево, а не только то, что вы указали явно.

Насколько это серьёзно, показала уязвимость Log4Shell в Java-библиотеке Log4j в декабре 2021 года. Достаточно было передать специально составленную строку туда, где она попадёт в журнал, чтобы выполнить код на сервере. Многие компании неделями выясняли, в каких проектах вообще используется эта библиотека. Если бы список зависимостей каждого проекта был под рукой, ответ занял бы минуты.

Инструменты

Trivy — хороший первый выбор: один инструмент для кода, образов и SBOM. Grype и OSV-Scanner полезны как второе мнение, потому что базы уязвимостей у разных сканеров немного различаются.

Сканирование проекта

Trivy ставится из пакетного менеджера или бинарным файлом со страницы релизов. Проверка каталога проекта:

trivy fs --scanners vuln .

В отчёте для каждой находки указаны библиотека, идентификатор уязвимости (например, CVE), уровень опасности, установленная версия и версия, в которой уязвимость исправлена.

Проверка лицензий:

trivy fs --scanners license .

Те же проверки другими сканерами:

grype dir:.
osv-scanner scan source -r .

SBOM: список компонентов

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

trivy fs --format cyclonedx --output sbom.json .
trivy sbom sbom.json

Первая команда создаёт SBOM в формате CycloneDX, вторая проверяет его на уязвимости. Поддерживается и формат SPDX.

SCA в CI

Проверка должна запускаться автоматически. Пример задания GitHub Actions, которое останавливает сборку при критичных уязвимостях:

name: sca
on: [pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Trivy
        run: curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
      - name: Scan dependencies
        run: trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 .

--exit-code 1 делает находки ошибкой сборки, --severity ограничивает проверку серьёзными уровнями, чтобы CI не останавливался из-за каждой мелочи.

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

При первом запуске на реальном проекте находок может оказаться сотни. Это нормально.

1. Начните с HIGH и CRITICAL, особенно в библиотеках, которые обрабатывают входные данные: веб-фреймворк, разбор файлов, сериализация.
2. Проверьте, используется ли уязвимый код. Уязвимость в функции, которую приложение не вызывает, менее срочна. Но не откладывайте такие обновления навсегда.
3. Обновляйте небольшими шагами. Мажорное обновление может сломать приложение, поэтому после каждого обновления нужны тесты.
4. Если исправления нет, зафиксируйте осознанное исключение с датой пересмотра: у Trivy для этого есть файл .trivyignore.

Автоматические обновления берёт на себя Dependabot или Renovate: бот сам открывает запрос на слияние с новой версией, а вам остаётся дождаться тестов и принять его. Renovate гибче в настройке и работает не только с GitHub, но и с GitLab, в том числе на своём сервере.

Lock-файлы

Lock-файл фиксирует точные версии всех зависимостей, включая транзитивные. Без него две сборки одного и того же кода могут получить разные версии библиотек, и в продакшен попадёт версия, которую никто не проверял.

• Храните lock-файл в репозитории.
• В CI устанавливайте зависимости строго по нему: npm ci, poetry install, pip install --require-hashes -r requirements.txt.
• Обновляйте lock-файл осознанно, отдельным изменением, которое проходит те же проверки.

Лицензии зависимостей

SCA-сканеры предупреждают и о лицензиях. Копилефтные лицензии (GPL, AGPL) могут обязывать раскрыть исходный код, но обязательства зависят от того, как вы распространяете продукт. Программа, которую вы передаёте клиентам, и сервис, который работает только на ваших серверах, — разные случаи, а AGPL распространяется и на сетевое использование. Список разрешённых лицензий лучше согласовать с юристом один раз и проверять его автоматически.

Главное

• Каждая новая зависимость — это ещё один поставщик кода. Не добавляйте библиотеку ради функции на пять строк.
• Сканируйте регулярно, а не только при сборке: новые уязвимости находят в старых версиях каждый день.
• Держите lock-файлы и SBOM — тогда на вопрос «где у нас эта библиотека» найдётся ответ за минуты.