Сканирование образов и зависимостей

Два сканера, одна проблема инвентаризации

Образ контейнера — это стопка из двух цепочек поставок ПО, и сканировать нужно обе. Слой ОС — это всё, что приносит базовый образ: glibc, openssl, zlib, сотни пакетов Debian или Alpine, большинство из которых ты никогда не вызываешь. Слой приложения — твои прямые и транзитивные зависимости: package-lock.json, go.sum или requirements.txt, тянущие код, который ты действительно зовёшь. Обе цепочки сканируются одинаково, и стоит точно понять как — потому что механизм объясняет шум.

Сканер не анализирует твой код на ошибки. Он строит ведомость материалов — каждый пакет и точную версию — а затем сопоставляет этот список с базой уязвимостей (NVD плюс дистрибутивные ленты вроде Debian Security Tracker, GitHub Advisories и языковые экосистемы). Вывод — это арифметика множеств: installed_packages ∩ known_vulnerable_versions. Именно из-за этого пересечения свежий образ node:20 сообщает о десятках CVE в первый же день — ты установил ОС с известно-уязвимыми пакетами, и сканер сообщает факт, а не суждение. В руководстве OWASP DevSecOps это называется Software Composition Analysis (SCA), и это самый дешёвый высокоценный контроль, который можно добавить в пайплайн. И это же причина, по которой его включение ощущается как погребение под завалом.

Почему стена красного — в основном шум

Та же арифметика множеств, что делает сканирование дешёвым, делает его шумным. CVE из installed_packages ∩ known_vulnerable_versions говорит, что уязвимый код присутствует. Он не говорит, что код загружен, вызван или достижим с подконтрольным атакующему вводом. Этот разрыв — источник почти всего шума, и у него три различимые формы, которые сеньор учится распознавать.

Три формы шума:

• Недостижимый код. CVE в NIS-резолвере glibc, в пути разбора шрифтов библиотеки изображений, которую ты используешь только для миниатюр, или в подкоманде CLI, которую сервис никогда не вызывает. Уязвимые байты лежат на диске; уязвимый путь мёртв. Анализ достижимости — достигает ли хоть одна цепочка вызовов от твоей точки входа уязвимой функции? — это крупнейший единичный редуктор шума, и новейшие сканеры (и стандарт VEX, Vulnerability Exploitability eXchange) существуют именно чтобы записывать «присутствует, но не затронут».
• Фикса ещё нет (или won't-fix). Дистрибутивы рутинно помечают низкосерьёзные CVE как won't-fix, потому что фикс не стоит риска регрессии. Ронять сборку на CVE без апстрим-патча означает, что сборка никогда не позеленеет — ты построил храповик, который только затягивается.
• Серьёзность ≠ эксплуатируемость в контексте. CVSS 9.8 в dev-зависимости, вырезанной tree-shaking из продакшен-бандла, — это не 9.8 для тебя. CVSS оценивает уязвимость в абстракции; только ты знаешь, экспонирована ли она.

Где ставить гейт и на что он гейтит

Понимание форм шума позволяет поставить гейт правильно. Неверный дизайн — тот, к которому тянутся первым, — это «ронять сборку, если есть хоть одна CRITICAL». Он даёт три сбоя на первой же неделе: сборки, которые не могут позеленеть (CVE без фикса), усталость от алертов (так что единственный реальный RCE проскальзывает мимо вместе с 40 недостижимыми) и неизбежный --exit-code 0, тихо отключающий весь контроль. Тихо обезвреженный сканер хуже, чем его отсутствие, потому что позволяет верить, что ты защищён.

Гейт сеньора собирает три предиката: серьёзность И наличие фикса И не-подавлено. Ронять сборку только на исправимой, high-или-critical, неподавленной находке — потому что это то множество, где падение сборки реально меняет чьё-то поведение (бампни версию). Всё остальное идёт в другой поток: отслеживать, подавить с записанной причиной или принять. Цель — гейт, где красная сборка всегда означает «сделай вот это конкретное», а не «иди подтверди 40 вещей, с которыми ничего не сделать».

Резать вход, а не только фильтровать выход

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

• Минимальные базовые образы. Образ node:20 весит ~1,1 ГБ и тащит весь userland Debian — shell, apt, десятки библиотек, которых твоё приложение не касается, каждая — потенциальный CVE. Образ distroless или alpine несёт только рантайм. Замена node:20 на gcr.io/distroless/nodejs20 рутинно роняет находки слоя ОС со ~150 до единиц — потому что ты удалил пакеты, а не подавил их CVE. Меньше пакетов — единственный фикс, удаляющий сам уязвимый код, а не спорящий о его достижимости.
• Пинить и обновлять осознанно. Lock-файлы делают сканы воспроизводимыми (ты сканируешь ровно то, что отгружается), а ровный темп обновления зависимостей (Dependabot/Renovate) означает, что ты применяешь маленькие патчи непрерывно, а не упираешься в обрыв на 200 CVE при следующем вынужденном мажорном апгрейде.