Спецификация состава программного обеспечения (SBOM) обладает потенциалом для предотвращения большинства атак на цепочку поставок.
SBOM похожа на ярлык со «списком ингредиентов» для программного обеспечения, который вместе с подписями и аттестациями обеспечивает отслеживаемость, включая такую информацию, как:
- Кто создал программное обеспечение (авторство).
- Откуда взялось это программное обеспечение (происхождение)
- Что содержит программное обеспечение.
Стандартный формат также является идеальным инструментом для обмена этой информацией между инструментами CNAPP.
Однако отсутствие мотивации для должной проверки целостности ПО и нехватка поддержки со стороны инструментов разработчика ограничивают полезность SBOM.
Давайте проанализируем роль SBOM в жизненном цикле программного обеспечения и то, что сдерживает их внедрение.
SBOM в жизненном цикле программного обеспечения
Разработка программного обеспечения выглядит примерно так: кто-то берет несколько библиотек и инструментов, объединяет их с кодом и создает новую программу. Это также цепь: кто-то возьмет это программное обеспечение и создаст на его основе что-то новое.
При таком большом количестве зависимостей между компонентами инцидент с небольшим компонентом может скомпрометировать миллионы систем. Именно это происходит с OpenSSL, библиотекой криптографии с открытым исходным кодом, используемой большинством компьютерных систем. Уязвимость в OpenSSL часто становится глобальным риском безопасности.
Именно этот потенциальный ущерб делает атаки на цепочку поставок столь привлекательными для злоумышленников.
Аттестации программного обеспечения отлично подходят для защиты вашей инфраструктуры от большинства атак на цепочку поставок. Они представляют собой структурированные данные, содержащие SBOM, а также любые произвольные данные, такие как исходное происхождение или список уязвимостей. Аттестации могут быть подписаны разработчиком и репозиторием программного обеспечения.
Аттестацию для образов контейнеров можно загрузить и проверить с помощью docker scout attest:
Проверяя дайджест образа контейнера по его аттестационным подписям, вы можете определить, изменял ли кто-либо образ или выдавал ли себя за репозиторий. Имейте в виду, что эта проверка имеет свои ограничения; она не покроет случаи, когда сам репозиторий или его ключи скомпрометированы.
В идеале следует выполнять эту проверку перед использованием любого программного обеспечения, особенно перед его развертыванием в продакшене. Затем вам также следует создавать и подписывать 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 с помощью сканеров образов и использовать их в качестве входных данных для средств оценки политик, или вы можете предоставлять их вместе со своим программным обеспечением для укрепления доверия у пользователей. В конце концов мир наверстает упущенное, а вы окажетесь на шаг впереди.
