В последние годы значимость SBOM (Software Bill of Materials, перечень программных компонентов) стремительно возросла. В условиях растущих требований к прозрачности программного обеспечения, усиления нормативного регулирования и опасений по поводу безопасности цепочек поставок, все больше организаций стремятся внедрить SBOM в свои процессы. Однако при всем видимом прогрессе, большинство сгенерированных SBOM демонстрируют низкое качество и не выполняют свои основные задачи. Почему так происходит и какие шаги стоит предпринять, чтобы исправить ситуацию? Попробуем разобраться. SBOM по сути должна обеспечивать точное отображение всех компонентов программного продукта, включая сведения о лицензиях, версиях, поставщиках и других критически важных метаданных.
Именно на основе этих данных строится управление безопасностью, соблюдение лицензионных требований и мониторинг уязвимостей. Ключевым ожиданием является простота интеграции, полнота и актуальность информации. Тем не менее, на практике большая часть SBOM оказывается неполной, неточной или трудно воспринимаемой. Одной из главных причин неудач SBOM является отсутствие качества данных. Часто отчеты содержат недостаточное количество информации, например, ключевые поля остаются пустыми — лицензии, сведения о поставщиках или контрольные суммы отсутствуют.
Также нередки ситуации с повторяющимися компонентами или массовым использованием пометок «no-assertion», которые по сути сигнализируют об отсутствии информации, а не предоставляют реальный ответ. Такой уровень неполноты значительно снижает доверие к документу и ограничивает его полезность. Важное внимание стоит уделить лицензиям — нередко ошибки в определении лицензионных условий связаны с чрезмерной уверенностью в работе автоматизированных средств анализа программного обеспечения (САА, Software Composition Analysis). Хотя эти инструменты развиваются, они всё еще не способны гарантировать 100% точность. Кроме того, часто вопросы лицензирования попадают под контроль отделов безопасности, которые одновременно управляют бюджетом на инструменты.
Это сочетание может приводить к приоритету упрощенного решения задачи, а не глубокой проверки качества. Не менее важную проблему создает несовместимость форматов. На рынке распространены два основных стандарта для SBOM — SPDX и CycloneDX. Несмотря на схожие цели, их структурные отличия провоцируют сложности при интеграции и конвертации данных. Многие инструменты и процессы недостаточно быстро адаптируются к изменениям стандартов, новым полям и функциям, что усугубляет фрагментацию экосистемы и ограничивает взаимодействие между разными звеньями цепочки поставок.
Автоматическая генерация SBOM обычно воспринимается как гарантия качества, однако это далеко не так. Инструменты часто создают документы без последующей валидации, что ведет к распространению неточных или неполных данных. Без тщательной проверки такой SBOM может не соответствовать требованиям комплаенса, не отражать реальную структуру продукта или содержать юридически рискованные компоненты. Чтобы понимать, что делает SBOM действительно качественной, важно ориентироваться на рекомендации международных справочников, например, OpenChain Telco SBOM Guide v1.1.
В этом документе подчеркивается необходимость стандартизации, полноты и прозрачности данных. Ключевая рекомендация — при передаче SBOM она должна быть ясной, непротиворечивой и полной с точки зрения основных метаданных, информации о лицензиях и зависимости, включая транзитивные компоненты. Тестирование качества SBOM — еще один необходимый шаг. Использование схемной валидации (JSON, XML) помогает убедиться, что структура соответствует стандартам SPDX или CycloneDX. Важно удостоверяться, что в документе присутствует вся информация, необходимая для нормативного соответствия, включая лицензии, версии и сведения о поставщиках.
Также стоит использовать специализированные инструменты для проверки лицензионных данных, сравнивая их с авторитетными наборами данных. Это помогает выявлять ошибки и неполные утверждения в SBOM. Особое внимание уделяется анализу полей «no-assertion», которые сигнализируют о том, что заявленные данные не подтверждены. Высокий процент таких записей указывает на поверхностное или ошибочное формирование SBOM. Иногда коммерческие инструменты пытаются заполнить эти пробелы предположениями, что противоречит принципу прозрачности и может ввести в заблуждение конечных пользователей.
Для выявления потенциальных рисков рекомендуется сканировать SBOM с использованием баз данных уязвимостей и проблемных пакетов. Существуют проекты с открытыми наборами проблемных компонентов и данных о глубинных зависимостях, такие как VulnerableCode, ClearlyDefined, OSSA и другие. Особая важность уделяется криптографическим библиотекам и их соответствию требованиям безопасности. При работе с несколькими форматами SBOM крайне важно протестировать конвертацию между ними так, чтобы сохранить целостность и точность данных. Также необходимо проверять наличие и корректность хэшей, которые играют критическую роль в обеспечении подлинности компонентов.
Проверка целостности метаданных помогает обнаружить попытки манипуляций или предоставления неполной информации от вендоров. Отсутствие описания используемых инструментов, противоречия внутри файлов — все это признаки низкого качества, на которые стоит обратить внимание. Одной из основных проблем индустрии остается тот факт, что стандарты SBOM развиваются быстрее, чем инструменты для их поддержки. Новые поля, дополнительные функции и требования вводятся регулярно, в то время как сканеры, автоматизированные процессы и движки политики зачастую обновляются с задержкой или не обновляются вовсе. Такое расхождение создает серьезные проблемы с интеграцией, автоматизацией и выявлением рисков, что в итоге сказывается на общей надежности экосистемы.
Самая главная мысль, которая должна быть усвоена всеми участниками процесса, заключается в том, что создание SBOM — это не одномоментная задача генерации файла. Важно акцентировать внимание на качестве, что требует сотрудничества между стандартными организациями, разработчиками инструментов и конечными пользователями. Проверка соответствия схемам — это минимальное требование, но для достижения реальной ценности необходимы четкие критерии качества, совместимость между форматами и автоматические механизмы, выявляющие низкокачественные SBOM. До появления общепринятых стандартов качества каждой команде следует самостоятельно проверять и улучшать SBOM, делиться обратной связью с экосистемой и помогать совершенствовать процессы. Только такой подход позволит повышать уровень прозрачности, снижать риски и обеспечивать эффективное управление цепочкой поставок программного обеспечения.
В заключение стоит отметить, что качество SBOM — это не просто техническая задача, а важный аспект корпоративной безопасности, комплаенса и ответственности. Инвестиции в обучение, развитие подходящих инструментов и обмен опытом имеют решающее значение для успешного внедрения SBOM и повышения доверия к программным продуктам на рынке.
