SBOM

Материал из Циклопедии
Перейти к навигации Перейти к поиску
Software Bill of Materials (SBOM)
Краткие сведения
Термин Software Bill of Materials, SBOM
Смысл Формальный перечень компонентов программного продукта и их связей
Основное
назначение 		Прозрачность цепочки поставок ПО, учет компонентов, анализ уязвимостей и лицензий
Минимальные
элементы 		Поля данных, поддержка автоматизации, практики и процессы (NTIA)
Распространенные
форматы 		SPDX, CycloneDX, SWID (в контексте стандартов и рекомендаций)

Software Bill of Materials (SBOM) — формальная ведомость, содержащая сведения о компонентах, использованных при создании программного продукта, и об их отношениях в цепочке поставок.[1] В материалах NIST SBOM определяется как формальная запись, перечисляющая компоненты в продукте и отражающая связи поставок, аналогично перечню ингредиентов на упаковке продуктов питания.[2]

Назначение[править]

SBOM используется как инструмент прозрачности состава программного продукта. В практических сценариях SBOM применяют для:

  • инвентаризации программных компонентов (включая сторонние библиотеки и зависимости);
  • сопоставления состава продукта с базами уязвимостей и вендорными бюллетенями;
  • управления рисками цепочки поставок и оценки поставщиков;
  • анализа соблюдения лицензионных требований (в рамках учёта компонентов и их метаданных).[3]

NIST отмечает, что SBOM ускоряет выявление и устранение уязвимостей за счет повышения прозрачности и улучшения процессов управления рисками в жизненном цикле разработки и эксплуатации.[4]

Происхождение и нормативный контекст[править]

В 2021 году в США был издан Executive Order 14028, где SBOM определен как формальная запись, содержащая детали и отношения цепочки поставок компонентов, использованных при построении ПО, и указано, что SBOM полезен разработчикам, покупателям и операторам программных продуктов.[1] На базе этого подхода NTIA опубликовало документ о минимальных элементах SBOM.[3]

Минимальные элементы SBOM[править]

В документе NTIA минимальные элементы SBOM сгруппированы в три взаимосвязанные области: поля данных, поддержка автоматизации и практики с процессами.[3]

Поля данных[править]

NTIA перечисляет базовые поля, которые должны обеспечивать идентификацию компонентов и их отношений:

  • поставщик (англ. supplier);
  • наименование компонента (англ. component name);
  • версия компонента (англ. version);
  • иные уникальные идентификаторы (англ. other unique identifiers);
  • отношение зависимости (англ. dependency relationship);
  • автор данных SBOM (англ. author of SBOM data);
  • временная метка (англ. timestamp).[3]

Поддержка автоматизации[править]

Минимальные элементы предполагают машинную читаемость и возможность автоматической генерации и обработки SBOM, чтобы использовать их в масштабе экосистемы. В документе NTIA среди форматов, применяемых для генерации и потребления SBOM, упоминаются SPDX, CycloneDX и SWID tags.[3]

Практики и процессы[править]

NTIA описывает операционные аспекты работы с SBOM, включая частоту обновления, глубину (англ. depth), фиксацию известных пробелов (англ. known unknowns), способы распространения и доставки, контроль доступа и обработку ошибок (англ. accommodation of mistakes).[3]

Форматы и стандарты[править]

SPDX[править]

SPDX является открытым стандартом представления состава программных систем; на сайте проекта указано, что спецификация SPDX является международным стандартом ISO/IEC 5962:2021 и может использоваться для представления SBOM.[5] Существует отдельное руководство, описывающее, как выражать минимальные элементы NTIA в документах SPDX 2.x.[6]

CycloneDX[править]

CycloneDX описывается как объектная модель для прозрачности программных и системных цепочек поставок. В обзоре спецификации указано, что формат поддерживает описание компонентов, сервисов, графов зависимостей, а также передачу сведений об уязвимостях и связанных данных, пригодных для задач VEX и управляемого раскрытия уязвимостей.[7] В ECMA-424 (CycloneDX) отмечается ориентация стандарта на прозрачность и автоматизацию в цепочках поставок ПО и систем.[8]

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» как часть практик, то есть фиксацию того, что известно, что неизвестно, и где данные неполны.[3]

Связанные понятия[править]

  • Software supply chain security (безопасность цепочек поставок ПО) — область практик, в которой SBOM используется как один из инструментов прозрачности и управления рисками.[4]
  • VEX (Vulnerability Exploitability eXchange) — обмен данными об эксплуатируемости уязвимостей; в материалах CycloneDX описывается поддержка сценариев, связанных с уязвимостями и VEX.[7]

Источники[править]

  1. ↑ 1,0 1,1 Executive Order 14028: Improving the Nation’s Cybersecurity (govinfo.gov, PDF)PDF
  2. ↑ Software Bill of Materials (SBOM) (NIST CSRC Glossary)
  3. ↑ 3,0 3,1 3,2 3,3 3,4 3,5 3,6 The Minimum Elements for a Software Bill of Materials (SBOM) (NTIA, PDF)PDF
  4. ↑ 4,0 4,1 4,2 4,3 Software Security in Supply Chains: Guidance under EO 14028 Section 4(c)/4(d) (NIST, PDF)
  5. ↑ spdx.dev — The System Package Data Exchange (SPDX) (Linux Foundation Projects, ISO/IEC 5962:2021)
  6. ↑ SPDX and NTIA Minimum Elements for SBOM HOWTO (spdx.github.io)
  7. ↑ 7,0 7,1 https://cyclonedx.org/specification/overview/ CycloneDX Specification Overview
  8. ↑ ECMA-424: CycloneDX Bill of Materials Specification, 1st edition (Ecma International, PDF)PDF
  9. ↑ Software Identification (SWID) Tagging: Specifications and Guidelines (NIST CSRC)
Источник — http://cyclowiki.org/w/index.php?title=SBOM&oldid=2734738