О спецификации программного обеспечения SBOM (Software Bill Of Materials)

ФГБУ «НИИ «Интеграл»·15 Aug 2023

Спецификация программного обеспечения (SBOM) – это официальная информация о программном продукте, содержащая подробные сведения об используемых при его создании различных компонентах и цепочках поставок. Следует отметить, что основная часть современного программного обеспечения создается с использованием элементов стороннего кода и ПО с открытым исходным кодом (OSS).

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

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

Внедрение SBOM в США

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

В указе Президента США от 12 мая 2021 года №14028 «Повышение уровня национальной кибербезопасности» изложены принципы и требования, которым должны соответствовать все информационные ресурсы федеральных ведомств. В разделе 4 указаны задачи по подготовке рекомендаций, стандартов и процедур, касающихся безопасной разработки и закупки программного обеспечения. В документе SBOM определен в качестве приоритета обеспечения гарантии программного обеспечения и управления рисками в цепочке поставок.

В соответствии с указом №14028 Министерство торговли США и Национальное управление телекоммуникаций и информации разработали перечень минимального набора данных о компонентах ПО, которые разбиты на три основные категории:

Поля данных – документирование базовой информации о каждом компоненте, в том числе.

Название поставщика – наименование организации, осуществившей поставку ПО.
Название компонента.
Строка версии – сведения о сборке и версии компонента.
Взаимосвязь – описание зависимости между программными компонентами и то, какие компоненты были скомпилированы и связаны с другими компонентами.
Имя автора – наименование организации, разработавшей SBOM.
Временная метка – временя создания SBOM.

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

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

В отчете рабочей группы NTIA от 21 октября 2021 года «Обеспечение прозрачности компонентов программного обеспечения: создание общей спецификации программного обеспечения» (SBOM) расширен перечень базовых компонентов ПО, информация о которых включается в SBOM, уточнена терминология, применяемая в концепции.

В категорию «Поля данных» спецификации программного обеспечения добавлены следующие элементы:

Уникальный идентификатор – универсальный уникальный идентификатор (UUID).
Хеширование компонентов – криптографический хэш компонента, позволяющий получателю проверить (если у него есть подозрения), был ли изменен предоставленный ему двоичный файл.
Лицензирование – тип лицензии, под которой выпускается программный компонент

В «Руководстве по безопасности цепочки поставок программного обеспечения» от 9 ноября 2021 года, разработанном Национальным институтом стандартов и технологий США, указано, что SBOM должны формироваться с использованием следующих форматов, рекомендованных NTIA:

Программный пакет обмена данными (SPDX) – это открытый стандарт для создания инвентарного списка SBOM, содержащего все программные компоненты, лицензии на компоненты, авторские права и рекомендации по безопасности. В сентябре 2021 года SPDX стал международным открытым стандартом с кодом ISO/ IEC 5962:2021, присвоенным Международной организацией по стандартизации и Международной электротехнической комиссией (IEC).
CycloneDX – это упрощенный стандарт SBOM для создания полного перечня программных компонентов разработчиков и сторонних производителей. CycloneDX документирует типы компонентов, включая приложения, контейнеры, библиотеки, файлы, встроенное программное обеспечение, фреймворки и операционные системы.
Стандарт идентификации программного обеспечения (SWID) — это XMLфайл, содержащий список программных компонентов и их лицензий, статусы исправлений и установочные пакеты.

Области применения SBOM: разработка, приобретение и эксплуатация

Области применения концепции SBOM условно подразделяются на три уровня:

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

Использование инструментов SBOM

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

Finite State (США) – управляет рисками по всей цепочке поставок программного обеспечения с помощью SBOM. Он обеспечивает видимость программного обеспечения любой стороны, что позволяет специалистам по безопасности понимать свои риски и переключаться прямо на компоненты с обнаруженными уязвимостями.

Mend.io (США) – решение для гибкого управления безопасностью с открытым исходным кодом и соблюдением требований лицензий, интегрируется с конвейером DevOps для обнаружения уязвимых библиотек с открытым исходным кодом в режиме реального времени.

SOOS (США) – предназначен для создания комплексной SBOM стороннего программного обеспечения или компонентов с открытым исходным кодом.

Snyk (Великобритания) – автоматически интегрируется с рабочим процессом разработчиков и специально создан для специалистов групп безопасности, чтобы они могли работать совместно с командами разработчиков.

MergeBase (Канада) – предназначен для создания SBOM. Точно определяет и сообщает об уязвимостях в процессе сборки и развертывания с очень низким уровнем ложных срабатываний.

Scribe Security (Израиль) – комплексное решение для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающее прозрачность, контроль и доверие как для производителей ПО, так и для потребителей. Поддерживает рабочий процесс обмена SBOM между командами и организациями.

Xygeni (Испания) – решение для обеспечения безопасности цепочки поставок программного обеспечения, которое обеспечивает прозрачность, безопасность и целостность в средах DevOps.

Инструменты SBOM используют:

Разработчики программного обеспечения – для составления списка всех компонентов, которые входят в их программный продукт. Это позволяет разработчикам отслеживать версии и функционал при создании новых приложений или обновлении существующих.
Системные интеграторы – для документирования каждого элемента системы, помогая им выявлять любые отсутствующие части или дублирование функций.
Команды обеспечения качества – для тестирования перед выпуском продукта с целью определения соответствия всех компонентов установленным критериям.
Аналитики безопасности – для проверки компонентов системы на соответствие требованиям безопасности и отраслевым стандартам.
Руководители проектов – для контроля хода выполнения проекта и своевременного обеспечения совместимости всех компонентов.
Специалисты по закупкам – для исследования рынка ПО на наличие компонентов, необходимых для проектов, а также для сравнения цен и других оценок, связанных с логистикой.
Технические специалисты по обслуживанию – для устранения любых проблем, возникающих с программными продуктами, путем быстрого определения того, какие части нуждаются в замене или обновлении.
Регуляторные органы – для обеспечения соответствия программных продуктов определенным требованиям, правилам и стандартам.

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

Использование SBOM дает преимущества как поставщикам программного обеспечения, так и его потребителям. Они включают:

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

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

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

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

Распространение и обмен информацией в SBOM

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

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

При выборе организацией программного продукта и принятии решения о его покупке наличие SBOM позволяет:

проанализировать состав компонентов программного обеспечения и их взаимосвязи;
изучить компоненты ПО (даты, версии и т.д.);
понять цепочку лицензирования программного продукта.

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

Перспективы развития SBOM

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

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

Спецификация аппаратного обеспечения.
Спецификация операционной системы.
Спецификация компиляторов ПО.
Спецификация транзитивных зависимостей компонентов ПО.
Спецификация упаковщиков пакетов ПО.
Единая спецификация программного приложения.

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

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

124 views·1 share

124 views