Хьюстон, у нас спам. GitHub завалил программистов бесполезными правками и почему это опасно

Поддерживать зависимости в актуальном состоянии давно считается базовой практикой безопасности. Но один из сопровождающих ключевых криптографических библиотек Go заявил, что GitHub Dependabot нередко приносит больше шума, чем пользы, и в ряде случаев инструмент лучше вовсе отключить.

С резкой критикой выступил Филиппо Вальсорда, бывший руководитель команды безопасности Go в Google и нынешний сопровождающий криптографических пакетов стандартной библиотеки Go. Поводом стало недавнее исправление уязвимости в библиотеке filippo.io/edwards25519, которую применяют для криптографии EdDSA. После публикации патча Dependabot начал массово создавать pull request в тысячах репозиториев, хотя реальной угрозы для многих проектов не было.

По словам Вальсорды, автоматическая система сработала слишком грубо: GitHub увидел наличие зависимости и начал рассылать предупреждения без проверки, затрагивает ли проблема конкретный пакет и используется ли уязвимая функция в коде. Вместе с потоком pull request сервис присвоил уязвимости, как выразился разработчик, бессмысленную оценку CVSS v4 и показал совместимость на уровне 73%, намекнув на 27-процентный риск поломки. Вальсорда назвал такую оценку абсурдной, поскольку исправление затронуло всего одну строку в редко используемом методе MultiScalarMult.

Ситуация оказалась особенно показательной из-за того, как библиотека обычно попадает в проекты. Часто зависимость появляется через драйвер MySQL для Go, однако такой сценарий не использует исправленную функцию и потому не подвержен проблеме. Несмотря на отсутствие реальной опасности, Dependabot все равно начал рассылать обновления и предупреждения. По мнению Вальсорды, подобное поведение превращает сервис в «машину шума» и провоцирует усталость от предупреждений, а усталость от предупреждений уже напрямую снижает уровень защиты.

Вальсорда считает, что Dependabot плохо справляется не только с точностью, но и с самой задачей оценки риска. Проверка наличия зависимости без анализа конкретного пакета и достижимости уязвимого кода выглядит слишком примитивно для серьезной работы с безопасностью. Для экосистемы Go разработчик советует использовать более точные инструменты, например govulncheck, который умеет показывать, достижима ли уязвимость из реального кода приложения.

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

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

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

При всей жесткости критики у Dependabot все же остается важное преимущество: сервис хотя бы заставляет команды замечать проблему зависимостей. В экосистеме Go уже есть более точные инструменты и понятные процессы, поэтому замену найти проще. В других проектах, где ресурсов мало, а зрелого набора альтернатив нет, Dependabot может оказаться полезнее полного бездействия.