Пакет без единой CVE в отчете сканера может оказаться не самым безопасным, а самым неудобным для проверки элементом инфраструктуры. Именно на этот разрыв между «уязвимостей не найдено» и реальной безопасностью цепочки поставок обратил внимание The New Stack: для команд, которые полагаются на open source и автоматические проверки зависимостей, это неприятная, но практическая новость.
Как пишет The New Stack, сама логика «ноль CVE = ноль проблем» слишком упрощает картину. В материале с заголовком Why zero vulnerability code packages could still be your biggest software supply chain risk издание напоминает: сканеры уверенно работают там, где уже есть известные уязвимости, записи в базах и понятные сигнатуры. Но цепочка поставок ломается не только из-за уже зарегистрированных дыр. Проблема в том, что пакет может выглядеть чистым в формальном отчете и при этом оставаться рискованным по происхождению, сопровождению и контролю изменений.
Для русскоязычной IT-аудитории здесь важен очень прикладной вывод. Во многих командах проверка зависимостей до сих пор устроена как бюрократия с зеленой галочкой: CI/CD прогнал SBOM, сверил библиотеки с базой уязвимостей, не нашел критики, значит релиз можно выпускать. Такой процесс удобен для отчетности перед CISO, комплаенсом или заказчиком, но он плохо отвечает на куда более неприятный вопрос: кто именно отвечает за код пакета, как он обновляется и можно ли доверять каналу поставки. С точки зрения безопасности цепочки поставок отсутствие CVE говорит лишь о том, что на данный момент никто не зафиксировал известную проблему в публичной базе. Это не то же самое, что доказанная надежность компонента.
Логика угроз здесь довольно жесткая. Если команда смотрит только на CVE, она по определению смотрит в прошлое: на уже найденные, описанные и классифицированные инциденты. А риск supply chain часто возникает раньше, чем попадает в реестры и сканеры. В этой зоне живут компрометация процессов публикации, неочевидные изменения в зависимостях, слабая прозрачность происхождения пакета и банальная нехватка сопровождения. Даже если в карточке компонента пусто по CVE, это не означает, что пакет проходил строгий аудит, что у него зрелая модель выпуска обновлений или что его жизненный цикл вообще кто-то контролирует. Для разработки это плохая новость, потому что привычный метрик «количество уязвимостей» оказывается слишком грубым.
Контекст у этой истории понятен и без лишней драмы: за последние годы безопасность open source давно перестала быть темой только для security-команд. Она стала частью инженерного процесса, закупок, M&A-проверок и разговоров с enterprise-клиентами. Поэтому сама формулировка The New Stack бьет в больное место рынка: индустрия научилась измерять то, что легко измеряется, но до сих пор спорит о том, как оценивать зависимости без известных CVE. А именно такие пакеты часто создают ложное чувство порядка. У разработчиков чистый дашборд, у менеджера понятный KPI, у бизнеса ощущение контролируемого риска. Потом выясняется, что «чистота» была просто результатом нехватки наблюдаемости.
Почему это важно не только для security-команд
Для разработчиков история упирается в выбор критериев качества зависимостей. Если библиотека ставится в прод только потому, что по ней нет записей в базе уязвимостей, команда принимает решение на неполной информации. Нужны дополнительные сигналы: активность сопровождения, воспроизводимость сборки, прозрачность релизного процесса, политика подписывания артефактов, предсказуемость обновлений. Для продуктовых и ИТ-руководителей вывод еще жестче: закупка инструментов для поиска CVE не закрывает вопрос supply chain-риска, а лишь покрывает один его слой. И если внутренний процесс безопасности по-прежнему сводится к фразе «сканер ничего не нашел», то это не зрелость, а иллюзия зрелости.
Отдельная неприятность в том, что «нулевой CVE-профиль» легко продается внутри компании как хороший показатель. Его удобно показывать на совещаниях, включать в квартальные отчеты и использовать как критерий допуска в production. Но для бизнеса это ловушка. Чем сильнее организация опирается на открытые пакеты и внешние компоненты, тем выше цена ошибки в оценке доверия. The New Stack фактически напоминает рынку простую вещь: безопасность цепочки поставок нельзя свести к подсчету карточек в базе уязвимостей. Иначе самые рискованные зависимости будут не теми, где уже нашли проблему, а теми, которые никто толком не умеет оценивать.
На этом фоне меняется и роль DevSecOps. Его задача уже не ограничивается тем, чтобы встроить сканер в пайплайн и блокировать сборку на критических CVE. Нужен более широкий фильтр доверия к артефактам: от происхождения пакета до дисциплины сопровождения. Для российского рынка, где многие компании одновременно импортозамещают стек, пересобирают внутренние репозитории и наращивают долю собственных форков, тема особенно нервная. Чем больше зависимостей компания берет под собственный контроль, тем меньше помогает формальная «чистота» по известным уязвимостям и тем важнее становится операционная проверка всего пути поставки кода.
Главный вопрос теперь звучит не «сколько CVE у пакета», а «почему мы вообще ему доверяем». И если индустрия действительно сдвинется от подсчета опубликованных уязвимостей к проверке происхождения и управляемости компонентов, это будет означать зрелый поворот: от удобной отчетности к реальной инженерной гигиене. Именно там, похоже, и пройдет следующая линия обороны за безопасность цепочки поставок.