Спецификация программного обеспечения (SBOM) — это список всех компонентов, библиотек и других зависимостей, используемых в программном приложении. Стандартные форматы SBOM включают SPDX, CycloneDX и CPE (Common Platform Enumeration). Эти форматы обеспечивают структурированный способ представления компонентов и зависимостей в программном приложении, упрощая понимание и управление рисками безопасности, связанными с этими компонентами.
В этой статье мы собираемся подробно объяснить, каковы различные форматы и стандарты SBOM, что должен включать SBOM и почему все организации должны его использовать.
Что такое стандарт SBOM?
Сложность и динамичный характер цепочек поставок современных программных систем создают серьезные проблемы для прозрачности. Отсутствие прозрачности увеличивает риски кибербезопасности и увеличивает затраты, связанные с разработкой, закупками и обслуживанием. Последствия этого имеют далеко идущие последствия, затрагивая не только бизнес, но и коллективные вопросы, такие как общественная и национальная безопасность в нашем взаимосвязанном мире.
Повышение прозрачности цепочек поставок программного обеспечения может привести к снижению рисков и затрат в области кибербезопасности за счет:
- Улучшение выявления уязвимых систем и определение первопричин инцидентов
- Сокращение незапланированной и непродуктивной работы.
- Обеспечение более осознанной дифференциации рынка и выбора компонентов
- Стандартизация форматов во многих секторах, что приводит к сокращению дублирования усилий.
- Обнаружение подозрительных или поддельных компонентов программного обеспечения
Сбор и обмен этой информацией в четком и последовательном формате может помочь снизить затраты, повысить надежность и повысить доверие к нашей цифровой инфраструктуре.
Для этой цели, Рабочая группа NTIA по прозрачности программного обеспечения по стандартам и форматам была создана в 2018 году для оценки текущих форматов спецификаций программного обеспечения и определения потенциальных вариантов использования в будущем. Группа изучила существующие стандарты и инициативы, связанные с идентификацией внешних компонентов и общих библиотек, используемых в программных продуктах, и передачей этой информации в машиночитаемом формате. Группа не рассматривала проприетарные форматы. Исходный опрос был выпущен в конце 2019 года и обновлен в 2021 году с упором на подчеркивание преимуществ экосистемы инструментов SBOM и важности координации и гармонизации в техническом мире SBOM. Ключевой вывод заключается в том, что данные SBOM могут передаваться в различных форматах, и экосистема должна поддерживать взаимодействие между ними.
Рабочая группа обнаружила, что обычно используются три формата:
- Обмен данными пакетов программного обеспечения (SPDX®), машиночитаемый формат с открытым исходным кодом, разработанный Linux Foundation и теперь являющийся стандартом ISO/IEC.
- CycloneDX (CDX), машиночитаемый формат с открытым исходным кодом, разработанный сообществом OWASP.
- Идентификация программного обеспечения (SWID), отраслевой стандарт ISO/IEC, используемый различными издателями коммерческого программного обеспечения.
Стоит отметить, что эти три формата имеют некоторую общую информацию. Однако они традиционно используются на разных этапах процесса разработки программного обеспечения и предназначены для разных аудиторий. В этой статье мы подробно обсудим каждый из этих форматов.
Что должно включать в себя SBOM?
Минимальные компоненты NTIA SBOM, называемые элементами, состоят из трех широких и взаимосвязанных областей. Эти элементы обеспечивают гибкий подход к прозрачности программного обеспечения, касаясь как технологии, так и функциональной работы. В будущем могут быть добавлены более подробные сведения или технические усовершенствования. Как упоминалось ранее, на данный момент это минимальные компоненты, и организациям может потребоваться больше компонентов. Возможность обеспечения прозрачности в цепочке поставок программного обеспечения может со временем улучшаться и развиваться.
Эти минимально необходимые элементы для СБОМ обычно группируются в три категории:
- Поля данных: SBOM должен включать важные данные о компонентах программного обеспечения, такие как имя компонента, имя поставщика, версия и уникальные идентификаторы. Он также должен включать информацию о зависимостях между компонентами, позволяющую точно идентифицировать и отслеживать все компоненты программного обеспечения по всей цепочке поставок.
- Практики и процессы: В документации SBOM также должны быть описаны стандартные методы и процедуры создания и обновления SBOM, распространения и доступа к нему, а также обработки ошибок.
- Поддержка автоматизации: Спецификация программного обеспечения должна быть машиночитаемой и автоматически генерироваться для непрерывного отслеживания данных. Обычно они представлены в стандартных форматах, таких как теги SPDX, CycloneDX и SWID, что также делает их читабельными для людей.
Стандартный формат SPDX SBOM
Спецификация SPDX® (обмен данными программных пакетов) — это стандарт ISO/IEC для обмена информацией о компонентах программного обеспечения, лицензиях, авторских правах и сведениях о безопасности в различных форматах файлов. В рамках этого проекта был разработан и продолжает совершенствовать набор стандартов обмена данными, которые позволяют предприятиям и организациям обмениваться метаданными программного обеспечения в формате, понятном как людям, так и машинам, упрощая процессы цепочки поставок программного обеспечения.
Информация SPDX может быть связана с конкретными программными продуктами, компонентами или наборами компонентов, отдельными файлами или даже небольшими фрагментами кода. Проект SPDX сосредоточен на создании и совершенствовании языка для описания данных, которыми можно обмениваться как часть SBOM, а также на возможности представления этих данных в нескольких форматах файлов (RDF/XML, XLSX, тег-значение, JSON, YAML). и XML), чтобы упростить сбор и обмен информацией о пакетах программного обеспечения и соответствующем контенте, что приводит к сокращению времени и точности.
Спецификация SPDX описывает поля и разделы, необходимые для правильного документа, но важно отметить, что не все разделы являются обязательными — требуется только раздел информации о создании. Создатель документа может выбрать, какие разделы и поля он хочет включить, описывая программное обеспечение и метаданные, которыми он планирует поделиться.
SPDX может эффективно собирать данные спецификации программного обеспечения, представляя все компоненты, обнаруженные при разработке и развертывании программного обеспечения. Он используется для документирования образов дистрибутива .iso, контейнеров, пакетов программного обеспечения, двоичных файлов, исходных файлов, исправлений и даже небольших фрагментов кода, встроенных в другие файлы. SPDX предлагает комплексный набор связей для соединения элементов программного обеспечения внутри документов и между документами SBOM. Документ SPDX SBOM также может ссылаться на внешние источники, такие как Национальная база данных уязвимостей и другие метаданные системы упаковки.
Документ SPDX состоит из нескольких компонентов: информация о создании, информация о пакете, информация о файле, информация о фрагменте, другая информация о лицензировании, взаимосвязях и аннотациях.
Каждый документ SPDX может быть представлен полной реализацией модели данных и синтаксисом идентификатора, что позволяет осуществлять обмен между различными форматами вывода данных (RDF/XML, тег-значение, XLSX) и формальную проверку точности документа. Версия 2.2 спецификации SPDX включает дополнительные форматы вывода, такие как JSON, YAML и XML, а также устраняет «известные неизвестные», как указано в исходном документе SBOM. Дополнительную информацию о базовой модели данных SPDX можно найти в Приложении III к спецификации SPDX и на веб-сайте SPDX.
Стандартный формат CycloneDX SBOM
Проект CycloneDX был создан в 2017 году с целью разработки полностью автоматизированного стандарта SBOM, ориентированного на безопасность. Основная рабочая группа ежегодно выпускает неизменяемые и обратно совместимые версии, используя процесс стандартизации, основанный на оценке рисков. CycloneDX включает существующие спецификации, такие как URL-адрес пакета, CPE, SWID и идентификаторы лицензий и выражения SPDX. SBOM могут быть представлены в различных форматах, включая XML, JSON и буферы протокола (protobuf).
CycloneDX — это облегченная спецификация SBOM, предназначенная для использования в анализе компонентов цепочки поставок и обеспечении безопасности программного обеспечения. Он обеспечивает обмен информацией о перечне компонентов программного обеспечения, внешних службах и связях между ними. Это стандарт с открытым исходным кодом, разработанный OWASP (Open Web Application Security Project).
CycloneDX может отражать динамическую природу компонентов с открытым исходным кодом, исходный код которых доступен, модифицируется и может распространяться. Спецификация может представлять родословную компонента, включая его предков, потомков и варианты, описывая происхождение компонента с любой точки зрения, а также фиксации, исправления и различия, которые делают его уникальным.
Проект CycloneDX поддерживает список известных инструментов с открытым исходным кодом и проприетарных инструментов, которые поддерживают стандарт, поддерживаемый сообществом, или совместимы с ним.
Спецификация CycloneDX описывает подробную объектную модель, которая обеспечивает согласованность во всех реализациях. Его можно проверить с помощью схемы XML и схемы JSON или с помощью интерфейса командной строки CycloneDX. Типы мультимедиа для XML и JSON также предусмотрены для автоматической доставки и использования поддерживаемых форматов.
SBOM CycloneDX могут содержать следующую информацию: Метаданные спецификации, компоненты, сервисы, зависимости, композиции и расширения.
CycloneDX — это комплексный стандарт SBOM, который может характеризовать различные типы программного обеспечения, включая приложения, компоненты, службы, встроенное ПО и устройства. Он широко используется в различных отраслях для описания пакетов программного обеспечения, библиотек, платформ, приложений и образов контейнеров. Проект совместим с основными экосистемами разработки и предлагает реализации для фабрик программного обеспечения, такие как действия GitHub, что позволяет организациям полностью автоматизировать создание SBOM.
SWID-тег
Теги SWID или теги идентификации программного обеспечения были созданы, чтобы позволить организациям прозрачно отслеживать программное обеспечение, установленное на их управляемых устройствах. Стандарт был установлен ISO в 2012 году и пересмотрен как ISO/IEC 19770-2:2015 в 2015 году. Эти теги содержат подробную информацию о конкретной версии программного продукта.
Стандарт SWID описывает жизненный цикл отслеживания программного обеспечения: тег SWID добавляется к конечной точке во время установки программного продукта и удаляется в процессе удаления продукта. Существование определенного тега SWID напрямую соответствует наличию описываемого им программного обеспечения. Многие организации по стандартизации, такие как Trusted Computing Group (TCG) и Internet Engineering Task Force (IETF), включают теги SWID в свои стандарты.
Для отслеживания жизненного цикла программного компонента в спецификации SWID предусмотрены четыре типа тегов: основной, исправленный, корпусной и дополнительный. Корпусные, первичные теги и теги исправлений служат схожим целям, поскольку они описывают существование и присутствие различных типов программного обеспечения, таких как установщики программного обеспечения, установки программного обеспечения и исправления программного обеспечения, а также возможные состояния программных продуктов. С другой стороны, дополнительные теги предоставляют дополнительную информацию, отсутствующую в корпусных, основных тегах или тегах исправлений.
Дополнительные теги можно связать с любым другим тегом, чтобы предоставить дополнительные метаданные, которые могут оказаться полезными. Вместе теги SWID могут выполнять различные функции, такие как обнаружение программного обеспечения, управление конфигурацией и управление уязвимостями.
Теги SWID могут функционировать как SBOM, поскольку они предоставляют идентифицирующую информацию для программного компонента, список файлов и криптографические хэши для артефактов компонента, а также информацию о происхождении создателя SBOM (тега) и создателя программного компонента. Теги также могут быть связаны с другими тегами, что позволяет представить дерево зависимостей.
Теги SWID могут создаваться в процессе сборки и упаковки, что позволяет автоматически создавать SBOM на основе тегов SWID при упаковке соответствующего программного компонента.
Почему важны спецификации программного обеспечения?
Спецификации программного обеспечения (SBOM) становятся все более важными для организаций, поскольку они стремятся управлять и защищать используемое ими программное обеспечение. На вопрос о том, нет короткого ответа что такое СБОМ. SBOM предоставляют полный список всех компонентов и зависимостей, составляющих пакет программного обеспечения, включая такую информацию, как номера версий, авторов и информацию о лицензии. Эта информация имеет решающее значение для безопасности и соответствия требованиям, а также для отслеживания происхождения программных компонентов.
Многие организации, в том числе в регулируемых отраслях, используют SBOM для обеспечения соблюдения таких правил, как Общий регламент по защите данных (GDPR) и Стандарт безопасности данных индустрии платежных карт (PCI DSS). SBOM также могут помочь в выявлении и устранении уязвимостей в программном обеспечении, а также в отслеживании происхождения компонентов программного обеспечения. Кроме того, SBOM могут помочь в управлении лицензиями на программное обеспечение, гарантируя, что организации используют программное обеспечение в соответствии с условиями своих лицензий.
SBOM также можно использовать для отслеживания использования программного обеспечения с открытым исходным кодом, которое становится все более распространенным в разработке программного обеспечения. Предоставляя подробную информацию о компонентах с открытым исходным кодом, используемых в пакете программного обеспечения, SBOM могут помочь организациям обеспечить соблюдение лицензий с открытым исходным кодом.
Кроме того, SBOM можно использовать для поддержки разработки и обслуживания программного обеспечения. Предоставляя подробную информацию о компонентах, используемых в пакете программного обеспечения, SBOM могут помочь разработчикам понять зависимости пакета программного обеспечения, что может помочь им выявить потенциальные проблемы совместимости и принять обоснованные решения об использовании новых компонентов.