Современные пакеты программного обеспечения более безопасны, чем когда-либо, благодаря достижениям в области кибербезопасности. Однако они также сталкиваются с самыми современными угрозами, что делает их столь же уязвимыми, сколь и безопасными. Атаки на цепочку поставок, такие как Солнечные ветры и серьезные уязвимости, такие как Журнал4Shell являются одними из последних угроз, с которыми сегодня сталкиваются программные системы. Подобные атаки на цепочку поставок программного обеспечения являются динамичными по своему эффекту, и в них труднее ориентироваться, поскольку они используют уязвимости в системах, находящихся вне вашего прямого контроля.
Однако первым шагом в борьбе с подобными атаками на цепочку поставок программного обеспечения является четкое знание пакетов, зависимостей и компонентов, включенных в ваше программное обеспечение. Вот почему важно составить спецификацию программного обеспечения (SBOM) для вашей сборки. Это не только повышает видимость уязвимостей в цепочке поставок программного обеспечения — SBOM также стал важным для целей обеспечения соответствия. Создание SBOM было предписано недавним исполнительный указ, изданный федеральным правительством США для повышения кибербезопасности и гарантии подлинности сторонних компонентов, используемых в пакетах программного обеспечения.
В соответствии с Gartner По прогнозам, к 60 году 2025% организаций, отвечающих за разработку программного обеспечения для критически важной инфраструктуры, потребуют стандартизированные SBOM. Создание SBOM начинается с выбора инструмента, соответствующего стандартам и целям вашей организации, определения этапов жизненного цикла сборки программного обеспечения, в течение которых необходимо примените SBOM, подтвердив, что он соответствует формату, и выполнив сканирование уязвимостей. Создание SBOM — деликатный и сложный процесс. В этой статье рассказывается, когда необходимо создание SBOM и как его создать для вашего программного обеспечения.
Когда создавать спецификацию программного обеспечения
Создание спецификации программного обеспечения (SBOM) имеет важное значение для обеспечения безопасности ваших сборок программного обеспечения, а также всей вашей цепочки поставок программного обеспечения. Генерацию SBOM можно интегрировать в различные этапы процесса сборки вашего программного обеспечения. Вы можете создать спецификацию, используя исходный код во время сборки, во время выполнения или при проведении экспертизы программного обеспечения. Из всего этого эксперты рекомендуют генерировать SBOM во время сборки. Это связано с тем, что генераторы SBOM во время сборки более точны и генерируют более полный список зависимостей. Однако, поскольку это не всегда практично, SBOM можно создать в любой другой момент жизненного цикла DevOps.
Стоит отметить, что тип используемого инструмента создания SBOM зависит от того, на каком этапе жизненного цикла DevOps создается документация SBOM. Ниже приведены различные этапы создания SBOM в течение жизненного цикла сборки. Каждый период имеет свои преимущества и компромиссы. Лучше всего понять целевую аудиторию и вариант использования генерируемых вами данных SBOM и выбрать подход, который обеспечит наилучший для вас результат.
На этапе исходного кода
Изучая артефакты и любые связанные с ними источники, такие как манифесты, метаданные и файлы блокировки, исходные или двоичные инструменты создают спецификацию программного обеспечения на этапе исходного кода. На этом этапе вы можете выполнить анализ компонентов программного обеспечения или бинарный анализ вашего программного обеспечения.
Инструмент SCA (анализ компонентов программного обеспечения) предназначен для анализа части программного обеспечения и его файлов манифеста для определения его компонентов. С другой стороны, инструменты двоичного анализа анализируют метаданные программного обеспечения и создают информацию об артефактах для создания SBOM. Примеры инструментов анализа, используемых на этом этапе, включают CycloneDX, It-Depends, Fossa, AppSonar, Cybellum, Black Duck и Fortress.
Вы можете использовать анализатор уязвимостей вместе с SBOM, созданным на этапе исходного кода, чтобы получать ранние предупреждения об уязвимостях в создаваемом программном обеспечении. Однако существуют ограничения на SBOM, созданные на этом этапе. Во-первых, они не являются полными, поскольку информация, сгенерированная во время сборки с зависимостями, часто отсутствует. Кроме того, они могут включать информацию о компонентах, которые не использовались в окончательном развернутом продукте.
Во время сборки
Создание SBOM во время сборки с помощью инструмента, который подключается к системе сборки, дает наиболее точную информацию о том, что входит в двоичный файл, включая транзитивные и незакрепленные зависимости. Это подтверждается Исследование NTIA по производству и предоставлению SBOM поставщиками программного обеспечения.
NTIA рекомендует создавать SBOM для каждого нового выпуска компонента. Это означает создание нового SBOM каждый раз, когда вы обновляете или выпускаете новую версию вашего программного обеспечения. Поставщики также обязаны создавать новые SBOM всякий раз, когда они обнаруживают ошибку в предыдущем или узнают новую информацию о своих программных компонентах, которая ранее не была документирована.
Создание SBOM во время сборки предполагает использование плагина, который работает с исходной средой, в которой вы создаете свое программное обеспечение. В большинстве сред разработки есть плагины, которые интегрируются с системой управления зависимостями для автоматического создания SBOM. Примеры генераторов SBOM во время сборки включают SPDX, плагин CycloneDX Maven и Dependency-Track-Check от OWASP.
Хотя генераторы SBOM во время сборки являются наиболее полными и точными, их сложнее настроить по сравнению с другими методами. Кроме того, этот метод не работает для некоторых систем сборки, и его нельзя использовать для устаревших продуктов.
Генерация SBOM во время выполнения
Генератор SBOM, работающий во время выполнения, предназначен для сбора библиотек, которые программное обеспечение, сервер приложений или подключаемые модули используют во время выполнения. Этот тип генератора также детализирует все службы, вызываемые программным обеспечением, а также порты и активные библиотеки, к которым оно обращается. Однако этот метод создания SBOM не получил широкого распространения. Кроме того, не существует четкого рабочего процесса для объединения данных, созданных с помощью этого метода, с исходной документацией SBOM. Джбом и Карта угроз являются примерами генераторов SBOM во время выполнения.
Как составить спецификацию программного обеспечения: пошаговое руководство
Создание спецификации программного обеспечения вручную отнимает много времени и утомительно для разработчиков. Перечислять таким образом все компоненты программы в большинстве случаев непрактично. Однако теперь доступны многочисленные инструменты создания SBOM, которые упрощают этот процесс. Как это сделать, зависит от стандартов вашей организации и от того, когда вы хотите создать SBOM во время жизненного цикла разработки.
Интегрируя рабочие процессы SBOM в конвейеры сборки программного обеспечения, вы можете автоматизировать процесс SBOM. Платформа Писца — один из таких инструментов, который упрощает создание спецификации программного обеспечения. Scribe позволяет вам управлять своим SBOM и делиться им из одного места. Таким образом, вы можете проверить целостность ваших программных компонентов и беспрепятственно отслеживать уязвимости в программном конвейере. Этот раздел представляет собой пошаговое руководство по созданию спецификаций программного обеспечения с помощью Scribe.
Шаг 1. Зарегистрируйтесь и войдите в Scribe Trust Hub.
Прежде чем начать, вы должны знать, что платформа Scribe имеет веб-интерфейс Scribe Trust Hub, доступный из вашего браузера. Однако сборщик доказательств Scribe работает только на устройствах Linux и Mac. Чтобы создать отчет о целостности и SBOM с помощью Scribe, у вас должно быть разрешение на изменение сценария сборки вашего проекта и добавление соответствующего фрагмента кода, необходимого для подключения вашего проекта к Scribe. Имейте в виду, что хотя Scribe может генерировать SBOM для проектов, написанных на любом языке программирования, генерирующем образ контейнера, текущая версия работает только для проектов Node.js.
Первым шагом для интеграции Scribe в ваш проект является регистрация в Scribe Trust Hub. После регистрации и входа в систему перейдите на вкладку «Продукты» и нажмите «Настроить». На этой странице Scribe есть демонстрационный продукт, с которым вы можете взаимодействовать, чтобы познакомиться с платформой и понять, как она работает.
Шаг 2. Интеграция Scribe Trust Hub
Следующий шаг — подключить Scribe к конвейеру непрерывной интеграции вашего проекта. Это автоматизирует процесс генерации SBOM. Как правило, вы можете добавлять фрагменты кода из Scribe Trust Hub в две точки вашего конвейера CI. Вы можете разместить код на этапе оформления исходного кода или в окончательном построенном образе. Первый вариант рекомендуется, но не является обязательным, а второй является обязательным.
Настройка CI Scribe в настоящее время работает только для Jenkins через Kubernetes и GitHub Actions. Процесс интеграции Scribe для этих установок CI аналогичен. Чтобы начать работу, вам необходимо получить следующие учетные данные на странице настройки продукта Scribe Hub:
- Ключ продукта
- идентификатор клиента
- Секрет клиента
Ключ продукта варьируется от одного продукта к другому, а учетные данные клиента уникальны для вашей учетной записи.
Настройка интеграции CI для Jenkins
Чтобы настроить интеграцию CI для Jenkins, вы можете добавить фрагмент кода для вызова Gensbom (инструмента Scribe Trust Hubs для сбора доказательств и создания SBOM) на этапе оформления заказа и/или после создания образа Docker.
Начните с добавления указанных выше учетных данных в среду сборки в соответствии с уникальными инструкциями по Jenkins . Затем добавьте фрагмент кода в свой конвейер согласно инструкциям. здесь.
Настройка интеграции CI для действий GitHub
Процесс настройки интеграции CI для GitHub Actions аналогичен процессу Jenkins. Основная идея состоит в том, чтобы вызвать сборщика доказательств и генератора SBOM Scribe, известного как «Gensbom». Для начала следуйте инструкциям Инструкции на GitHub добавить в конвейер учетные данные для настройки продукта и фрагмент кода согласно инструкциям здесь
Интеграция Scribe Trust Hub с другими системами CI
Хотя Scribe предлагает только встроенную поддержку действий Jenkins и GitHub, вы также можете использовать его для других систем CI. Для начала загрузите инструмент «Gensbom» из интерфейса командной строки на базе Unix. Затем добавьте свой продукт и учетные данные клиента, а затем вызовите Scribe gensbom из сценария сборки либо при оформлении заказа, либо после окончательного создания образа.
Шаг 3. Создание спецификации программного обеспечения
Инструмент CLI gensbom от Scribe генерирует спецификацию программного обеспечения (SBOM) для Docker и образов открытых контейнеров (OCI). Этот инструмент работает только в системах Mac или Linux. Окончательный SBOM, созданный Scribe, имеет формат CycloneDX JSON, который является одним из стандартных машинных и человекочитаемых форматов, распознаваемых для SBOM. Образы открытых контейнеров можно извлечь из Docker, локального диска или удаленного реестра, в зависимости от обстоятельств.
Хотя существуют настройки по умолчанию для имени, каталога и пути к изображению, из которого создается SBOM, при желании можно соответствующим образом изменить эти настройки по умолчанию.
Шаг 4. Экспортируйте SBOM
Scribe Trust Hub также позволяет вам легко экспортировать и публиковать спецификацию программного обеспечения в рамках процесса проверки вашего программного обеспечения. SBOM генерируется в формате отчетов CycloneDX JSON и подробно описывает все зависимости с открытым исходным кодом анализируемого образа Docker. После создания SBOM вы можете экспортировать его одним щелчком мыши. В правом верхнем углу отчета вы найдете кнопку «Экспорт SBOM». Нажмите на нее, чтобы экспортировать спецификации программного обеспечения.
Заключение
Составление спецификации программного обеспечения становится все более важным шагом для обеспечения безопасности вашей цепочки поставок программного обеспечения, а также для обеспечения соответствия требованиям. Независимо от причин создания SBOM, вы найдете Scribe Trust Hub простым в использовании и гибким способом автоматизации рабочего процесса создания SBOM для каждой сборки вашего программного обеспечения.