Аудит зависимостей веб-приложения: рабочие приёмы

Веб-приложение может получить уязвимую библиотеку не напрямую, а через цепочку из нескольких пакетов. Команда npm audit покажет известные проблемы в дереве зависимостей, но сама по себе не скажет, используется ли опасный код в вашем приложении и не сломает ли обновление сборку. Ниже — практический процесс для проектов на npm 10.x: от проверки lock-файла до решения, что делать с каждым предупреждением.

Сначала проверьте, что именно вы сканируете

Аудит зависит от манифеста и lock-файла. Для воспроизводимого результата запускайте его в чистой рабочей копии проекта, где лежит актуальный package-lock.json. Если команда выполняется без lock-файла или после изменений, которые ещё не зафиксированы, отчёт может не совпасть с тем, что установит CI или production-сборка.

Зафиксируйте версии Node.js и npm, а также состояние репозитория. В примерах используется npm 10.x; проверьте фактическую версию командой npm --version. Для восстановления зависимостей в CI обычно подходит npm ci: команда устанавливает версии из lock-файла и завершится ошибкой, если он расходится с package.json.

node --version
npm --version
git status --short
npm ci
npm audit

Проверка готова, если установка завершилась без ошибки, а аудит выдал отчёт по текущему дереву. Сохраните вывод в задаче или артефакте CI: так будет видно, какие предупреждения были исходными, а какие появились после обновления.

Четыре приёма, которые превращают отчёт в план

1. Разделите production- и dev-зависимости

Уязвимость в инструменте тестирования и уязвимость в библиотеке, попавшей в серверный runtime, — не один и тот же риск. Но dev-зависимости нельзя автоматически считать безопасными: они исполняются в CI, а сборщик может включить пакет в клиентский бандл. Сначала получите полный отчёт, затем сравните его с проверкой production-зависимостей:

npm audit
npm audit --omit=dev

Если проблема исчезла с --omit=dev, это сужает область проверки, но не доказывает, что пакет безвреден. Уточните, где он запускается и может ли попасть в публикуемую сборку.

2. Найдите не только пакет, но и путь к нему

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

npm ls --all
npm explain имя-пакета

Замените имя-пакета точным названием из отчёта. Если пакет приходит через несколько родителей, выясните, какой из них можно обновить без массового изменения дерева. Это особенно важно для общих утилит, от которых зависят сразу несколько частей приложения.

3. Используйте автоматическое исправление как предложение, не как вердикт

npm audit fix пытается применить совместимые обновления и изменить lock-файл. После команды изучите diff: какие версии поменялись, не добавились ли крупные обновления и не исчезли ли ожидаемые зависимости. Затем запустите тесты, сборку и повторный аудит.

Не начинайте с npm audit fix --force. Флаг может разрешить обновления, выходящие за заявленные диапазоны совместимости, и привести к изменениям, которые требуют правок кода. Запускайте его только в отдельной ветке, когда понимаете, какие пакеты будут обновлены и как проверите обратную совместимость.

4. Проверяйте исправление в том же контуре, где собирается приложение

Локальный результат не заменяет CI. После изменения lock-файла прогоните установку через npm ci, тесты и production-сборку. Если приложение публикует клиентские файлы, проверьте состав бандла принятыми в проекте средствами: зависимость может быть dev-пакетом, но всё равно участвовать в сборке.

Как решить, что исправлять первым

Не сортируйте задачи только по количеству строк в отчёте. Для каждого предупреждения зафиксируйте четыре вещи: какая версия уязвима, как пакет попал в проект, где он исполняется и какой вариант исправления предложен. Затем оцените последствия для конкретного приложения.

• Пакет исполняется в production и обрабатывает недоверенный ввод — сначала выясните, есть ли доступный патч и затрагивает ли уязвимый сценарий ваш код.
• Пакет используется только в тестах — проверьте риски CI и возможность влияния на публикацию сборки; не закрывайте предупреждение одной пометкой «не production».
• Исправление требует major-обновления — создайте отдельную задачу на совместимость, а не проталкивайте изменение вместе с обычным патчем.
• Патча пока нет — запишите причину, владельца и срок повторной проверки. Если есть обходной путь, подтвердите его тестами и ограничьте область применения.

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

Где процесс ломается

Lock-файл не обновили вместе с манифестом

Разработчик меняет package.json, но не фиксирует согласованное изменение package-lock.json. В результате локальная установка и CI могут получить разные наборы пакетов или CI остановится на npm ci. Исправление — обновить оба файла в одной ветке, проверить diff и повторить установку с чистого состояния.

Предупреждение закрыли, не проверив сборку

Успешный npm audit fix означает, что npm изменил зависимости, а не то, что приложение осталось совместимым. Ошибка может проявиться позже — при тестировании, сборке или запуске. Минимальный контроль: CI устанавливает зависимости, выполняет тесты и собирает проект из обновлённого lock-файла.

Зависимость объявили неиспользуемой по одному поиску

Пакет может подключаться динамически, использоваться скриптом сборки или приходить транзитивно. Перед удалением проверьте импорты, скрипты в package.json, конфигурацию сборщика и вывод npm explain. Если роль пакета неясна, удаление — отдельное изменение, которое нужно проверить тестами.

Термин: транзитивная зависимость

Транзитивная зависимость — пакет, который попал в проект не напрямую, а потому что он нужен другому пакету. Например, вы добавили библиотеку интерфейса, а она сама использует набор утилит. Обновлять такую зависимость часто приходится через её родителя, а не прямой заменой пакета в манифесте.

Что делать дальше

Добавьте в CI проверку зависимостей и определите, кто разбирает новые предупреждения. Не ограничивайтесь числом найденных проблем: сохраняйте отчёт, фиксируйте решение по каждой уязвимости и проверяйте обновления на тестах и production-сборке. Для следующего шага полезнее всего посмотреть официальную документацию npm по аудиту и команде npm explain, сверив её с установленной версией npm.