Создание безопасных программных продуктов или приложений в наш век требует полного знания точных компонентов приложения, которое вы создаете. Зависимости, лицензии, файлы и другие активы, составляющие ваш программный пакет, являются потенциальными точками уязвимости, через которые злоумышленники могут начать атаку на ваше программное обеспечение и другие приложения на всех этапах цепочки поставок.
В рамках усилий по борьбе с недавним увеличением частоты и воздействия атаки на цепочки поставок программного обеспеченияФедеральное правительство в координации с NTIA издало распоряжение, в котором подробно описаны различные меры по улучшению кибербезопасности и гарантии целостности сторонних компонентов, используемых в пакетах программного обеспечения. Одной из таких мер является Спецификация программного обеспечения.
Это формальный документ, содержащий все компоненты пакета программного обеспечения и взаимоотношения в цепочке поставок между этими компонентами. Подготовка подробной спецификации программного обеспечения — это не просто стандартная практика, это также требуется по закону. В этом посте определяется объем Спецификации программного обеспечения и минимальные элементы это должно быть включено в полную спецификацию материалов.
Что обеспечивают минимальные компоненты SBOM, предусмотренные NTIA?
SBOM служит формальным руководством для компаний, которые создают, приобретают или эксплуатируют программное обеспечение, предоставляя всю информацию, необходимую им для улучшения понимания цепочки поставок программного обеспечения. Это также помогает легко отслеживать возникающие уязвимости в случае их возникновения. снизить риски в цепочке поставок программного обеспечения. Однако для того, чтобы SBOM отвечал установленным требованиям федерального правительства, он должен содержать некоторые основные элементы. Эти элементы часто подразделяют на три категории:
- Поля данных: Ожидается, что SBOM предоставит важные данные о компонентах программного обеспечения, такие как имя компонента, имя поставщика, версию программного обеспечения и другие уникальные идентификаторы. Также следует детализировать отношения между зависимостями. Эти данные позволяют точно идентифицировать все компоненты программного обеспечения и отслеживать их по всей цепочке поставок программного обеспечения.
- Поддержка автоматизации: Спецификация программного обеспечения должна быть машиночитаемой, а также иметь возможность автоматического создания. Это позволяет непрерывно отслеживать данные, включенные в SBOM. Обычно эти документы имеют стандартные форматы, такие как теги SPDX, CycloneDX и SWID, что также делает их удобочитаемыми для человека.
- Практики и процессы: Ожидается, что в документации SBOM также будут подробно описаны стандартные методы и процессы подготовки и обновления SBOM. Он также должен включать методы распространения и доступа к SBOM, а также меры по устранению случайных ошибок.
Минимальные необходимые элементы документации SBOM, установленные NTIA, обеспечивают четкий критерий того, что ожидается в руководстве SBOM для основных случаев использования вашей спецификации программного обеспечения, таких как управление уязвимостями, инвентаризация компонентов программного обеспечения и управление лицензиями на программное обеспечение. Структура обновляется и в ближайшем будущем может включать дополнительные элементы, расширяющие ее удобство использования. В последующих разделах этой страницы мы более подробно объясним эти ключевые компоненты вашей спецификации программного обеспечения. Минимально необходимые элементы спецификации программного обеспечения включают семь полей данных, как указано ниже.
Поля данных: минимальные требования
Цель спецификации программного обеспечения — предоставить информацию, которая поможет пользователям и другим заинтересованным сторонам легко идентифицировать компоненты программного обеспечения. Ожидается, что одним из первых и наиболее важных элементов SBOM являются данные, которые должны быть включены для каждого компонента, подробно описанного в документе. Помимо помощи в идентификации отдельных компонентов, данные также облегчают отслеживание компонентов в различных местах их использования в цепочке поставок программного обеспечения.
- Наименование поставщика: Поставщик является создателем или производителем рассматриваемого программного компонента. Это имя человека или организации, которая создает, определяет и идентифицирует компоненты программного обеспечения.
- Название компонента: Это относится к обозначенному имени, присвоенному программному обеспечению, определенному первоначальным поставщиком или производителем. В случаях, когда у программного обеспечения имеется несколько имен и псевдонимов, их также можно отметить.
- Версия компонента: SBOM должен включать номер выпуска или номер категории, указанный поставщиком или производителем. Данные о версии служат идентификатором, указывающим любое изменение в программном обеспечении по сравнению с ранее идентифицированной версией последующего выпуска программного обеспечения.
- Другие уникальные идентификаторы: Это относится к дополнительным идентификаторам, отличным от имени и версии компонента. Эти дополнительные идентификаторы обеспечивают дополнительный уровень идентификации компонента, а также могут использоваться в качестве ключа поиска для поиска компонента в соответствующих базах данных.
- Отношения зависимости: Это один из наиболее важных компонентов данных в спецификации программного обеспечения, поскольку SBOM предназначен для подробного описания того, как компоненты программного обеспечения сочетаются друг с другом. Отношения зависимости определяют отношения между программным обеспечением X, используемым в вашем приложении, и его вышестоящими компонентами.
- Автор данных СБОМ: Это относится к лицу, создавшему данные SBOM. Иногда поставщик программного обеспечения может также выступать в роли автора. Однако во многих случаях автором является другое лицо или группа.
Поддержка автоматизации: минимальные требования
Использование спецификации программного обеспечения часто выходит за рамки организации. Это означает, что данные, содержащиеся в SBOM, часто используются несколькими отделами внутри организации, а также несколькими организациями. Чтобы обеспечить простоту использования этой документации, NTIA рекомендует, чтобы SBOM был в формате, читаемом как машиной, так и человеком. Подготовка и передача SBOM в таких стандартных автоматизированных форматах улучшает совместимость этого документа для различных целей.
NTIA признает три формата доставки для создания и передачи SBOM. Ваша спецификация программного обеспечения должна соответствовать любому из этих форматов, чтобы соответствовать стандартам, установленным постановление правительства по кибербезопасности. Эти стандартные форматы включают в себя:
- Программный пакет обмена данными (SPDX)
- Теги идентификации программного обеспечения (SWID)
- ЦиклонDX
Программный пакет обмена данными (SPDX)
SPDX — это открытый стандарт доставки данных SBOM. Он собирает важную информацию о программном обеспечении, включая его компоненты, происхождение, лицензии и авторские права. Он также предоставляет ссылки на безопасность. СПДКС версия 2.2 является самой последней версией и поддерживает тип файлов YAML 1.2, нотацию объектов JavaScript и структуру описания ресурсов (RDF/XML). тег: текстовый файл значений и электронные таблицы .xls
Теги идентификации программного обеспечения (SWID)
Теги SWID предназначены для идентификации и контекстуализации компонентов любого программного продукта. Проект тегов идентификации программного обеспечения (SWID Tags) представляет собой набор инструментов для создания и проверки идентификационных тегов части программного обеспечения. Эти инструменты на основе Java поддерживают теги XML SWID на основе стандартизированного формата, определенного стандартом ISO/IEC 19770-2:2015, и краткое представление двоичных объектов (CBOR). У НИСТ есть сайт со списком полезных ресурсов для:
- Создание тегов SWID и CoSWID
- Проверка тегов SWID и CoSWID на основе конкретных требований к схеме и рекомендаций по передовой практике.
- Веб-приложение, предоставляющее службу проверки тегов SWID, которую можно развернуть на сервере приложений Java.
- Клиент репозитория SWID для публикации тегов в Национальной базе данных уязвимостей
ЦиклонDX
ЦиклонDX утверждает, что является «облегченным стандартом спецификации программного обеспечения (SBOM)». Это полезно для анализа компонентов цепочки поставок и обеспечения безопасности приложений. Организации, которые внедряют CycloneDX, могут легко удовлетворить минимальные требования SBOM и со временем перейти к более сложным вариантам использования документации SBOM.
SBOM CycloneDX обычно представлены в форматах XML, JSON или буферов протокола. Спецификация часто включает в себя следующие пять полей:
- Метаданные спецификации: сюда входит общая информация о самом приложении или программном продукте.
- Компоненты: это комплексный перечень, охватывающий все проприетарные компоненты программного обеспечения и компоненты с открытым исходным кодом.
- Информация об услугах: здесь подробно описаны все внешние API, которые приложение может вызывать во время своей работы. Он включает в себя все URL-адреса конечных точек, требования к аутентификации и обход границ доверия.
- Зависимости: В документации также подробно описаны все компоненты и службы пакета программного обеспечения. Сюда входят как прямые, так и транзитивные отношения.
- Композиции: это относится к полноте всех составных частей, включая отдельные компоненты, услуги и отношения зависимости. Каждая композиция обычно описывается с точки зрения того, являются ли они полными, неполными, неполными только собственными, неполными только сторонними или полностью неизвестными.
Практики и процессы: минимальные требования
Последний элемент спецификации программного обеспечения посвящен механике самого использования SBOM. Практики и процессы охватывают оперативные детали создания и использования SBOM и должны быть включены в любую политику или контракт, который требует этого. Ниже приведены ключевые требования, которые должны быть подробно описаны в разделе «Практика и процессы» спецификации программного обеспечения:
- Частота: В этом разделе подробно описано, как часто организации приходится составлять новый счет на программное обеспечение для материалов. Как правило, NTIA рекомендует создавать новый SBOM каждый раз при обновлении вашего программного компонента или выпуске новой версии. Также ожидается, что поставщики будут создавать новые SBOM всякий раз, когда они обнаруживают ошибку в исходной версии или узнают новые подробности о компонентах своего программного обеспечения, которые не были включены в исходную документацию.
- Глубина: Глубина вашего SBOM зависит от того, что включено в документ. Ожидается, что для обеспечения соответствия вашему SBOM будут включены все компоненты верхнего уровня и все транзитивные зависимости. В ситуациях, когда автор не может включить все транзитивные зависимости, документ должен указывать потребителю, где они могут их найти.
- Бывают случаи, когда автор SBOM по той или иной причине не может предоставить полный граф зависимостей. Это может быть связано с тем, что у компонента нет дальнейших зависимостей или они не знают, существуют эти зависимости или нет. Автор СБОМ обязан указать эту причину.
- Распространение и доставка: Цель этого требования — обеспечить быструю доставку SBOM в легко усваиваемом формате. Хотя это требование не определяет количество дней или недель, в течение которых SBOM должны быть доставлены, их следует сдать как можно быстрее. Кроме того, при доставке SBOM должны иметь соответствующие роли и права доступа. Наконец, требование предусматривает, что SBOM может либо распространяться вместе с каждым экземпляром продукта, либо быть доступен любым другим легкодоступным способом, например, через общедоступный веб-сайт.
- Контроль доступа: В случаях, когда поставщик решает ограничить доступ к данным СБОМ конкретным пользователям или заказчикам, автор обязан указать условия контроля доступа. Также необходимо предложить специальные возможности для потребителей, которые хотели бы интегрировать данные SBOM в свои собственные инструменты безопасности.
- Размещение ошибок: SBOM может помочь улучшить гарантию программного обеспечения и управление рисками в цепочке поставок программного обеспечения. Однако он еще далек от совершенства. Таким образом, потребители должны быть терпимы к случайным непреднамеренным ошибкам или упущениям, которые могут возникнуть при подготовке SBOM.
Не ограничиваясь минимальными требованиями NTIA
До сих пор мы обсуждали минимальные элементы, которые требуются в вашей спецификации программного обеспечения. Эти минимальные элементы представляют собой рекомендуемые требования, особенно для самых основных случаев использования этой документации. Хотя они закладывают хорошую основу для происхождения и безопасности программного обеспечения, необходимо выходить за рамки этих требований. Ниже приведены некоторые рекомендации, которые следует учитывать для более сложных случаев использования SBOM.
Дополнительные поля данных
В дополнение к полям данных, описанным в документе с минимальными требованиями, существуют дополнительные поля данных, которые рекомендуются в случаях, когда необходим более высокий уровень безопасности. Некоторые из этих дополнительных полей данных включают в себя:
- Криптографический хэш компонентов программного обеспечения.
- Данные об этапах жизненного цикла программного обеспечения
- Отношения между другими компонентами
- Информация о лицензии
Облачное программное обеспечение и программное обеспечение как услуга
Другая потенциальная область, где требования SBOM могут выходить за рамки базовых, — это управление продуктами «программное обеспечение как услуга» (SaaS). Эти типы программных продуктов имеют уникальные проблемы с данными SBOM. Начнем с того, что риски безопасности в контексте облака уникальны. Кроме того, ответственность за управление этими рисками лежит на поставщике услуг. Подготовка документации SBOM для облачного программного обеспечения также более сложна, поскольку они, как правило, имеют более короткий цикл выпуска.
Целостность и подлинность SBOM
Еще одна вероятная проблема, на которую стоит обратить внимание, — это процесс аутентификации самого источника данных SBOM. В настоящее время подписи и инфраструктура открытых ключей являются основными решениями для проверки целостности программного обеспечения в современном цифровом мире. Авторам и поставщикам SBOM может потребоваться использовать существующие сигнатуры программного обеспечения для повышения надежности данных SBOM.
Уязвимость и возможность использования в зависимостях
Хотя цель SBOM — облегчить обнаружение уязвимостей, важно отметить, что не все уязвимости в зависимостях представляют собой серьезный риск для программного обеспечения, которое на них опирается. Чтобы избежать напрасной траты времени и ресурсов, поставщикам программного обеспечения необходимо будет принять меры для определения потенциального воздействия уязвимости зависимостей на программное обеспечение, которое использует последующие версии, и сообщить об уровне риска (или его отсутствии в данном случае) пользователям SBOM. данные ниже по течению.
Гибкость против единообразия в реализации
Всякий раз, когда обсуждается безопасность программного обеспечения, на передний план всегда выходит вопрос гибкости и единообразия. Это относится и к расширенным вариантам использования SBOM. Для успешной реализации SBOM потребуется общая политика, применимая ко всем областям, а также к конкретным случаям, когда потребуется гибкость.