SBOM для готовой сборки: почему списка пакетов недостаточно
Чтобы понять, есть ли проблемная библиотека в работающем выпуске, SBOM нужно связать с конкретным объектом сборки и развёртывания. Lock-файл описывает зависимости в своей области, но не обязательно весь состав готового артефакта или окружения. Отдельно нужны источник предупреждения, оценка применимости и подтверждение фактического обновления.
Какой объект должен описывать состав
Начните с вопроса владельца: какая версия реально запущена и из какого артефакта она получена? Название ветки репозитория не является достаточным ответом. После сборки, упаковки и развёртывания состав может отличаться от перечня, который изучали разработчики до публикации.
В документации Syft о целях анализа перечислены разные объекты, включая образ контейнера, каталог и архив. Они дают разные границы обследования. Поддержка типа объекта не обещает одинаково полный результат для любого языка, упаковки и способа поставки.
Почему lock остаётся полезным, но не единственным источником
Он помогает установить разрешённые версии зависимостей в соответствующем процессе. Но отдельно существуют компоненты базового образа, включённые файлы и содержимое, которое не определяется этим lock. Нужно понимать, какой именно список получен, а не объявлять любой машинный JSON полным составом программы.
Например, GitLab описывает формирование CycloneDX SBOM по поддерживаемым lock-файлам, графам или манифестам. Это конкретный механизм с определённой областью. Из его успешного выполнения нельзя вывести, что исследовано всё возможное окружение работающего сервиса.
Учебная карта объектов и ограничений
В таблице предлагается схема выбора объекта. Речь не о выполненном сканировании проектов пользователя: инструменты не устанавливались, образы не скачивались. Для настоящего результата нужно сохранить фактический объект и способ получения сведений.
| Объект учёта | Что может описывать источник | Чего не следует обещать | Как связать с выпуском | Следующее действие |
|---|---|---|---|---|
| Репозиторий и lock | Поддерживаемые зависимости проекта | Полный состав любой собранной поставки | Версия исходников и выбранный набор файлов | Сопоставить с процессом сборки |
| Готовый каталог или архив | Распознанные компоненты внутри объекта | Знание содержимого за пределами объекта | Идентификатор и контрольная сумма артефакта | Зафиксировать границы анализатора |
| Образ контейнера | Распознанные пакеты образа | Полную картину последующих изменений среды | Проверяемый идентификатор нужного образа | Сопоставить с фактическим развёртыванием |
| Работающее окружение | Подтверждённые дополнительные компоненты по выбранной процедуре | Что один анализ образа обнаружил всё добавленное позже | Связь окружения с развёрнутым выпуском | Отдельно учесть изменения после поставки |
Какие сведения нужны рядом с перечнем
Сохраните объект, момент получения, инструмент и применимые ограничения распознавания. Для артефакта полезна контрольная сумма, для контейнера — устойчивый идентификатор, который действительно сопоставлен с запуском. Просто одинаковое человекочитаемое имя не всегда отвечает на вопрос, тот ли выпуск проверен.
Не подставляйте вымышленные версии компонентов там, где анализатор не смог их установить. Неизвестная версия — задача на уточнение. Она не становится безопасной только потому, что сопоставление с предупреждениями ничего не нашло.
Также отличайте отсутствие компонента по подтверждённому исследованию от отсутствия его в неполном источнике. В отчёте должны быть видны ограничения. Иначе отрицательный результат поиска получит более сильный смысл, чем позволяет состав выбранного объекта.
SBOM и предупреждение об уязвимости — разные результаты
Перечень компонентов является инвентаризацией. Сопоставление с источником предупреждений — следующий этап. В документации GitLab эти результаты описываются отдельно: документы состава и отчёт dependency scanning. Название формата не означает, что все найденные компоненты автоматически исследованы любым доступным способом.
Для предупреждения проверьте идентичность и версию компонента, затронутые условия и фактическое использование. Одно совпадение имени не доказывает возможность эксплуатации. Но и решение «не применимо» должно иметь основание, а не появляться ради уменьшения числа красных строк.
Новые сведения о проблемах могут появиться уже после создания состава. Поэтому сохранённый SBOM можно использовать для повторной оценки при изменении источника предупреждений. Его прежнее существование не является бессрочным сертификатом безопасности.
Обновление в репозитории ещё не обновление сервиса
Представим учебный выпуск А с компонентом, по которому требуется действие. Разработчик подготовил выпуск Б с исправлением. Пока не подтверждено развёртывание Б, факт изменения исходников не отвечает на вопрос о работающей версии. Здесь нет настоящего компонента, номера CVE или заявленного инцидента.
Сопоставьте новый артефакт, его состав и фактический запуск. Старые экземпляры и прежние задания могут продолжать использовать другой выпуск. Задача закрывается по согласованной области, а не только по отметке успешной сборки.
Кому передаётся инвентаризация
Определите владельца состава и порядок обновления при новом релизе. Заказчику нужен не просто файл, а понимание его происхождения, области и применимости к поставке. Внутренние технические сведения передают в согласованной области доступа, не публикуя их по умолчанию.
Не объявляйте SBOM обязательным для каждого малого бизнеса по одному упоминанию проектных требований. В этой статье речь о практической проверке состава. Нормативные обязанности для конкретной поставки требуют самостоятельного подтверждения применимых оснований.
Порядок приёмки состава выпуска
- Назовите проверяемый выпуск и объект: исходники, артефакт, образ или окружение.
- Выберите способ анализа с понятными поддерживаемыми форматами и ограничениями.
- Сохраните состав вместе с идентификатором объекта и происхождением результата.
- Отдельно разберите предупреждения и основания применимости.
- После исправления свяжите новый состав с новым артефактом.
- Подтвердите фактическое развёртывание исправленного выпуска в согласованной области.
Для аудита безопасности передайте область состава и связь с запуском. В задаче поддержки сервера нужны сведения о реально используемом выпуске. Если требуется доработка процесса, включите получение и передачу состава в условия публикации.
Хороший результат позволяет проследить путь от работающего сервиса к объекту, компоненту и решению по предупреждению. Отдельный lock, SBOM или список CVE без этих связей не заменяет такую проверку.
Вопросы и ответы
Что такое SBOM-файл для приложения?
Это описание состава в определённой области и формате. Чтобы применять его к работающему сервису, нужно знать объект, выпуск, способ получения и ограничения результата.
Чем SBOM отличается от lock-файла?
Lock относится к зависимостям соответствующего процесса, а состав может описывать другой объект, например готовый артефакт или образ. Область и полноту нужно устанавливать по фактическому источнику, а не по расширению файла.
Достаточно ли SBOM контейнера для подтверждения безопасности?
Нет: инвентаризация не является сертификатом и не заменяет оценку предупреждений. Также нужно сопоставить образ с запуском и отдельно учесть изменения вне его области.