Навіщо перевіряти залежності на вразливості

Аудит залежностей — це перевірка всіх підключених бібліотек на відомі вразливості з публічних баз, таких як 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