OCI-образ или SBOM: выбор security gate для CI/CD

Проверку контейнерного артефакта в CI/CD можно организовать двумя способами. Первый — передать сканеру Docker- или OCI-образ, чтобы он получил манифест, исследовал файловую систему и определил установленные компоненты. Второй — заранее сформировать SBOM, сохранить его рядом с образом, а в security gate повторно сопоставлять перечисленные компоненты с актуальной базой уязвимостей.

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

Поэтому выбирать следует не просто между образом и файлом меньшего размера. Нужно определить, где конвейер будет формировать достоверный состав артефакта, как он свяжет SBOM с конкретным digest образа и когда обновлённая vulnerability database должна влиять на решение о выпуске.

Что происходит при прямом сканировании образа

Сканер получает образ из локального контейнерного движка, OCI layout, архива или registry. Затем он читает манифест и конфигурацию, загружает или открывает слои, восстанавливает доступное ему представление файловой системы и ищет признаки компонентов. Это могут быть базы системного пакетного менеджера, lock-файлы, манифесты зависимостей, метаданные библиотек, исполняемые файлы и другие поддерживаемые источники.

Полученный инвентарь сопоставляется с vulnerability database. Таким образом, результат зависит сразу от нескольких переменных:

• содержимого образа и выбранной платформы;
• версии сканера и его анализаторов;
• настроек поиска пакетов и исключений;
• состояния кэша;
• версии базы уязвимостей;
• доступности registry и корректного выбора образа.

Сильная сторона подхода заключается в близости к проверяемому объекту. Gate исследует тот артефакт, который планируется отправить в registry или развернуть. Если в финальном этапе многостадийной сборки появился дополнительный пакет, библиотека была скопирована без исходного lock-файла или базовый образ изменился, анализ содержимого может обнаружить это независимо от сведений, подготовленных на ранней стадии сборки.

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

Что происходит при проверке готового SBOM

SBOM отделяет инвентаризацию от поиска уязвимостей. Один процесс исследует артефакт и записывает компоненты, их версии, типы, идентификаторы, связи и другие метаданные. Позднее vulnerability scanner читает этот документ и сопоставляет его записи со своей текущей базой.

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

Ключевое преимущество — дорогая операция извлечения состава выполняется один раз. Все последующие проверки работают с компактным структурированным документом. Но полнота результата ограничена тем, что попало в SBOM: сканер уязвимостей не сможет восстановить отсутствующий пакет, путь к файлу или контекст дистрибутива, если не обращается к самому образу.

SBOM ускоряет повторное сопоставление компонентов с уязвимостями, но не исправляет ошибки и пробелы первоначальной инвентаризации.

Скорость и нагрузка на CI/CD

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

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

Для централизованного сканирования и хранения кэша может потребоваться отдельный вычислительный ресурс, например VPS-сервер, доступный CI-runner и registry. При этом конкретная архитектура зависит от используемого CI/CD, числа параллельных сборок и требований к изоляции.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

SBOM обычно значительно меньше образа и не требует распаковки его файловой системы. Это особенно важно в следующих ситуациях:

• один артефакт проверяется на нескольких этапах продвижения между средами;
• security gate выполняется повторно после обновления vulnerability database;
• в registry хранится много образов с общими слоями;
• сканирование запускается централизованно вне build runner;
• образ велик, а пропускная способность сети или реестра ограничена;
• необходимо регулярно переоценивать уже выпущенные версии.

Однако скорость не следует оценивать только по среднему времени одной команды. Важны задержка на критическом пути, количество параллельных сборок, объём передаваемых данных и вероятность повторных запусков. Если образ уже собран локально, невелик и сканируется один раз, преимущество SBOM может быть менее значительным. Если тот же артефакт проверяется при сборке, публикации, развёртывании и по расписанию, повторное чтение ведомости обычно выгоднее.

Воспроизводимость: два разных требования

Под воспроизводимостью security gate часто понимают разные свойства. Первое — возможность снова получить тот же список компонентов. Второе — возможность повторить прежний список обнаруженных уязвимостей. Эти задачи требуют разных условий.

Воспроизводимость инвентаря

Сохранённый SBOM фиксирует результат инвентаризации и потому удобен для аудита. Через некоторое время команда может увидеть, какой состав был определён в момент сборки, даже если версия генератора изменилась или сам образ удалён из оперативного registry.

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

Для надёжного воспроизведения необходимо сохранять не только SBOM, но и сведения о его происхождении: digest образа, версию генератора, параметры анализа, выбранную платформу и время создания. Ссылка только на тег недостаточна, поскольку тег может быть переназначен другому манифесту.

Воспроизводимость результатов поиска уязвимостей

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

Если требуется воспроизвести историческое решение gate, нужно знать версию vulnerability database, конфигурацию сопоставления, фильтры и версию сканера. Если требуется оценить риск сейчас, напротив, следует использовать актуальную базу. Один отчёт не может одновременно быть неизменным доказательством прошлого решения и постоянно обновляемой оценкой текущего риска.

Практичная модель состоит из двух записей:

• неизменяемый отчёт о проверке на момент выпуска с идентификаторами инструмента, политики и базы;
• текущий результат повторного сопоставления того же SBOM с обновлёнными данными.

Полнота метаданных и качество сопоставления

Для поиска уязвимости недостаточно пары из названия и версии. Системный пакет может иметь разные исправления и правила версионирования в разных дистрибутивах. Компонент приложения может потребовать указания экосистемы, пространства имён или однозначного идентификатора. Для анализа зависимостей полезны сведения о происхождении, путях, связях и области использования.

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

Проблемы возникают, если ведомость:

• создана по исходному репозиторию, а не по финальному образу;
• включает зависимости сборочной среды, отсутствующие во время выполнения;
• не учитывает файлы, добавленные на поздних стадиях Dockerfile;
• теряет контекст операционной системы или архитектуры;
• не содержит точных версий либо стандартных идентификаторов компонентов;
• сводит прямые и транзитивные зависимости в плоский список без происхождения;
• была преобразована между форматами с потерей расширенных полей.

Обратная ситуация также возможна. SBOM, созданный специализированным генератором в контролируемой среде сборки, может содержать сведения, которые универсальный image scanner не извлекает. Например, система сборки иногда лучше знает происхождение внутреннего компонента или связь между собранным модулем и исходной зависимостью. Поэтому сравнение должно учитывать не только тип цели, но и качество конкретного этапа инвентаризации.

Для gate важнее не максимальное число строк, а соответствие ведомости реальному runtime-артефакту. SBOM репозитория, SBOM build environment и SBOM финального OCI-образа описывают разные объекты и не должны автоматически подменять друг друга.

Как обновление vulnerability database влияет на выбор

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

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

Но актуальная база важна и на основном build gate. Если runner использует давно сохранённую vulnerability database ради скорости или из-за сетевых ограничений, новый образ может пройти проверку по устаревшим данным. Поэтому политика должна отдельно определять:

• максимально допустимый возраст базы для блокирующего gate;
• источник и порядок обновления базы;
• поведение при невозможности проверить её актуальность;
• различие между ошибкой инфраструктуры и успешной проверкой без находок;
• частоту повторного анализа опубликованных SBOM.

Режим fail-open, при котором недоступность базы или registry превращается в успешный результат, снижает ценность gate. В то же время безусловный fail-closed способен остановить все поставки из-за временной инфраструктурной ошибки. Команда должна явно разделять нарушение security policy, технический сбой сканера и невозможность подтвердить свежесть данных, назначая для них разные правила эскалации.

Доверие к SBOM и связь с образом

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

Иначе возможна опасная подмена: gate проверит корректный SBOM от предыдущей сборки, а в production будет отправлен другой образ под тем же тегом. Аналогичная проблема возникает, если после формирования SBOM образ дополнительно модифицируют, перепаковывают или дополняют новым слоем.

Полезно проверять следующие свойства:

• SBOM создан после формирования финального артефакта или непосредственно из него;
• digest в ведомости совпадает с digest кандидата на выпуск;
• документ хранится как неизменяемый артефакт или OCI-объект, связанный с образом;
• известны генератор, его версия и параметры;
• целостность и происхождение ведомости можно подтвердить;
• при изменении образа прежний SBOM не используется повторно.

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

Формат SBOM как зависимость, а не основной критерий

Выбор между SPDX, CycloneDX и поддерживаемыми инструментом вариантами представления важен, но вторичен по отношению к качеству данных. Формат должен сохранять необходимые идентификаторы, версии, связи, контекст дистрибутива и ссылку на исходный артефакт. Также его должны без неоднозначности читать генератор, сканер и система хранения.

Даже формально корректные документы одного стандарта могут различаться по наполнению. Инструменты по-разному описывают типы компонентов, пути и зависимости. Сканер способен принять файл, но использовать только часть его полей. Поэтому совместимость необходимо проверять на реальных образах, а не только по наличию названия формата в документации. Подробнее о выборе формата можно прочитать в статье «SPDX 3.0 и CycloneDX 1.7: выбор формата SBOM для CI и аудита».

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

Когда лучше сканировать OCI-образ напрямую

Прямой анализ предпочтителен, если gate должен независимо подтвердить фактический состав финального артефакта. Это особенно важно в следующих случаях:

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

Такой gate логично размещать после сборки финального образа и обращаться к нему по digest. Проверка тега до публикации и проверка другого манифеста после публикации не подтверждают один и тот же объект. Для multi-platform image необходимо также понимать, сканируется ли индекс целиком или конкретный манифест для выбранной архитектуры.

Когда лучше повторно проверять SBOM

Сканирование ведомости подходит, когда достоверная инвентаризация уже выполнена, а задача gate — быстро применить актуальную vulnerability policy. Типичные сценарии:

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

Этот вариант безопасен только при наличии контроля качества SBOM. Если ведомость не привязана к digest, создаётся нерегулярно или не покрывает используемые экосистемы, ускорение достигается ценой неизвестного числа пропусков.

Почему гибридная схема обычно надёжнее

Для большинства зрелых конвейеров прямое сканирование и проверка SBOM не являются взаимоисключающими альтернативами. Их можно использовать на разных этапах, не выполняя полную работу при каждом продвижении.

1. После сборки финальный образ идентифицируется по digest и анализируется для получения инвентаря.
2. На том же этапе формируется SBOM, сохраняются сведения о генераторе и выполняется проверка связи с digest.
3. Перед публикацией или выпуском применяется блокирующая vulnerability policy с достаточно свежей базой.
4. При продвижении между средами проверяется неизменность digest, а быстрое повторное сопоставление выполняется по сохранённому SBOM.
5. После выпуска ведомости регулярно переоцениваются с обновлённой базой без повторного разбора всех слоёв.
6. Периодически или по событию запускается прямое повторное сканирование: после обновления анализаторов, изменения генератора либо обнаружения расхождений.

В этой модели образ остаётся источником истины о поставляемых байтах, а SBOM — зафиксированным и пригодным для быстрого повторного анализа представлением состава. Gate не доверяет ведомости безусловно, но и не оплачивает извлечение одного инвентаря на каждом этапе.

Как сравнить варианты в своём конвейере

Решение лучше принимать по измеримым свойствам, а не по общему утверждению, что SBOM всегда быстрее или прямой сканер всегда полнее. Для нескольких репрезентативных образов стоит сравнить:

• время холодного запуска без кэша;
• время повторного запуска с кэшем;
• объём загрузок из registry;
• число найденных компонентов по экосистемам;
• расхождения в названиях, версиях и идентификаторах;
• наличие контекста ОС, архитектуры, путей и связей;
• результат после обновления vulnerability database;
• поведение при повреждённом, устаревшем или чужом SBOM;
• возможность воспроизвести историческое решение;
• стоимость хранения образов, кэша, SBOM и отчётов.

Особое внимание следует уделить компонентам, найденным только одним способом. Расхождение не всегда означает ошибку: один отчёт может учитывать build-зависимости, а другой — только содержимое финального образа. Нужно определить происхождение каждой значимой разницы и решить, какой объект должна описывать политика.

Ошибки при проектировании security gate

Сканирование по изменяемому тегу

Если сборка, сканер и deployment разрешают тег независимо, они могут работать с разными манифестами. Для передачи между этапами нужен digest, полученный после публикации или формирования итогового OCI-артефакта.

Создание SBOM слишком рано

Ведомость, полученная до финальной стадии сборки, не учитывает последующие изменения. Она полезна для анализа исходного проекта, но не заменяет инвентарь поставляемого образа.

Подмена актуальности базы повторным анализом слоёв

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

Безусловное доверие успешному парсингу SBOM

Файл может быть синтаксически корректным, но пустым, неполным или относящимся к другому артефакту. Gate должен проверять ожидаемое число типов компонентов, обязательные метаданные и связь с digest.

Отсутствие повторной оценки после выпуска

Успешный gate подтверждает соответствие политике на конкретный момент. Он не означает, что образ останется безопасным до конца жизненного цикла. Сохранённый SBOM позволяет закрыть этот пробел с меньшими затратами.

Смешивание разных политик в одном результате

Build gate, разрешение на deployment и реакция на новую уязвимость решают разные задачи. Для них могут различаться допустимый возраст базы, набор исключений и действие при сбое. Единый статус без контекста затрудняет аудит и автоматизацию.

Итоговый критерий выбора

Прямое сканирование OCI-образа следует выбирать как основной gate, когда необходимо заново установить фактический состав артефакта и нет достаточно доверенного SBOM. Этот подход требует больше времени и инфраструктурных ресурсов, зато уменьшает зависимость от ранее подготовленной ведомости.

Проверка готового SBOM предпочтительна, когда инвентарь уже создан из финального образа, привязан к его digest и прошёл контроль качества. Она ускоряет продвижение артефактов и позволяет регулярно применять обновлённую vulnerability database к уже выпущенным версиям.

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

Таким образом, предмет выбора — не файл против образа, а место разделения двух операций: инвентаризации и сопоставления с уязвимостями. Чем надёжнее первая операция и связь её результата с digest, тем больше проверок можно безопасно перенести на SBOM и тем меньше времени security gate будет занимать в CI/CD.