Как блокировать PR с уязвимыми зависимостями через GitHub Dependency Review

Как сделать Dependency Review реальным merge gate

Сам по себе workflow Dependency Review только сообщает результат; чтобы реально блокировать merge, job должен завершаться с ошибкой на выбранном уровне риска и быть required check. Начните с `pull_request` workflow и `actions/dependency-review-action`, затем задайте `fail-on-severity` согласно политике команды. После нескольких стабильных запусков добавьте check в branch protection или ruleset. Такой порядок снижает риск ситуации, когда merge внезапно блокируется не из-за уязвимости, а потому что workflow не стартовал или был неправильно настроен.

Совет: Сначала добейтесь стабильного зелёного Dependency Review job, затем делайте его required для merge.

Что сделать по шагам

1. Создайте workflow на pull_request.
2. Добавьте checkout и actions/dependency-review-action.
3. Установите fail-on-severity по политике команды.
4. Проверьте check на тестовом PR.
5. Добавьте его в required status checks/ruleset, если merge должен блокироваться.

Предупреждение: Не копируйте deny-licenses без своей лицензионной политики.

Что важно учесть в текущей реализации

Dependency Review анализирует изменения зависимостей именно в pull request. Официальный action запускается на `pull_request`; параметр `fail-on-severity` принимает уровни critical, high, moderate или low и определяет, при какой уязвимости job завершится ошибкой. Сам красный job ещё не гарантирует блокировку merge: check нужно сделать required через branch protection или ruleset. Для начала выберите порог, соответствующий вашему risk appetite, и протестируйте PR с заведомо безопасным изменением manifest. Лицензионные опции `allow-licenses` и `deny-licenses` нельзя бездумно копировать из примера — они должны соответствовать политике проекта. Любое временное исключение лучше документировать с владельцем и сроком пересмотра.

Важно: Определите, кто согласует временное исключение и как оно закрывается.

Проверка результата и крайние случаи

Минимальный workflow должен запускаться на pull_request и содержать Dependency Review Action. Порог `fail-on-severity` выбирайте осознанно: слишком низкий сразу может заблокировать большое число обновлений, слишком высокий пропустит риски, которые политика команды считает неприемлемыми. После тестового failed check добавьте именно этот job в required status checks или ruleset. Если используете лицензионные ограничения, задавайте их отдельно и только после согласования списка лицензий — чужой пример `deny-licenses` не является готовой политикой для вашего проекта.

Контрольный список

• Workflow запускается на pull_request.
• Задан осознанный fail-on-severity.
• Тестовая уязвимость даёт failed check.
• Dependency Review job добавлен в required checks/ruleset.

Финальная проверка

Покажите разработчику текст failed Dependency Review check и ожидаемый способ remediation — обновить зависимость, удалить её или согласовать временное исключение по принятой процедуре.

Ожидаемый результат

Тестовый PR с зависимостью выше выбранного порога должен получить failed Dependency Review check, и этот failure должен реально удерживать merge.

Последняя проверка перед завершением

Версию action в workflow лучше фиксировать на поддерживаемой major-ветке или принятом в команде pinning-подходе, чтобы security check не менялся неожиданно вместе с внешней зависимостью.

Что учитывать

Dependency Review анализирует изменения зависимостей именно в pull request. Официальный action запускается на `pull_request`; параметр `fail-on-severity` принимает уровни critical, high, moderate или low и определяет, при какой уязвимости job завершится ошибкой. Сам красный job ещё не гарантирует блокировку merge: check нужно сделать required через branch protection или ruleset. Для начала выберите порог, соответствующий вашему risk appetite, и протестируйте PR с заведомо безопасным изменением…

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• Configuring the dependency review action
• Customizing your dependency review action configuration