Отчёт о зависимостях без паники: что чинить сегодня, а что подождёт

Сканер находит сотни предупреждений в любом живом проекте. Рассказываем, как мы сортируем их по риску и почему уровень опасности - не единственный критерий.

Первый запуск проверки зависимостей на большом проекте обычно выглядит как катастрофа: несколько сотен предупреждений, из них десятки высоких. Команда открывает список, пугается и закрывает. Через месяц список становится длиннее.

Достижимость важнее уровня

Уязвимость в функции, которую ваш код никогда не вызывает, опасна меньше, чем средняя уязвимость в разборщике входящих запросов. Поэтому отчёт сначала проверяет, достижим ли уязвимый код из ваших точек входа, и только потом сортирует по уровню.

Три корзины

• Сегодня - достижимый код, есть исправленная версия, обновление не ломает совместимость. Платформа готовит запрос на слияние сама.
• На этой неделе - достижимый код, но обновление мажорное. Нужен человек и прогон тестов.
• В плане - недостижимый код или уязвимость только в инструментах сборки.

$ cedar deps report --reachable --min-level medium
найдено 214, достижимо 17, с готовым исправлением 12

Цель не в пустом отчёте, а в том, чтобы ни одна достижимая уязвимость не жила дольше недели.

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