Как я перестал бояться сторонних зависимостей и полюбил Dependency-Check

Представьте ситуацию: вы спокойненько катите фичу в прод, тесты зеленые, код-ревью пройдено. А через неделю выясняется, что в одной из сотен библиотек, которые ваше приложение подтягивает транзитивно, нашли критическую уязвимость. Причем нашли ее не вы, а какой-нибудь пытливый хакер или, в лучшем случае, отдел безопасности. Ощущение не из приятных.

Я часто вижу, как команды забивают на аудит зависимостей. Обычно аргумент один: «у нас нет времени проверять каждый артефакт вручную». И это правда, вручную это делать невозможно. Но есть инструмент, который делает эту работу за вас уже больше десяти лет. Речь про Dependency-Check.

Что это за зверь

Dependency-Check — это утилита для анализа состава программного обеспечения (SCA, Software Composition Analysis). Проект курирует сообщество OWASP, что само по себе уже неплохая рекомендация.

Принцип работы простой: утилита сканирует зависимости вашего проекта и пытается сопоставить их с базой общеизвестных уязвимостей (CVE). Если она находит совпадение, вы получаете подробный отчет с описанием дыры в безопасности и ссылками на первоисточники.

Что полезного он умеет

Инструмент не привязан к конкретному языку, хотя в экосистеме Java он чувствует себя наиболее уверенно.

Поддержка множества стеков. Кроме Java (Maven, Gradle, Ant), он справляется с .NET Core, Go, Ruby, Elixir и даже с JavaScript (npm, pnpm, yarn). Для JS-проектов он использует встроенные команды аудита соответствующих пакетных менеджеров.
Интеграция в CI/CD. Его легко воткнуть в пайплайн Jenkins или запускать как шаг в GitHub Actions. Это позволяет «ронять» сборку, если в проект пытаются затащить библиотеку с критическим рейтингом CVSS.
Генерация отчетов. На выходе вы получаете HTML, XML, JSON или CSV. HTML-отчет выглядит наглядно, его не стыдно показать лиду или заказчику.
Гибкость настройки. Можно настроить файл подавления (suppression file). Это нужно, когда уязвимость найдена, но вы точно знаете, что в вашем контексте она не эксплуатируема или риск приемлем.

Тонкости настройки и пара граблей

Проект довольно тяжеловесный в плане ресурсов. Ему нужно скачивать базу данных NVD (National Vulnerability Database). С версии 9.0.0 разработчики перешли на использование NVD API, и здесь кроется главный нюанс: без ключа API (который нужно получить на сайте NVD) обновления будут мучительно медленными.

Кстати, если вы используете Docker в CI, рекомендую пробрасывать кэшированную директорию с базой данных, иначе каждый запуск пайплайна будет превращаться в десятиминутное ожидание загрузки данных.

Пример запуска через Docker для Linux:

docker run --rm \
    -e user=$USER \
    -u $(id -u ${USER}):$(id -g ${USER}) \
    --volume $(pwd):/src:z \
    --volume "$DATA_DIRECTORY":/usr/share/dependency-check/data:z \
    --volume $(pwd)/odc-reports:/report:z \
    owasp/dependency-check:latest \
    --scan /src \
    --format "ALL" \
    --out /report

Как это использовать в Java-проекте

Если вы используете Maven, достаточно добавить плагин. По умолчанию он привязывается к фазе verify, что логично.

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Для Gradle есть отдельный плагин, но там бывают конфликты версий (например, с Jackson). В README проекта есть целый раздел, посвященный тому, как фиксить NoSuchMethodError через constraints в Gradle.

Стоит ли его внедрять

Если у вас в компании нет платных решений вроде Snyk или Sonatype IQ, то Dependency-Check — это ваш выбор по умолчанию. Он бесплатный, проверенный временем и поддерживается экспертами по безопасности.

Кому он точно пригодится:

Финтех-проектам и всем, кто работает с персональными данными.
Командам, которые хотят автоматизировать «безопасную разработку» (DevSecOps) без бюджета на софт.
Одиночкам, которые выпускают Open Source продукты и хотят гарантировать их чистоту.

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