SBOM
| Software Bill of Materials (SBOM) | |
|---|---|
| Краткие сведения | |
| Термин | Software Bill of Materials, SBOM |
| Смысл | Формальный перечень компонентов программного продукта и их связей |
| Основное назначение | Прозрачность цепочки поставок ПО, учет компонентов, анализ уязвимостей и лицензий |
| Минимальные элементы | Поля данных, поддержка автоматизации, практики и процессы (NTIA) |
| Распространенные форматы | SPDX, CycloneDX, SWID (в контексте стандартов и рекомендаций) |
Software Bill of Materials (SBOM) - формальная ведомость, содержащая сведения о компонентах, использованных при создании программного продукта, и об их отношениях в цепочке поставок.[1] В материалах NIST SBOM определяется как формальная запись, перечисляющая компоненты в продукте и отражающая связи поставок, аналогично перечню ингредиентов на упаковке продуктов питания.[3]
Назначение[править]
SBOM используется как инструмент прозрачности состава программного продукта. В практических сценариях SBOM применяют для:
- инвентаризации программных компонентов (включая сторонние библиотеки и зависимости);
- сопоставления состава продукта с базами уязвимостей и вендорными бюллетенями;
- управления рисками цепочки поставок и оценки поставщиков;
- анализа соблюдения лицензионных требований (в рамках учёта компонентов и их метаданных).[2]
NIST отмечает, что SBOM ускоряет выявление и устранение уязвимостей за счет повышения прозрачности и улучшения процессов управления рисками в жизненном цикле разработки и эксплуатации.[4]
Происхождение и нормативный контекст[править]
В 2021 году в США был издан Executive Order 14028, где SBOM определен как формальная запись, содержащая детали и отношения цепочки поставок компонентов, использованных при построении ПО, и указано, что SBOM полезен разработчикам, покупателям и операторам программных продуктов.[1] На базе этого подхода NTIA опубликовало документ о минимальных элементах SBOM.[2]
Минимальные элементы SBOM[править]
В документе NTIA минимальные элементы SBOM сгруппированы в три взаимосвязанные области: поля данных, поддержка автоматизации и практики с процессами.[2]
Поля данных[править]
NTIA перечисляет базовые поля, которые должны обеспечивать идентификацию компонентов и их отношений:
- поставщик (supplier);
- наименование компонента (component name);
- версия компонента (version);
- иные уникальные идентификаторы (other unique identifiers);
- отношение зависимости (dependency relationship);
- автор данных SBOM (author of SBOM data);
- временная метка (timestamp).[2]
Поддержка автоматизации[править]
Минимальные элементы предполагают машинную читаемость и возможность автоматической генерации и обработки SBOM, чтобы использовать их в масштабе экосистемы. В документе NTIA среди форматов, применяемых для генерации и потребления SBOM, упоминаются SPDX, CycloneDX и SWID tags.[2]
Практики и процессы[править]
NTIA описывает операционные аспекты работы с SBOM, включая частоту обновления, глубину (depth), фиксацию известных пробелов (known unknowns), способы распространения и доставки, контроль доступа и обработку ошибок (accommodation of mistakes).[2]
Форматы и стандарты[править]
SPDX[править]
SPDX является открытым стандартом представления состава программных систем; на сайте проекта указано, что спецификация SPDX является международным стандартом ISO/IEC 5962:2021 и может использоваться для представления SBOM.[5] Существует отдельное руководство, описывающее, как выражать минимальные элементы NTIA в документах SPDX 2.x.[8]
CycloneDX[править]
CycloneDX описывается как объектная модель для прозрачности программных и системных цепочек поставок. В обзоре спецификации указано, что формат поддерживает описание компонентов, сервисов, графов зависимостей, а также передачу сведений об уязвимостях и связанных данных, пригодных для задач VEX и управляемого раскрытия уязвимостей.[6] В ECMA-424 (CycloneDX) отмечается ориентация стандарта на прозрачность и автоматизацию в цепочках поставок ПО и систем.[7]
SWID tags[править]
SWID tags представляют структурированный формат метаданных для описания программного продукта. NIST указывает, что формат определен стандартом ISO/IEC 19770-2 и рекомендует использовать актуальную версию; также описываются сценарии использования SWID tags для автоматизации учета установленного ПО и связанных процессов безопасности.[9]
Создание и распространение SBOM[править]
SBOM может формироваться на разных этапах жизненного цикла разработки и поставки:
- на уровне исходного кода и сборки (build-time), когда известен состав зависимостей;
- на уровне артефакта поставки (release-time), когда фиксируется окончательная комплектация;
- на уровне эксплуатации (runtime), когда используется наблюдаемость или сканирование для уточнения состава.
NIST в рекомендациях по безопасности цепочек поставок подчеркивает, что SBOM является дополняющей мерой, а не заменой существующих практик управления уязвимостями и оценок поставщиков.[4] В том же контексте указывается значимость машинной читаемости и поддержания доступных репозиториев SBOM, включая возможность подписи и контроля целостности как практик зрелого применения.[4]
Ограничения и типичные проблемы[править]
К ключевым ограничениям SBOM относят:
- неполнота данных, если в цепочке сборки отсутствует информация о части компонентов или о транзитивных зависимостях;
- различия в глубине описания (например, компонентный уровень против файлового);
- сложность синхронизации SBOM с быстро меняющимися продуктами и частыми релизами;
- необходимость согласования идентификаторов компонентов (версии, имена, CPE/PURL и др.) для корректного сопоставления с базами уязвимостей;
- вопросы доступа и конфиденциальности, когда SBOM раскрывает структуру продукта и поставщиков.
Документ NTIA прямо выделяет аспект "known unknowns" как часть практик, то есть фиксацию того, что известно, что неизвестно, и где данные неполны.[2]
Связанные понятия[править]
- Software supply chain security (безопасность цепочек поставок ПО) - область практик, в которой SBOM используется как один из инструментов прозрачности и управления рисками.[4]
- VEX (Vulnerability Exploitability eXchange) - обмен данными об эксплуатируемости уязвимостей; в материалах CycloneDX описывается поддержка сценариев, связанных с уязвимостями и VEX.[6]
Источники[править]
[1] Executive Order 14028: Improving the Nation's Cybersecurity (govinfo.gov, PDF)
[2] The Minimum Elements for a Software Bill of Materials (SBOM) (NTIA, PDF)
[3] Software Bill of Materials (SBOM) (NIST CSRC Glossary)
[4] Software Security in Supply Chains: Guidance under EO 14028 Section 4(c)/4(d) (NIST, PDF)
[5] The System Package Data Exchange (SPDX) (Linux Foundation Projects, ISO/IEC 5962:2021)
[6] CycloneDX Specification Overview (cyclonedx.org)
[7] ECMA-424: CycloneDX Bill of Materials Specification, 1st edition (Ecma International, PDF)
[8] SPDX and NTIA Minimum Elements for SBOM HOWTO (spdx.github.io)
[9] Software Identification (SWID) Tagging: Specifications and Guidelines (NIST CSRC)