Спецификация состава программного обеспечения (SBOM) обладает потенциалом для предотвращения большинства атак на цепочки поставок.
SBOM — это своего рода «список ингредиентов» для программного обеспечения, который вместе с цифровыми подписями и аттестациями обеспечивает прослеживаемость, включая такую информацию, как:
- Кто создал программное обеспечение (атрибуция).
- Откуда это программное обеспечение (происхождение).
- Что содержит это программное обеспечение.
Стандартный формат также является идеальным инструментом для обмена этой информацией между инструментами CNAPP.
Однако отсутствие мотивации для надлежащей проверки целостности программного обеспечения и недостаточная поддержка со стороны инструментов разработки ограничивают полезность SBOM.
Давайте проанализируем роль SBOM в жизненном цикле программного обеспечения и то, что сдерживает их внедрение.
SBOM в жизненном цикле программного обеспечения
Разработка программного обеспечения выглядит примерно так: кто-то берет несколько библиотек и инструментов, объединяет их с кодом и создает новый программный продукт. Это также цепочка: кто-то другой возьмет это ПО и построит на его основе что-то новое.
Из-за огромного количества зависимостей между компонентами инцидент с небольшим компонентом может скомпрометировать миллионы систем. Именно это происходит с OpenSSL, криптографической библиотекой с открытым исходным кодом, используемой большинством компьютерных систем. Уязвимость в OpenSSL часто становится глобальным риском безопасности.
Этот потенциальный масштаб воздействия делает атаки на цепочки поставок такими привлекательными для злоумышленников.
Аттестации программного обеспечения отлично подходят для защиты вашей инфраструктуры от большинства атак на цепочки поставок. Это структурированные данные, содержащие SBOM, а также любые произвольные данные, такие как источник происхождения или список уязвимостей. Аттестации могут быть подписаны разработчиком и репозиторием программного обеспечения.
Аттестацию для образов контейнеров можно загрузить и проверить с помощью команды docker scout attest:
Узнайте больше в статье «Как защитить развертывание Kubernetes с помощью проверки подписей».
Проверяя дайджест образа контейнера на соответствие его подписям аттестации, вы можете определить, изменил ли кто-то образ или выдал себя за репозиторий. Помните, что эта проверка имеет свои ограничения; она не покроет случаи, когда скомпрометирован сам репозиторий или его ключи.
В идеале вы должны выполнять эту проверку перед использованием любого программного обеспечения, особенно перед развертыванием его в рабочей среде. Затем вам также следует создавать и подписывать SBOM при упаковке собственного программного обеспечения.
Для разработки в Kubernetes жизненный цикл выглядел бы примерно так:
На бумаге это выглядит отлично: вы знаете, что используете и откуда это взялось. Это защищает вас от большинства векторов атак на цепочки поставок.
Так почему же уровень внедрения SBOM так низок? Давайте рассмотрим некоторые проблемы, с которыми сталкиваются SBOM при достижении поддержки и эффективности.
Проблема 1: Несогласованная поддержка инструментов
Каждый, кто имел дело с цифровыми подписями, знает, сколько хлопот это доставляет.
Хотя многие инструменты разработки программного обеспечения поддерживают аттестации, заставить все эти инструменты работать вместе у разработчиков и инфраструктурных команд требует настройки и борьбы с командной строкой. Внедрение этой системы не масштабируется до корпоративных сред или больших команд.
Это создает порочный круг. Без поддержки инструментов внедрение идет медленно, а низкий уровень внедрения не мотивирует разработчиков инструментов.
Однако при хорошей поддержке со стороны инструментов цифровые подписи становятся практически прозрачными. Хорошим примером является система нотариального заверения Apple. Инструменты разработки Apple автоматически создают, подписывают и заверяют приложения для разработчиков. Это не создает SBOM, но решает вопросы с подписями практически бесшовно.
Проблема 2: Вы не можете доверять каждому SBOM
Когда вы покупаете майонез, список ингредиентов не скажет вам, содержит ли он сальмонеллу. Точно так же разработчик не узнает, содержит ли его программное обеспечение вредоносный код.
SBOM, предоставляемые разработчиками, хороши для быстрых проверок, например, при изучении новых библиотек, базовых образов или инструментов. Однако и пользователи, и репозитории должны проводить собственные тесты, чтобы быть уверенными в том, что они используют. Для контейнеров и рабочих нагрузок Kubernetes сканеры образов являются инструментом для выполнения этих проверок.
Поскольку большинство реестров контейнеров не проводят собственные сканирования в дополнение к тому, что заявил разработчик, их SBOM носят лишь информативный характер.
Тем не менее, вы можете выполнять собственное сканирование образов. Это позволит вам блокировать релизы в ваших CI/CD-конвейерах, если образы не соответствуют политикам безопасности вашей организации. Кроме того, интегрировав сканер образов с контроллером допуска Kubernetes, вы можете создавать комплексные SBOM, которые дополняют предоставленные разработчиками и блокируют попадание вредоносных образов в рабочую среду.
Проблема 3: Уязвимости меняются со временем
Одна из вещей, которую ищут сканеры образов, — это известные уязвимости.
Обладая этой информацией, вы можете принять решение заблокировать развертывание тех образов контейнеров, которые содержат критическую и эксплуатируемую уязвимость. Фактически, некоторые инструменты начинают включать уязвимости в создаваемый ими SBOM.
Однако одного сканирования недостаточно. Поскольку новые уязвимости обнаруживаются каждый день, вам необходимо постоянно проверять свои образы на их наличие. Если в SBOM указаны уязвимости, не принимайте эту информацию на веру. Проверьте, когда было выполнено сканирование, и дополните этот SBOM собственными проверками.
К счастью, некоторые платформы CNAPP уже делают это за вас:
- Они выполняют первоначальное сканирование, чтобы узнать, что находится в образе и какие у него есть уязвимости.
- Они дополняют результаты сканирования контекстом из вашей инфраструктуры.
- Они хранят эту информацию в формате SBOM, поэтому им не нужно повторно сканировать образ для поиска новых уязвимостей.
Проблема 4: Внутренние угрозы
Наконец, SBOM не покрывает случаи, когда злоумышленники имеют внутренний доступ.
Это может быть связано с тем, что член команды был скомпрометирован, как в случае с инцидентом с npm-пакетом Axio, или с тем, что некоторые сотрудники являются самозванцами, работающими на организованные группы со злым умыслом. В любом случае, злоумышленник может использовать этот внутренний доступ, чтобы скрыть вредоносные полезные нагрузки в вашем программном обеспечении.
Одним из самых серьезных инцидентов стал бэкдор 2024 года в XZ Utils, библиотеке, используемой в OpenSSH, утилите удаленного доступа, установленной на большинстве серверов и машин разработчиков. Вредоносный участник годами предоставлял полезный код, пока внезапно не внедрил бэкдор.
К сожалению, часто требуется выполнить код, чтобы обнаружить эти вредоносные нагрузки, а традиционные сканеры образов не выполняют этот вид динамической атаки. Кроме того, когда ИИ бездумно используется для генерации кода, он вносит шум, который затрудняет обнаружение аномального кода.
Вот почему одних только SBOM и аттестаций недостаточно для обнаружения новых уязвимостей, и вам необходимо внедрять дополнительные проверки.
К счастью, ИИ также демонстрирует свою эффективность в поиске уязвимостей программного обеспечения. Это означает, что внутренние угрозы могут быть обнаружены, если ИИ внедряется вместе со сканерами образов в CI/CD-конвейерах.
Заключение
SBOM — это стандартный инструмент для обмена информацией между компонентами CNAPP.
Цепочка поставок программного обеспечения — это цепочка доверия, в которой важно каждое звено. Каждый участник цепочки должен выполнять свои проверки, сообщать о результатах через SBOM и подтверждать свои полномочия с помощью подписанных аттестаций.
Поскольку всё это носит добровольный характер, организации часто не внедряют необходимые проверки. Также наблюдается нехватка поддержки в инструментах разработки программного обеспечения. Всё это означает, что слишком многие SBOM не содержат той полезной информации, которая в них должна быть.
Но это не значит, что мы должны просто отказаться от SBOM. Как и в других фундаментальных сферах нашего общества, таких как продовольствие, здравоохранение и промышленность, нам нужны нормативные акты для обеспечения доверия к цепочке поставок программного обеспечения.
Даже если SBOM несовершенны, они остаются бесценным инструментом для вашей внутренней инфраструктуры. Вы можете начать создавать SBOM с помощью сканеров образов и использовать их в качестве входных данных для ваших оценщиков политик, или же предоставлять их вместе со своим программным обеспечением для укрепления доверия пользователей. Мир в конечном итоге наверстает упущенное, а вы будете на шаг впереди.
