Поиск по сайту:

Что такое SBOM и что они означают для программного обеспечения с открытым исходным кодом?

Что находится внутри коммерческого программного обеспечения и программного обеспечения с открытым исходным кодом, которое вы используете? Сколько было написано вендором и сколько стороннего кода? Можно ли доверять всему этому коду?

Угрозы реальны

Недавний всплеск громких кибератак наглядно демонстрирует косвенные последствия агрессивных киберинцидентов. Взлом SolarWinds подверг сети их клиентов угрозе компрометации со стороны киберпреступников. Атака Codecov раскрыла среды непрерывной интеграции/непрерывного развертывания их пользователей для злоумышленников.

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

Атака программы-вымогателя в мае 2021 года на Colonial Pipeline Company привела к отключению трубопровода протяженностью 5500 миль. Среди прочего очищенного топлива трубопровод обеспечивает 45% поставок бензина — 2,5 млн баррелей бензина в день — на Восточное побережье. Подача бензина просто прекратилась. Цены на заправках взлетели до небес, и начались панические закупки. Тысячи заправок были вынуждены закрыться из-за отсутствия предложения.

Атака Colonial Pipeline Company была финансово мотивирована. Это была атака программы-вымогателя, распространенная форма цифрового вымогательства. Colonial Pipeline заплатила киберпреступникам выкуп в размере 75 биткойнов — примерно 4,4 миллиона долларов, в зависимости от обменного курса — за восстановление их систем.

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

Ответ на угрозы

21 марта 2021 года президент Байден подписал указ о повышении кибербезопасности страны. В нем изложен набор стандартов и требований, которым должны соответствовать или превосходить все федеральные информационные системы.

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

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

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

Это не удивительно. Отчет о безопасности с открытым исходным кодом за 2021 год показал, что среднее количество компонентов с открытым исходным кодом в нетривиальных коммерческих проектах составляет ошеломляющие 528. Это на 259% больше, чем пять лет назад, когда в среднем на проект приходилось 84 компонента с открытым исходным кодом.

Открытый исходный код как расходный материал

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

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

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

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

Безопасность начинается со знаний. Вы должны знать, что у вас есть, чтобы убедиться, что вы это защитили. Вот почему так важны реестры ИТ-активов и реестры обработки данных. SBOM (произносится как ess-bomb) — это документ для конкретного приложения, в котором перечислены все программные элементы, из которых состоит программный продукт.

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

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

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

  • Имя поставщика: поставщик или люди, разработавшие программное обеспечение.
  • Имя компонента: имя компонента.
  • Уникальный идентификатор: универсальный уникальный идентификатор (UUID).
  • Строка версии: сведения о сборке и версии компонента.
  • Хэш компонента: криптографический хэш компонента. Это позволяет получателю проверить, если у него есть подозрения, был ли изменен предоставленный ему двоичный файл.
  • Взаимосвязь: взаимосвязь между программными компонентами описывает зависимости между компонентами и то, какие компоненты были скомпилированы и связаны с другими компонентами.
  • Лицензирование. Тип лицензии, под которой выпускается программный компонент.
  • Имя автора: автор SBOM. Это не обязательно поставщик программного обеспечения.

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

Существует несколько конкурирующих стандартов SBOM. Тремя лидерами в этой области являются обмен данными о пакетах программного обеспечения (SPDX), стандарт ISO 19770-5:2013 для идентификации программного обеспечения (SWID) и CycloneDX. Будет интересно посмотреть, примет ли один из них федеральное правительство в качестве предпочтительного стандарта.

Автоматизация может помочь

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

SBOM, вероятно, будут доступны либо для загрузки, либо как часть упакованного программного обеспечения, как файл «readme». Как только вы завладеете чужим SBOM, вам необходимо просмотреть его.

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

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

Безопасность начинается со знаний

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