Уязвимость, которую вы не подключали — и почему она опасна для сайта

Наткнулся на разбор о том, как сканер нашёл уязвимость в библиотеке, которую вы не подключали. И понял: это не редкость — это про каждый сайт, где есть зависимость.

О чём речь и почему я считаю это важным для сайта

Речь не о том, что вы сами что-то установили. А о том, что ваш сайт работает с кодом, которого вы даже не знаете. Уязвимость может быть в библиотеке, которая пришла вместе с тем, что вы выбрали. И даже если вы её не вызывали — она всё равно работает. И может быть эксплуатирована.

Я считаю это важным, потому что уязвимость не в том, что вы выбрали. А в том, что вы не видите, что работает. И если кто-то взломал — это не из-за вашего кода. Это из-за библиотеки, которую вы не проверяли. И это — риск для бизнеса.

Как это устроено — что тут вообще происходит

Вы подключаете одну библиотеку — например, для работы с API. А она, в свою очередь, тянет ещё десяток. И каждый из них — это код, который выполняется на вашем сервере. Даже если вы не писали его, даже если не знаете его имени.

Сканер не смотрит только на то, что вы явно указали. Он видит всё дерево зависимостей. И если в одном из узлов есть уязвимость — она есть в вашем приложении. Даже если вы не выбрали этот пакет. Даже если он не в вашем файле.

Как понять, что это касается вашего сайта

Простой способ: посчитайте, сколько пакетов вы явно указали, и сколько реально установлено. Если разница в десятки — это нормально. Но если у вас 500 пакетов, а в файле зависимостей — 5 — это тревога.

У меня в процессе проверки есть автоматическая проверка: прогоняю отчёт о составе сборки через инструмент, который сравнивает версии с базой уязвимостей. И если находок больше, чем в вашем манифесте — значит, проблема где-то в транзитивных зависимостях. И это не просто «найдено» — это реальный риск.

Что я делаю, когда нахожу такую уязвимость

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

Потом смотрю, какие пакеты входят в дерево, и проверяю, какие из них уязвимы. Не все находки критичны — но если уязвимость доступна извне, даже если вы её не вызывали — это уже повод действовать. И я не игнорирую отчёты. Кто-то должен смотреть на них — и действовать.

Что даёт поддержка — не просто починка, а защита

Мы не просто удаляем уязвимость. Мы закрываем причину. Фиксируем версии, проверяем воспроизводимость сборки, включаем контроль хешей. Потому что если завтра появится новая уязвимость — мы сразу узнаем, есть ли она у вас.

И это работает 24/7. Наш мониторинг проверяет состав сборки каждые несколько минут. И если что-то изменилось — мы сразу видим. Это не разовая проверка. Это постоянная защита от того, что вы даже не знаете, что работает в вашем коде.