Что такое спецификация программного обеспечения (SBOM)?

SBOM в цепочке поставок программного обеспечения: уроки, извлеченные из бэкдора XZ Utils

Случай с бэкдором XZ ​​Utils, обозначенный как CVE-2024-3094, включал вредоносный бэкдор, встроенный в широко используемую утилиту Linux. Эта уязвимость была обнаружена Андресом Фройндом непосредственно перед ее интеграцией в основные дистрибутивы Linux, подвергая риску миллионы серверов. Исследователь обнаружил эту уязвимость до того, как она была запущена в производство, что предотвратило какой-либо реальный вред. Хотя SBOM не сыграли роли в этом конкретном случае, они были бы решающими, если бы уязвимость стала широко распространенной, как это было с Log4j в 2021 году. В случае широко распространенной уязвимости, такой как Log4j, платформы SBOM могли бы эффективно помочь в понимании радиуса взрыва. и проведение анализа воздействия. Если бы уязвимость XZ Utils была обнаружена, такие инструменты, как Scribe Hub, могли бы сыграть важную роль в оповещении компаний, позволяя им выполнять поиск в своем программном обеспечении, блокировать развертывание скомпрометированных версий и повышать общий уровень безопасности.

Определение спецификации программного обеспечения

В спецификации программного обеспечения (SBOM) перечислены все компонентные части и зависимости программного обеспечения, участвующие в разработке и доставке приложения. SBOM аналогичны спецификациям материалов (BOM), используемым в цепочках поставок и производстве. У всех поставщиков ИТ-индустрии не было общей функции, позволяющей точно описать основные компоненты кода, на которых построено приложение.

Типичный SBOM будет включать информацию о лицензировании, номера версий, сведения о компонентах и ​​поставщиках. Формальный список всех фактов снижает риски как для производителя, так и для пользователя, позволяя другим понять, что находится в их программном обеспечении, и действовать соответствующим образом. SBOM не являются чем-то новым для индустрии программного обеспечения, но они становятся все более важными по мере того, как разработка становится все более сложной и дорогой. В последнее время они стали основным требованием во многих компаниях.

Защита облачных приложений: возможности расширенных SBOM

Рост количества облачных приложений усложнил защиту современных программных сред. Эти приложения, характеризующиеся своей динамичной и распределенной природой, состоят из взаимосвязанных микросервисов и внешних компонентов, что увеличивает поверхность атаки. В этом контексте критически важным становится улучшение SBOM, поскольку они обеспечивают детальную видимость всех компонентов и зависимостей внутри облачной архитектуры. Эффективный SBOM помогает выявлять уязвимости, обеспечивает соответствие стандартам безопасности и способствует быстрому реагированию на инциденты. Используя надежные SBOM, организации могут вести полную инвентаризацию своих программных активов, отслеживать изменения и заранее обнаруживать потенциальные угрозы безопасности. В эпоху облачных приложений совершенствование методов SBOM необходимо для повышения безопасности и поддержания целостности сложных программных экосистем.

Преимущества СБОМ

Борьба с угрозами целостности

Нападения могут произойти в любой точке обычной цепочки поставок программного обеспечения, и в современном мире эти атаки становятся все более заметными, разрушительными и дорогостоящими. Целостность можно поддерживать с помощью SBOM, проверяя, что компоненты и файлы, которые появляются в нем, такие же, как и предполагалось. Например, одним из компонентов формата CycloneDX является хэш-значение, которое можно использовать при точном сопоставлении файлов и компонентов. Поскольку SBOM не является статичным документом, его следует обновлять каждый раз при изменении описываемого программного обеспечения или его компонентов.

Обеспечивает видимость компонентов продукта

Компании должны создавать доверие клиентов, чтобы генерировать лояльность и способствовать повторным покупкам. Вместо заверений и обещаний общие SBOM обеспечивают улучшенную видимость качества используемых ими технологий.

Позволяет упростить сканирование уязвимостей

Компании могут использовать SBOM для выявления и устранения уязвимостей до того, как они попадут в производство. Новые уязвимости в производственном программном обеспечении можно быстро устранить. В конечном итоге SBOM помогают инженерам быстрее обнаруживать и устранять недостатки безопасности.

Использование управления лицензированием вашего продукта

Внедрение спецификации программного обеспечения может помочь улучшить управление лицензированием программного обеспечения. Каждая часть программного обеспечения поставляется с лицензией, которая определяет, как ее можно использовать и распространять на законных основаниях. Составляющие компоненты цепочки поставок, составляющие полное приложение, могут иметь множество различных лицензий. Любой бизнес, использующий программу, по закону обязан следовать условиям лицензирования. Без спецификации программного обеспечения может оказаться невозможным определить, что требуется для лицензий или как их соблюдать.

Принципы хорошо сформированной SBOM

Минимальные компоненты правильно сформированного SBOM разделены на три категории:

Поля данных

Цель этих полей — обеспечить адекватную идентификацию этих компонентов. Это позволяет вам отслеживать их по цепочке поставок программного обеспечения и связывать их с другими полезными источниками данных, такими как базы данных уязвимостей или лицензий. Некоторыми примерами полей данных являются имя поставщика, имя компонента, версия компонента, другие уникальные идентификаторы, отношения зависимости, автор данных SBOM и временная метка.

Поддержка автоматизации

Организации, которые хотят внимательно следить за данными компонентов SBOM, потребуют, чтобы они были представлены в единообразном и понятном стиле. Это рассматривается в разделе основных требований SBOM в разделе «Поддержка автоматизации». При отправке SBOM через границы организации можно выбрать один из трех стандартов:

1. Программный пакет обмена данными (SPDX)
2. ЦиклонDX
3. Теги идентификации программного обеспечения (SWID)

Подробнее они обсуждаются чуть позже в этой статье.

Практики и процессы

Наконец, в разделе «Практика и процессы» излагаются шесть стандартов того, как и когда следует обновлять и предоставлять SBOM. Они заключаются в следующем:

• Если программный компонент обновляется новой сборкой или выпуском, необходимо создать новые SBOM.
• Авторы SBOM должны включать компоненты верхнего уровня, а также их транзитивные зависимости.
• Если SBOM не предлагает полного дерева зависимостей, автор SBOM должен объяснить, происходит ли это потому, что (а) компонент больше не имеет зависимостей или (б) существование зависимостей неизвестно и неполно.
• SBOM должны распространяться и доставляться «своевременно», с «соответствующими правами доступа и ролями».
• Компании, которые хотят сохранить в секрете некоторые компоненты SBOM, должны указать параметры контроля доступа, которые будут содержать конкретные правила и процедуры для включения информации, связанной с SBOM, в руководство пользователя и инструменты. Проще говоря: если есть что-то, что необходимо хранить в секрете ради организации, то в этом разделе определяется процесс сохранения этого в секрете. 
• Поскольку стандарты, управляющие созданием SBOM, являются новыми, пользователям SBOM рекомендуется прощать (непреднамеренные) ошибки или упущения.

Различные форматы SBOM

Конечно, вы можете вручную составить счет SBOM, перечислив множество компонентов созданного вами программного обеспечения. Однако поддержка огромных баз кода с десятками или даже сотнями зависимостей и сторонних компонентов — утомительная и трудоемкая задача, особенно для разработчиков, которые управляют большими базами кода с множеством сторонних компонентов и зависимостей. Некоторые разработчики могли включать в приложение сторонние компоненты, не документируя это. В результате нынешние разработчики могут не быть знакомы со всей кодовой базой.

Чтобы внедрение стало реальностью, SBOM должны придерживаться принятых в отрасли стандартов, которые обеспечивают совместимость между различными секторами и организациями. Благодаря нескольким стандартам организации уже имеют архитектуру для разработки, управления и распространения данных о компонентах программного обеспечения.

SPDX: обмен данными программного пакета

Команда Программный пакет обмена данными (SPDX) — это основной открытый стандарт для форматов спецификаций программного обеспечения, разработанный Linux Foundation в 2010 году. Компоненты программного обеспечения, авторские права, лицензии и ссылки на безопасность включены в файлы SPDX. Спецификация SPDX совместима с предложенными NTIA. Минимальные стандарты SBOM и варианты использования. Организации могут использовать SPDX Lite для обмена данными, поскольку это сокращенная версия стандарта SPDX. SPDX получил официальный стандарт ISO/IEC 5962 в августе 2021 года.

SPDX-документ

SWID: маркировка идентификации программного обеспечения

Команда Международная организация по стандартизации (ISO) еще до конца десятилетия начала устанавливать стандарт для маркировки компонентов программного обеспечения машиночитаемыми идентификаторами. Теги SWID, как они теперь известны, представляют собой структурированные встроенные метаданные в программное обеспечение, которые передают такую ​​информацию, как название программного продукта, версия, разработчики, взаимоотношения и многое другое. Теги SWID могут помочь в автоматизации управления исправлениями, проверке целостности программного обеспечения, обнаружении уязвимостей, а также разрешении или запрете установки программного обеспечения, аналогично управлению активами программного обеспечения. В 2012 году был подтвержден стандарт ISO/IEC 19770-2, который был изменен в 2015 году. Существует четыре основных типа тегов SWID, которые используются на различных этапах жизненного цикла разработки программного обеспечения:

1. Теги корпуса: Они используются для идентификации и характеристики компонентов программного обеспечения, которые не готовы к установке. По данным Национального института стандартов и технологий, теги корпуса «предназначены для использования в качестве входных данных для инструментов и процедур установки программного обеспечения».
2. Основные теги: Цель основного тега — идентифицировать и контекстуализировать элементы программного обеспечения после их установки.
3. Теги патча: Теги патчей идентифицируют и описывают патч (в отличие от самого основного продукта). Теги патчей также могут включать в себя контекстную информацию об отношении патча к другим товарам или патчам, что часто и происходит.
4. Дополнительные теги: Дополнительные теги позволяют пользователям программного обеспечения и инструментам управления программным обеспечением добавлять полезную контекстную информацию о локальных утилитах, такую ​​как лицензионные ключи и контактную информацию для соответствующих сторон.

Когда дело доходит до определения того, какие теги и точные данные предлагать в своих продуктах, компании имеют значительную свободу действий. Помимо обязательных данных, стандарт SWID определяет ряд дополнительных компонентов и характеристик. Наконец, для базового действительного и совместимого тега требуется всего лишь несколько характеристик, характеризующих программный продукт (например, имя и идентификатор тега) и организацию, которая его создала.

ЦиклонDX

В 2017 году Фонд OWASP выпустил ЦиклонDX как часть Dependency-Track, инструмента анализа программных компонентов с открытым исходным кодом. CycloneDX — это облегченный стандарт для многоотраслевого использования, включающий такие варианты использования, как обнаружение уязвимостей, соблюдение требований лицензирования и оценка старых компонентов. CycloneDX 1.4 был запущен в январе 2022 года. Cyclone DX может обрабатывать четыре различных типа данных:

• Метаданные технологической схемы материалов: Он содержит информацию о самом приложении/продукте, такую ​​как поставщик, производитель и компоненты, описанные в SBOM, а также любые инструменты, используемые для создания SBOM.
• Компоненты: Это полный список как собственных, так и открытых компонентов, а также информация о лицензиях.
• Сервисы: URI конечных точек, требования аутентификации и обход границ доверия — все это примеры внешних API, которые может использовать программное обеспечение.
• зависимости: включают как прямые, так и косвенные связи.

Источник: ЦиклонDX

Как выглядит SBOM?

Для выявления рисков требуется тщательная и точная инвентаризация всех компонентов собственных и сторонних производителей. Все прямые и переходные компоненты, а также зависимости между ними должны быть включены в спецификации. Например, с помощью CycloneDX можно описать следующие типы компонентов:

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "version": 1, "comComponents": [ { " тип": "библиотека", "имя": "nacl-library", "версия": "1.0.0" } ] }

Формат XML:

 nacl-библиотека 1.0

Зачем подписывать свой SBOM?

Что такое цифровая подпись?

A цифровой подписи звучит именно так: электронная версия традиционной подписи на бумаге и ручке. Он проверяет достоверность и целостность цифровых сообщений и документов, используя сложный математический подход. Это гарантирует, что содержимое сообщения не будет изменено во время передачи, помогая нам преодолеть проблему выдачи себя за другое лицо и фальсификации в цифровых коммуникациях. Цифровые подписи со временем получили все большее распространение и являются криптографическим стандартом. 

Как работают цифровые подписи

Цифровые подписи создаются с использованием криптографии с открытым ключом, также известной как асимметричная криптография. Подход с открытым ключом, такой как ЮАР (Ривест-Шамир-Адлеман) генерирует два ключа, один частный и один открытый, что приводит к математически связанной паре ключей. Одним из основных механизмов цифровых подписей является хеширование. Он эффективно преобразует данные в выходные данные фиксированного размера независимо от размера входных данных. Это делается с помощью хэш-функций, которые по сути являются алгоритмами, а результат, который они производят, называется хэш-значением. Криптографические хеш-функции генерируют хэш-значение, которое действует как цифровой отпечаток пальца, что делает его уникальным для всех. Подобно тому, как отпечатки пальцев у всех разные, разные входные сообщения будут генерировать разные значения хеш-функции. Два взаимно аутентифицирующих криптографических ключа шифрования с открытым ключом (PKC) в основном используются для цифровых подписей. Создатель цифровой подписи использует закрытый ключ для шифрования данных, связанных с подписью, и эти данные могут быть декодированы только с использованием открытого ключа подписавшего. Таким образом получатель узнает, что отправитель не скомпрометирован и полученные данные верны. В настоящее время работа с инфраструктурой открытых ключей является дорогостоящей и сложной, поскольку люди часто потерять свои секретные ключи как будто кто-то потеряет свои физические ключи. Центры сертификации (ЦС) действуют как доверенные третьи стороны и выдают цифровые подписи, принимая, проверяя, выдавая и поддерживая цифровые сертификаты. Центры сертификации помогают предотвратить создание поддельных цифровых сертификатов. Это также подтверждает поставщик доверенных услуг (TSP). TSP — это физическое или юридическое лицо, которое проверяет цифровые подписи от имени компании и сообщает результаты проверки.

Преимущества SBOM с цифровой подписью

Подписанный SBOM предоставляет контрольную сумму, которая представляет собой длинную строку букв и цифр, которая представляет собой сумму точных цифр части цифровых данных и может сравниваться для обнаружения неисправностей или изменений. Контрольная сумма аналогична цифровому отпечатку пальца. На регулярной основе он проверяет избыточность (CRC). Изменения необработанных данных в цифровых сетях и устройствах хранения обнаруживаются с помощью кода обнаружения ошибок и функции проверки. Поскольку цифровая подпись призвана служить проверенным и безопасным способом подтверждения подлинности транзакций (то есть после подписания человек не может требовать иного), она обязывает всех подписавших соблюдать процедуры и действия, изложенные в законопроекте. 

Проблемы с неподписанным SBOM

Поскольку одной из основных целей цифровых подписей является проверка, неподписанный SBOM не подлежит проверке. Думайте об этом как о контракте: если контракт не подписан участвующими сторонами, нет реального способа обеспечить его соблюдение. Точно так же неподписанный SBOM — это просто неподписанный документ: ваш клиент не может привлечь вас к ответственности.  Это также может привести к дальнейшим проблемам в будущем, поскольку неподписанный SBOM также может представлять угрозу для безопасности вашей организации. Все, что в противном случае могло быть защищено подписанным SBOM, теперь не защищено, и поэтому данные и информацию можно отправлять или реплицировать где угодно. Одна из основных целей подписанных SBOM – подотчетность – теряется, когда SBOM не подписан, поскольку затем в него можно вносить изменения без последствий со стороны создателя или клиента. 

Использование SBOM для повышения кибербезопасности

SBOM — один из лучших способов для организаций обеспечить безопасность и подлинность своих данных и процедур. Они также создали прецедент в отрасли, повысив открытость между разработчиками, поставщиками программного обеспечения и клиентами. Организации могут безопасно сообщать партнерам операционные подробности на протяжении всего процесса заключения контракта, если существуют стандарты. Организации будут более успешны в выявлении недостатков, уязвимостей и угроз нулевого дня по мере того, как SBOM станут более распространенными. Внедрение спецификации программного обеспечения является очевидным преимуществом для безопасности цепочки поставок программного обеспечения во всем мире.

Использование VEX для повышения удобства использования вашего SBOM

Vulnerability Exploitability eXchange (VEX) — это рекомендации по безопасности, направленные на раскрытие возможности использования уязвимостей в контексте продукта, в котором они обнаружены. При запуске сканирования уязвимостей в большинстве современных приложений результаты могут легко составлять сотни или тысячи уязвимостей. Из общего числа обнаруженных уязвимостей только около 5% действительно пригодны для эксплуатации. Также важно помнить, что возможность использования уязвимостей почти никогда не является отдельной проблемой. Чаще всего именно сложный вариант использования библиотек, модулей и кода с открытым исходным кодом, работающего вместе, превращает уязвимость в проблему, которую можно использовать. Пока вы не измените свое приложение и не запустите новую SBOM для его описания, инвентаризация, описанная в спецификации, обычно останется статичной. Информация об уязвимостях гораздо более динамична и подвержена изменениям. Наличие вашей информации VEX в виде отдельного списка позволяет обновлять данные VEX без необходимости создавать дополнительные спецификации и управлять ими. CISA предоставляет список рекомендуемый минимум элементов данных это должно быть включено в полезную рекомендацию или документ VEX. Это:

Метаданные VEX: Идентификатор формата VEX, строка идентификатора для документа VEX, автор, роль автора, временная метка. 

информация о продукте: Идентификатор(ы) продукта или идентификатор семейства продуктов (например, уникальный идентификатор или комбинация имени Поставщика, названия продукта и строки версии, как указано в установленных руководствах SBOM3). 

Сведения об уязвимости: Идентификатор уязвимости (CVE или другие идентификаторы) и описание уязвимости (например, описание CVE). 

Статус изделия Подробнее (т. е. информация о статусе уязвимости в этом продукте): 

• НЕ ЗАТРУДНЕНО — исправление этой уязвимости не требуется.
• ЗАТРУДНЕНО — рекомендуется предпринять действия по устранению или устранению этой уязвимости.
• ИСПРАВЛЕНО. Эти версии продукта содержат исправление уязвимости. 
• В РАССЛЕДОВАНИИ – пока неизвестно, подвержены ли эти версии продукта уязвимости. Обновление будет предоставлено в более поздней версии.

Преодоление проблем внедрения SBOM

Включение SBOM в жизненный цикл разработки программного обеспечения организации (SDLC) сопряжено с рядом проблем. Во-первых, создание и поддержание точных SBOM может занять много времени и денег, требуя значительных инвестиций в инструменты и процессы. Проблемы SBOM также включают интеграцию управления SBOM с существующими конвейерами CI/CD, что может включать оптимизацию интеграции конвейеров CI/CD. Кроме того, обеспечение полноты и точности SBOM требует тщательного отслеживания всех компонентов программного обеспечения, включая сторонние зависимости. Еще одним серьезным препятствием является формирование культуры прозрачности и осведомленности о безопасности среди команд разработчиков, что имеет решающее значение для успешного внедрения практик SBOM. Преодоление этих проблем SBOM требует стратегического подхода, сочетающего надежные инструменты, эффективное обучение и твердую организационную приверженность повышению безопасности цепочки поставок программного обеспечения.

Резюме

В заключение, хотя SBOM по-прежнему являются новой идеей для большинства организаций, ожидается, что способность создавать SBOM станет более значимой в будущем. Если вы еще не начали включать создание SBOM в процесс поставки программного обеспечения, сейчас отличный момент для этого.