Зачем проверять зависимости на уязвимости

Аудит зависимостей — это проверка всех подключённых библиотек на известные уязвимости из публичных баз, таких как GitHub Advisory Database и National Vulnerability Database. Сайт на WordPress тянет за собой десятки npm-пакетов для сборки темы и composer-пакетов для плагинов; уязвимость в одном из них открывает путь к взлому всего сайта, даже если основной код написан аккуратно.

В 2026 году атаки на цепочку поставок (supply chain) — обычная практика: злоумышленники публикуют вредоносный код в пакете с похожим именем на популярную библиотеку (typosquatting) или взламывают аккаунт мейнтейнера и выпускают заражённое обновление. Регулярный аудит зависимостей — обязательная часть чек-листа безопасности сервера.

npm audit: проверка Node.js-пакетов

Команда встроена в npm начиная с версии 6 и не требует установки:

cd /var/www/myapp
npm audit

Отчёт группирует уязвимости по уровню серьёзности: low, moderate, high, critical. Для каждой указан пакет, версия с исправлением и путь зависимости — от какого пакета верхнего уровня тянется уязвимая версия. Автоматическое исправление без изменения major-версий:

npm audit fix

Флаг --force у npm audit fix может поднять major-версию зависимости и сломать API — не запускайте его на проде без предварительного теста на копии сайта.

composer audit: проверка PHP-пакетов

Начиная с Composer 2.4 команда доступна из коробки:

cd /var/www/myapp
composer audit

Composer сверяет содержимое composer.lock с базой FriendsOfPHP Security Advisories и выводит список CVE с описанием и рекомендуемой версией. В отличие от npm, composer не предлагает автоматическое исправление — версию нужно поднять вручную:

composer require vendor/package:^2.5 --update-with-dependencies

После обновления обязательно прогоните тесты: PHP-пакеты часто меняют сигнатуры методов даже в минорных релизах.

Автоматизация аудита в CI

Ручной запуск легко забыть, поэтому аудит выносят в пайплайн: GitHub Actions, GitLab CI или простой cron на сервере сборки. Пример шага в CI:

- name: Security audit
  run: |
    npm audit --audit-level=high
    composer audit

Параметр --audit-level=high останавливает сборку только при уязвимостях high и critical — так low-severity находки не блокируют каждый релиз, но критичные проблемы не проходят незамеченными.

Что делать, если исправления нет

Иногда патч ещё не вышел или пакет заброшен мейнтейнером. Варианты действий:

Найти форк с исправлением и временно переключиться на него через overrides в package.json или replace в composer.json.
Ограничить поверхность атаки: если уязвим редко используемый код-путь, отключить соответствующую функцию через конфигурацию.
Поставить компенсирующий контроль на уровне сервера — правило ModSecurity WAF, блокирующее характерные для эксплойта запросы.
Задокументировать риск и назначить срок пересмотра — молча игнорировать уязвимость нельзя.

Чек-лист регулярного аудита

npm audit и composer audit запускаются при каждом деплое, а не раз в квартал.
Критичные и высокие уязвимости блокируют сборку в CI.
package-lock.json и composer.lock закоммичены — версии зависимостей зафиксированы.
Обновления тестируются на копии сайта перед выкладкой на прод.
Список неисправленных уязвимостей с компенсирующими мерами пересматривается ежемесячно.

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

Аудит зависимостей: npm audit и composer audit