Цепочка поставки: сканеры, подписи, SBOM

Что именно приезжает в прод

Три источника, и все три надо считать. Первый - базовый образ, тот, с которого начинается сборка: у меня debian принёс 88 пакетов и 5242 файла, из них 8 программ, работающих с правами root. Тот же alpine - 14 пакетов и 89 файлов, программ с правами root ноль. Разница в поверхности атаки на два порядка, и выбирается она одной строкой в файле сборки.

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

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

транзитивная зависимость

библиотека, которую притащила другая библиотека; её никто не выбирал

поверхность атаки

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

Закрепление версий и обновление

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

Но закрепление создаёт вторую проблему: закреплённое устаревает и копит известные уязвимости. Значит, нужен и обратный процесс - регулярное обновление закреплений, желательно автоматическое, с прогоном тестов. Схема, которая работает: робот раз в неделю поднимает версии и открывает изменение, тесты проходят, человек смотрит и вливает.

// Ошибка на этом месте типовая: закрепили и забыли. Через год оказывается, что обновление невозможно, потому что версии разъехались на несколько крупных выпусков, в которых менялась совместимость, и всё ломается разом. Обновляться понемногу и часто дешевле, чем один раз и целиком.

закрепление версий

точные версии всех зависимостей, включая транзитивные

обновление закреплений

регулярный автоматический подъём версий с прогоном тестов

Сканирование, состав и подпись

Сканер сверяет список того, что стоит в образе, с базой известных уязвимостей. Ставят его в двух местах: в сборку, чтобы не выпускать новое с известными дырами, и по расписанию на то, что уже работает, - потому что уязвимость находят ПОСЛЕ выпуска, и вчера чистый образ сегодня уже нет.

Состав артефакта - это машиночитаемый список всего, что вошло в сборку, с версиями. Нужен он ровно для одного вопроса, который однажды прилетает: «в какой из наших сборок есть эта библиотека нужной версии». Без списка ответ ищется руками неделю, со списком - запросом за минуту.

// Подпись артефакта закрывает третью дыру: она подтверждает, что образ собран вашим сборочным конвейером, а не подсунут по дороге. Проверку подписи ставят на стороне, которая запускает: не подписан нашим ключом - не запускаем. Это же отсекает и «случайно выкатили образ, собранный на ноутбуке».

сканирование

сверка состава образа с базой известных уязвимостей

состав артефакта

машиночитаемый список всего, что вошло в сборку, с версиями

подпись артефакта

подтверждение, что образ собран вашим конвейером

Как отвечать: «Как контролировать то, что приезжает в прод вместе с кодом?»

Считать всё, что приезжает, а приезжает много. Я специально мерил: чистый образ python содержит один пакет, а после установки одного обычного фреймворка их восемь - семь транзитивных зависимостей никто не выбирал. Базовый образ debian сверх этого приносит 88 системных пакетов и больше пяти тысяч файлов, включая восемь программ, работающих с правами root; у alpine это 14 пакетов, 89 файлов и ноль таких программ. То есть выбор базы меняет поверхность атаки на два порядка одной строкой. Дальше по порядку: закрепляю версии приложения файлом со всеми транзитивными зависимостями, а базовый образ - отпечатком содержимого вместо тега, потому что тег можно перевесить. Ставлю автоматическое обновление закреплений раз в неделю с прогоном тестов, иначе через год обновиться будет невозможно. И держу сканирование в двух местах: в сборке и по расписанию на то, что уже работает, потому что уязвимость находят после выпуска.

Ответ показывает масштаб проблемы числами и даёт четыре конкретных механизма. Замечание про сканирование уже работающего отличает практика от того, кто поставил сканер в сборку и успокоился.

На чём валятся

• −Берут полновесный базовый образ по привычке и тащат в прод тысячи лишних файлов.
• −Закрепляют версии и не обновляют их: через год обновление ломает всё разом.
• −Ссылаются на базовый образ тегом, который можно перевесить, а не отпечатком.
• −Сканируют только при сборке и не сканируют то, что уже работает.
• −Оставляют в готовом образе компилятор и пакетный менеджер.