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

SBOM – Определение

Bill of Materials (Спецификация материалов) для программного обеспечения — это формальная, структурированная запись, описывающая

• компоненты программного продукта и

• их взаимосвязи в цепочке поставок ПО.

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

Возможно, вы знакомы со спецификациями материалов по аналогии с новыми автомобилями. В этом случае это документ, подробно описывающий каждый компонент, входящий в ваш новый автомобиль. Даже если ваш автомобиль собран Toyota или General Motors, многие его детали поставляются субподрядчиками со всего мира. Спецификация материалов показывает, откуда родом каждая деталь. Это служит не только прозрачности, но и безопасности: в случае отзыва определенной серии подушек безопасности производители автомобилей должны быстро определить, где они были установлены.

Однако, поскольку сторонние библиотеки с открытым исходным кодом становятся всё более популярными для создания контейнеризированных, распределенных приложений, в разработке ПО и производстве автомобилей обнаруживается больше общего, чем можно было бы подумать. И разработчики, и пользователи могут использовать Software Bill of Materials, чтобы понять, какие составляющие вошли в ПО, как они распространялись и использовались. Это позволяет делать ряд важных выводов, особенно с точки зрения безопасности.

Software Bill of Materials – Преимущества

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

В целом, эти изменения стали благом для разработки ПО, способствуя повышению производительности разработчиков и снижению затрат. Однако с точки зрения безопасности картина не столь радужная: в значительной степени полагаясь на сторонний код (внутренние процессы которого они знают частично или не знают вовсе), разработчики создали цепочку поставок программных компонентов, столь же сложную, как и у производителей физической продукции. Поскольку приложение безопасно настолько, насколько безопасно его самое слабое звено, такая практика может привести к серьезным уязвимостям. Десятилетие 2020-х годов ознаменовалось рядом атак на цепочку поставок ПО, попавших в заголовки новостей:

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

• В конце 2021 года была обнаружена серьезная уязвимость в Apache Log4j — библиотеке Java, используемой для ведения журналов системных событий. Это звучит невинно, пока не осознаешь, что почти каждое Java-приложение в той или иной степени использует Log4j и, следовательно, становится уязвимым.

Эти кризисы безопасности подчеркивают потенциальную роль Software Bill of Materials в ландшафте безопасности. Многие пользователи, возможно, лишь мельком слышали об этих уязвимостях, но не подозревали, что используют Log4j или какой-либо другой компонент SolarWinds. С помощью SBOM вы точно знаете, какие пакеты установлены — и, главное, какие версии этих пакетов. Это позволяет своевременно обновиться и обеспечить безопасность.

Software Bill of Materials может быть полезна не только для безопасности: например, SBOM могут помочь разработчикам отслеживать лицензии на открытый исходный код своих различных программных компонентов, что важно при распространении приложений.

SBOM – Обязательность в США и скорое введение в Европе

Взлом SolarWinds, в частности, забил тревогу в правительстве США — в том числе потому, что скомпрометированный компонент использовался многими федеральными ведомствами США. Поэтому в изданном администрацией Байдена в мае 2022 года Указе о кибербезопасности содержались положения, касающиеся Software Bill of Materials. Министерство торговли США опубликовало руководство о том, какие основные элементы должны быть включены в SBOM.

Хотя это распоряжение непосредственно касается тех, кто работает с федеральными ведомствами США, правила будут иметь более широкое влияние. В конце концов, продукты, продаваемые правительству США, которые теперь должны поставляться с SBOM, в основном продаются и другим компаниям и организациям. Многие производители ПО надеются, что корпоративные клиенты также будут рассматривать SBOM как дополнительную ценность.

Кроме того, государственные закупки сами по себе являются цепочкой поставок, как подчеркивает Соунил Ю, бывший главный научный сотрудник по безопасности в Bank of America, а ныне CISO и руководитель исследований в JupiterOn: «Есть лишь ограниченное число компаний, которые работают непосредственно с правительством США и подпадают под действие постановления. Влияние на поставщиков второго уровня будет еще более значительным».

В Европе SBOM также станет обязательным — в рамках реализации Акта о киберустойчивости (Cyber Resilience Act) к концу 2027 года.

Software Bill of Materials – Структура

В ответ на Исполнительный указ Национальная администрация по телекоммуникациям и информации (NTIA) в июле 2021 года опубликовала руководство «The Minimum Elements For a Software Bill of Materials» (PDF). Этот документ может стать де-факто стандартом для SBOM во всей отрасли и определяет семь полей данных, которые должна содержать каждая SBOM:

• Имя поставщика: Наименование организации, которая создает, определяет и идентифицирует компонент.

• Имя компонента: Идентификатор, присвоенный программному компоненту, определенному первоначальным поставщиком.

• Версия компонента: Идентификатор, используемый поставщиком для обозначения изменений в ПО по сравнению с ранее идентифицированной версией.

• Другие уникальные идентификаторы: Прочая информация, используемая для идентификации компонента или служащая ключом для поиска в соответствующих базах данных. Это может быть, например, идентификатор из Словаря NIST CPE.

• Отношение зависимости: Указывает на связь, в которой компонент X вышестоящего уровня включен в ПО Y. Это особенно важно для проектов с открытым исходным кодом.

• Автор данных SBOM: Наименование субъекта, создавшего данные SBOM.

• Временная метка: Запись даты и времени составления данных SBOM.

Кроме того, SBOM должны соответствовать следующим требованиям:

• SBOM должна быть представлена в одном из трех стандартизированных форматов, чтобы быть машиночитаемой — SPDX, CycloneDX или SWID-теги.

• Новая SBOM должна генерироваться с каждой новой версией ПО, чтобы гарантировать ее актуальность.

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

Создание SBOM – как это сделать

Читая эту статью, вы можете счесть создание Software Bill of Materials пугающей задачей. Ведь сбор всей этой информации вручную, должно быть, сущий кошмар. К счастью, в большинстве случаев SBOM создаются с помощью инструментов SCA (Software Composition Analysis). Эти инструменты часто используются в конвейерах DevSecOps и играют роль не только в создании SBOM.

Инструменты SCA сканируют ваши кодовые репозитории на наличие пакетов и сравнивают их с онлайн-базами данных для сопоставления с известными библиотеками. Существуют также инструменты, которые создают Software Bill of Materials в рамках процесса сборки ПО. Фонд OWASP собрал исчерпывающий список инструментов SCA, от простых инструментов командной строки с открытым исходным кодом до специализированных коммерческих продуктов. Если вы хотите глубже погрузиться в эту тему, вам также стоит ознакомиться с нашей статьей «7 инструментов для защиты цепочки поставок ПО».

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

Хотите прочитать больше интересных материалов по IT-безопасности? Наша бесплатная новостная рассылка доставит все, что необходимо знать специалистам и экспертам по безопасности, прямо в ваш почтовый ящик.