npm audit

Коротко: Вбудована команда npm, що звіряє встановлені залежності проєкту з базою даних відомих вразливостей безпеки.

Докладніше: Результат відсортовано за серйозністю (критична/висока/середня/низька). npm audit fix автоматично виправляє все, що можливо без несумісних змін; npm audit fix --force виправляє й решту, але при цьому може примусово перевести пакети на несумісні версії. «No fix available» означає, що самі супровідники пакета ще не випустили виправлену версію.

Наш контекст: Виявлено під час перестворення package-lock.json — 22 вразливості, 15 виправлено автоматично без несумісних змін; решта 15 залежать від інструментів збирання Capacitor (важливі лише для мобільного застосунку, виправлення немає) і навмисно не форсувалися.

Подробиці

Що саме перевіряється

npm audit перевіряє не лише залежності, перелічені безпосередньо в package.json, а й повне дерево залежностей, зокрема всі транзитивні залежності (пакети, які, своєю чергою, імпортуються вашими пакетами) — тож вразливість може бути глибоко захована в пакеті, про який ви навіть не чули, але який встановлено опосередковано. Сама команда нічого не встановлює; вона лише порівнює версії, зафіксовані в package-lock.json, з публічною базою відомих вразливостей (база рекомендацій реєстру npm, яка, своєю чергою, ґрунтується на публічно повідомлених CVE — Common Vulnerabilities and Exposures).

Рівні серйозності та що вони означають

Чотири рівні серйозності (критична/висока/середня/низька) зазвичай відображають систему оцінювання CVSS (Common Vulnerability Scoring System), яку використовують для стандартизованої оцінки вразливостей безпеки в усій галузі. Критичні та високі вразливості зазвичай стосуються таких речей, як віддалене виконання коду чи обхід автентифікації, тоді як низькі оцінки часто стосуються теоретичних проблем або тих, що можна експлуатувати лише за дуже особливих умов. Важливо: оцінка стосується пакета, розглянутого ізольовано — чи можна вразливість реально експлуатувати у ВАШОМУ проєкті, залежить від того, чи досягається взагалі вразливий шлях коду з неперевіреними/зовнішніми даними.

Межі npm audit fix --force

Важливо з npm audit fix --force: команда справді намагається виправити вразливість, але для цього може перейти на нову мажорну версію пакета — а мажорні версії, згідно із семантичним версіонуванням, явно НЕ гарантують зворотної сумісності. Після примусового виправлення повна перевірка тестами/збиранням тому обов’язкова, а не необов’язкова, перш ніж довіряти результату. На практиці --force може навіть призвести до переходу пакета на версію, що ламає інші залежності в тому самому проєкті (конфлікти peer dependency) — команда оптимізує насамперед «вразливість зникла», а не «проєкт продовжує працювати».

Коли виправлення немає

Вразливість без доступного виправлення («no fix available») зазвичай означає одне з двох: або супровідники зачепленого пакета ще не закрили діру, або пакет більше не підтримується — у другому випадку часто єдиний варіант — замінити пакет активно підтримуваною альтернативою. Перш ніж ігнорувати невиправлену вразливість, варто коротко перевірити, чи досяжний вразливий шлях коду у вашому проєкті взагалі — багато повідомлених вразливостей стосуються дуже конкретних викликів функцій пакета, які проєкт може взагалі не використовувати, що може робити реальний ризик низьким попри формально існуючу вразливість.

Безперервний моніторинг замість разової перевірки

Оскільки нові вразливості постійно виявляються й про них повідомляється, разовий запуск npm audit — лише знімок: проєкт, чистий на момент встановлення, може через тижні показувати нові повідомлення, хоча у вашому власному коді нічого не змінилося. Багато команд тому інтегрують npm audit (або еквівалентні інструменти на кшталт GitHub Dependabot) у свої конвеєри CI, щоб автоматично й регулярно перевіряти нові вразливості, а не покладатися на випадкові ручні запуски.

Див. також: GitHub