Спасительный SLSA. Оценка эффективности защиты цепочек поставок

Спасительный SLSA. Оценка эффективности защиты цепочек поставок

БЕЗОПАСНАЯ РАЗРАБОТКА И ЗАЩИТА ЦЕПОЧКИ ПОСТАВОК

Безопасная разработка, очевидно, помогает предотвращать риски, связанные с уязвимостями приложений, ещё на этапе разработки, минимизирует риски и повышает надёжность системы. Для этого применяются специализированные методы, инструменты и анализ безопасности.

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

При этом особо остро сейчас стоит задача защиты цепочки поставок при использовании сторонних библиотек и модулей в разработке приложений. В связи со сложностью и зависимостью процессов разработки от сторонних инструментов атаки на разработку стали более возможными. Теперь целью атак могут быть не уязвимости в конечном продукте, а сам процесс разработки. Атаки supply chain обычно нацелены на внедрение вредоносных изменений во время написания кода, замену распространяемых компонентов или зависимостей. Основная цель такой атаки — получить несанкционированный доступ к данным, интеллектуальной собственности или нанести ущерб компании. 

Все помнят масштабы атаки на финансовую отрасль с помощью вредоноса NotPetya, который эксплуатировал уязвимости в одном из поставщиков ПО, или известную атаку на Solarwinds. По данным Positive Technologies, в III квартале 2023-го количество атак на финансовые организации и их клиентов удвоилось по сравнению с таким же периодом прошлого года. При этом в 22% инцидентов было зафиксирована эксплуатация уязвимостей в цепочках поставок ПО. То есть обороты не сбавляются. 

ЗНАЧЕНИЕ SLSA ДЛЯ DEVSECOPS

Как удостовериться, что выстроенный вами SSDL обеспечивает нужный уровень безопасности цепочки поставок ПО? Есть ли у сообщества DevSecOps эталон или чек-лист, по которому можно удостовериться, что контролей безопасности достаточно для снижения этих рисков? Тут на помощь и приходит такой стандарт, как SLSA (Supply-chain Levels for Software Artifacts).

SLSA (уровни цепочки поставок) — это фреймворк, предложенный компанией Google и поддерживаемый ассоциацией Open Source Security Foundation, которая обеспечивает процессы контроля целостности и безопасности программных компонентов на всех этапах их поставки.

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

Рисунок 1. SLSA включает набор требований и рекомендаций по безопасности

СТАНДАРТЫ БЕЗОПАСНОЙ РАЗРАБОТКИ

Давайте посмотрим, как удостовериться, что ваши коллеги, которые предпочитают разрабатывать в облаке, будут разрабатывать с учётом рекомендаций и требований безопасности. Возьмём в качестве примера стандарт SLSA. 

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

Соответствие SLSA в облаке показано на рис. 2.

Рисунок 2. Соответствие SLSA в облаке

Уровень 1 и 2 покрывается за счёт встроенных возможностей Managed Service for GitLab, одна из которых — генерации provenance attestation.

Attestation (аттестация программного обеспечения) — это аутентифицированное заявление (метаданные) о программном артефакте или коллекции программных артефактов. Основным предполагаемым вариантом применения является использование в автоматизированных механизмах разработки политик, таких как in-toto и Binary Authorization. Cообщество Open Source Software Security (OpenSSF) в целом и проект SLSA в частности проделали большую работу по определению структуры и эталонной реализации. Суть её в том, что основной частью метаданных является заявление, заворачивающееся в конверт, который затем подписывается, формируя окончательную аттестацию. 

Уровень 3 достигается с использованием решения Сosign, интегрированного с сервисом Yandex Key Management, для подписи образов и локальных артефактов.

Cosign — это инструмент, разработанный командой Google, который предоставляет возможность подписывать и проверять подписи контейнерных образов. Он разработан с целью обеспечения безопасности и доверия при работе с контейнерами, особенно в контексте поставки и развёртывания контейнерных образов.

Yandex Key Management Service — сервис для управления криптографическими ключами. Эти ключи используются, чтобы защитить секреты, личные данные и другую конфиденциальную информацию, которую вы храните в облаке.

В сервисе Key Management Service можно использовать ключевые пары электронной подписи, созданные с помощью утилиты Cosign. Вот QR-код с инструкцией, как с помощью Cosign сохранять созданную ключевую пару в сервисе Yandex Key Management Service, подписывать файлы и артефакты закрытым ключом этой пары и проверять электронную подпись с помощью её открытого ключа.

Уровень 4: система должна соответствовать стандартам безопасности и обладать свойствами герметичности и изолированности.

Помимо того, что само облако соответствует стандартам безопасности, как отечественным, так и международным, и отдельным рекомендациям о безопасности CI/CD-системы на базе управляемого GitLab.

У пользователей есть возможность проводить сканирование на уязвимости своих образов, хранящихся в Yandex Container Registry, с помощью Сканера уязвимостей. Проверка образов на уязвимости важна для защиты цепочки поставок от атак и обеспечения безопасности облачных приложений.

Если говорить про отечественные стандарты, стоит упомянуть недавно обновлённый стандарт ГОСТ Р 56939-202Х «Защита информации. Разработка безопасного программного обеспечения. Общие требования» который мы сейчас активно изучаем. ГОСТ Р 56939 направлен на достижение целей, связанных с предотвращением появления или устранением уязвимостей программ, и содержит перечень мер, которые рекомендуется реализовать на соответствующих этапах жизненного цикла программного обеспечения. 

Кроме того, рекомендуем обратить внимание на то, что у Yandex Cloud есть собственный Стандарт по защите облачной инфраструктуры. Этот документ включает рекомендации по техническим мерам защиты и помогает выбрать меры обеспечения информационной безопасности при развёртывании информационных систем на облачной платформе Yandex Cloud. 

Рекомендации и меры обеспечения безопасности в стандарте сопровождаются ссылками на инструкции и решения по настройке безопасных конфигураций ресурсов с помощью штатных средств защиты информации и дополнительных средств защиты, доступных пользователям Yandex Cloud. На основе SLSA был написан 9-й раздел, посвящённый защите приложений, который устанавливает дополнительные требования к безопасности в цепочке поставок программных продуктов. Этот раздел учитывает рекомендации и лучшие практики, представленные в SLSA, и расширяет их для обеспечения максимальной защиты. 

ИНСТРУМЕНТЫ КОНТРОЛЯ ЦЕПОЧЕК ПОСТАВОК

Давайте рассмотрим некоторые ключевые этапы в построении надёжного пайплайна для безопасной разработки с инструментами контроля цепочки поставок, чтобы соответствовать SLSA.

Этапы построения Pipeline

Рисунок 3. Этапы построения Pipeline

По результатам опроса наших клиентов четверть пользователей Yandex Cloud используют облачную платформу для разработки. Так выглядит DevSecOps-пайплайн (рис. 3). Погрузимся в каждый этап подробнее.

Планирование и дизайн

Перед тем как написать первые строчки кода, необходимо верхнеуровнево понять, как вы будете выстраивать безопасную инфраструктуру. В контексте Yandex Cloud можно посетить портал безопасности, где собраны материалы по тому, как само облако соответствует требованиям регуляторов, как вы можете соответствовать этим требованиям, и много ещё интересного (рис. 4).

Рисунок 4. Планирование и дизайн

Разработка

Этап безопасной разработки нужно начинать с обучения разработчиков: подготовить гайды и рекомендации по безопасному программированию с примерами на ваших языках. Это поможет не допускать типовых и простых ошибок в начале пути. Так как разработка начинается с компьютера разработчика, необходимо выставить политики на уровень организации о том, каким должно быть рабочее место разработчика и какие локальные проверки должен проходить код, прежде чем он попадет в удалённый репозиторий (рис. 5). 

Рисунок 5. Разработка

Сборка и безопасность образов

Этап сборки и обеспечения безопасности образа состоит из следующих процессов.

Проверка в CI-пайплайне

• Проверка безопасности исходного кода после того, как он попал в систему контроля версий. Инструменты SAST выполняют статический анализ исходного кода и его зависимостей, чтобы обнаружить распространённые уязвимости, например из списка OWASP Top Ten.
• Проверка на наличие утёкших секретов с помощью Secret Detection, встроенного в Gitlab.
• Сканирование на уязвимости Docker-образа. Сканер уязвимостей интегрирован в сервис Yandex Container Registry и настраивается с помощью веб-интерфейса. Это позволяет освободить время специалистов ИБ и DevOps.
• SBOM содержит полный список всех компонентов и зависимостей, используемых в проекте ПО.
• SBOM помогает определить все составные части программного обеспечения, что позволяет контролировать безопасность и управлять рисками, связанными с использованием сторонних компонентов​. На этом этапе генерируем его с помощью syft и подпишем с помощью Cosign как локальный файл, далее отправляемего в Object Storage.
• Подпись образа и SBOM с помощью Cosign, интегрированного в Yandex KMS для обеспечения подлинности, целостности, доверия и соответствия требованиям в вашем программном обеспечении.

Далее сканер уязвимостей можно настроить на сканирование Docker-образов в реестрах автоматически при загрузке или по расписанию либо встроить в пайплайн, как мы сделали выше

Audit Trails — это сервис для сбора и выгрузки аудитных логов ресурсов Yandex Cloud (рис. 6).

Рисунок 6. Сборка и безопасность образов

Развёртывание и RUN-TIME

Ну, и наконец, этап развёртывания. Но и тут проверки не заканчиваются, мы проводим проверку безопасности приложения, которое запущено из собранного артефакта. Инструменты DAST (динамический анализ кода, метод «чёрного ящика») в этой фазе пытаются «сломать» приложение, имитируя действия злоумышленников (рис. 7).

В Run-time-этапе происходят непрерывные проверки безопасности приложения после развёртывания в production-среде. Инструменты в режиме реального времени мониторят открытые реестры известных уязвимостей и отправляют уведомление, обнаружив угрозу для приложения.

Рисунок 7. Развёртывание

ЗАКЛЮЧЕНИЕ

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

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