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

Что такое SBOM

Идея SBOM берет начало в промышленной сфере, и на производстве Bill of Materials (BOM) используют достаточно давно. Это — подробный список сырья и готовых компонентов, необходимых для изготовления той или иной продукции, организованный по иерархическому принципу. 

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

Эта информация помогает команде разработки и поддержки принимать взвешенные решения о состоянии инфраструктуры. Например, если в популярной open source библиотеке обнаружили серьезную уязвимость и необходимо определить, насколько она опасна в рамках конкретной компании или продукта. Представим на секунду, что ИТ-специалисту, который работает в крупной поликлинике, стало известно о критическом баге в библиотеке Java Spring. Ему необходимо понять, какое оборудование потенциально уязвимо. Взять, к примеру, аппарат МРТ: какая в нем операционная система? Использует ли он Java Spring и уязвимый компонент? Спецификация SBOM помогает быстро ответить на эти вопросы.

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

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

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

Разные стандарты: SPDX, CycloneDX и другие

Существует множество стандартов SBOM. Рассмотрим, как они появились и для чего используются.

Первый — Software Package Data Exchange (SPDX), который развивается под эгидой Linux Foundation. 

Cообщество открытого исходного кода заметило необходимость создания SBOM более 10 лет назад. В 2010 году в качестве первоначальной попытки решить эту проблему был запущен открытый стандарт SPDX. 

Изначально стандарт разработали для отслеживания используемых в открытом ПО лицензий, но со временем в него добавили требования к описанию уязвимостей и зависимостей от стороннего кода. В 2021 году SPDX признали международным стандартом для документирования метаданных о пакетах ПО (ISO/IEC 5692:2021).

SPDX состоит из трех элементов: спецификации, перечня лицензий (SPDX License List) с руководством для их идентификации, а также библиотек для работы с этими двумя компонентами. Самый простой вариант написать спецификацию по SPDX — заполнить ее вручную в специальном файле со стандартизированными полями. Также для этого можно использовать автоматизированные инструменты, например, для пакетов на Golang, Java, Python. SPDX позволяет представить метаданные в формате JSON, YAML, RDF/XML.

Второй распространенный стандарт — CycloneDX. Его разработали в OWASP (открытый проект обеспечения безопасности веб-приложений) для применения в Dependency-Track — платформе для анализа сторонних программных компонентов. 

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

Свои форматы SBOM запускают крупные игроки в сообществе открытого программного обеспечения. Помимо подхода GitHub один из актуальных стандартов представили для Kubernetes. Его разработала команда Kubernetes Security Operations Center (KSOC).

Kubernetes Bill of Materials (KBOM) предоставляет данные о количестве рабочих нагрузок в кластере, стоимости и типе хостинга, уязвимостях образов, сторонних инструментах и версиях различных компонентов. По умолчанию спецификацию KBOM можно написать в формате JSON — она подойдет для любых кластеров, в том числе развернутых у крупных облачных провайдеров.

Как использовать SBOM

Погрузиться в работу со SBOM может практически любая организация. Как видно, для стандартов вроде SPDX достаточно заполнить таблицу. Хотя такой подход едва ли годится для крупных проектов с большим числом зависимостей, пакетов и программных библиотек, не говоря уже о целых облачных инфраструктурах. Здесь на помощь приходят специальные генераторы. Например, Syft, который формирует спецификацию на основе образов контейнеров. Еще есть SwiftBOM — он поддерживает форматы SPDX, CycloneDX and SWID. Некоторые крупные игроки разрабатывают собственные генераторы, например, в прошлом году такой проект представила и передала в open source компания Microsoft.

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

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

Хотя стоит отметить, что вопросы стандартизации уже пытаются решить. Разработаны списки рекомендаций по составлению SBOM с целью унификации процесса. Однако остается решить вопрос надежности самих SBOM-генераторов. Специалисты по ИБ отмечают, что в теории хакеры могут провести атаку и подделать информацию в спецификации, чтобы скрыть уязвимость или вредоносный код, но в теории снизить такие риски могут цифровые подписи.

Как еще защищать ПО

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

У нас есть Security Operation Center (SOC) для комплексной защиты всех ресурсов клиентов. SOC мониторит и реагирует как на факты первоначальной компрометации системы, так и на дальнейшие попытки злоумышленника закрепиться в ней, повысить привилегии и развить атаку на хосты уже внутри корпоративной сети.

На базе Web Application Firewall (WAF) мы реализовали облачный сервис под ключ, который содержит набор инструментов, связанных с конфигурированием, эксплуатацией WAF, мониторингом и реагированием на инциденты, — WAF Premium. Команда CloudMTS берет на себя тонкую настройку защиты, выявляет ложные срабатывания механизмов защиты и реагирует на инциденты взлома в режиме 24/7.

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