Як зрозуміти, чи security advisory стосується вашого проєкту

Буває, що advisory не ваш

Уявіть, що вам прилітає advisory на середню за популярністю бібліотеку, але вона живе тільки в dev-залежностях і не потрапляє в production build. Панікувати не треба. Спочатку перевірте факти: де саме лежить пакет, яка версія реально запущена, і чи є шлях до вразливого коду.

Якщо уразлива версія є тільки в дереві залежностей, але код не виконується, ризик може бути значно нижчий за заголовок advisory. Саме тут і потрібен спокійний triage, а не “оновити все негайно”.

Коли advisory, ймовірно, стосується проєкту

Є три сигнали, на які варто дивитися першими:

1. Уразлива версія реально встановлена.
2. Проблемний кодовий шлях reachable.
3. Компонент exposed так, що помилка може бути використана у вашому сценарії.

Якщо всі три сигнали збігаються, advisory треба обробляти як реальний ризик. Тоді вже вирішуйте, чи достатньо швидкого оновлення, чи потрібне тимчасове пом’якшення ризику.

Коли це може бути хибна тривога

Не кожен advisory означає інцидент. Часто достатньо перевірити кілька речей:

• пакет є лише в dev-залежностях;
• фіча, про яку йдеться в advisory, вимкнена;
• версія у вас не збігається з affected range;
• шлях до проблемного коду недосяжний у вашому сценарії.

У такому випадку головне не сперечатися із severity, а зафіксувати, чому саме ваш проєкт не зачеплений.

Типові помилки

• Дивитися тільки на severity і не перевіряти reachable path.
• Плутати presence у lockfile з реальним production risk.
• Ігнорувати feature flags, configuration або deployment boundary.
• Оновлювати все підряд без доказу, що компонент справді використовується.

Що робити далі

Коли advisory справді стосується проєкту, у вас є три нормальні варіанти: оновити версію, тимчасово зменшити exposure або поставити контроль і повернутися після перевірки. Якщо advisory не доходить до вашого code path, зафіксуйте причину і закрийте alert без зайвої паніки.

Далі почитати

• CVE Program
• GitHub Security Advisories
• npm security advisories