Привет, Хабр! Я Михаил Черешнев, специалист по DevSecOps в компании Swordfish Security. Сегодня мы поговорим о важности защиты цепочки поставок программного обеспечения — критического аспекта для любой современной компании. В статье я расскажу, как мы в Swordfish Security реализуем стратегию Software Supply Chain Security (SSCS) и покажу, как с этой задачей могут помочь Open Source-решения.

Эта статья является текстовой версией моего доклада с конференции PHD2. Если тема вас заинтересует, можете посмотреть полное выступление по ссылке: [тут будет ссылка].

Что такое "Цепочка поставок"?

Для начала, давайте разберёмся, что такое цепочка поставок в обычной жизни. Представьте, что вы заказываете пиццу через мобильное приложение. В этой цепочке участвуют разные звенья: ритейлер (пиццерия), дистрибьютор (который доставляет полуфабрикаты) и производитель ингредиентов (ферма или завод). Однако, в мире DevSecOps к этой цепочке нужно добавить два новых элемента — злоумышленника и последствия его возможной атаки.

Теперь представим, что злоумышленник получает доступ к одному из звеньев этой цепочки. Например, если он скомпрометирует дистрибьютора, все магазины пиццерии окажутся под угрозой. Если злоумышленник проникнет на завод, где производятся ингредиенты, заражение может распространиться ещё дальше, затронув всю цепочку. И наконец, если "ферма" (поставщик сырья) окажется ненадежной — например, из-за использования плохих семян — это негативно повлияет на конечный продукт.

Теперь переведём этот пример на контекст разработки программного обеспечения. В цепочке поставок ПО можно выделить ключевые этапы, такие как:

• Код и зависимости;

• CI/CD системы (Continuous Integration / Continuous Delivery);

• Реестры артефактов (где хранятся пакеты, контейнеры и другие зависимости);

• Платформы исполнения (где развёртывается и запускается приложение).

Каждое из этих звеньев подвержено атакам. Если злоумышленник получит доступ хотя бы к одному элементу — это может привести к серьёзным последствиям для всей системы. Поэтому защита всех этапов цепочки поставок — это первостепенная задача для любой компании, стремящейся обеспечить безопасность своих приложений и данных.

Основные угрозы в цепочке поставок программного обеспечения

В процессе обеспечения безопасности цепочки поставок программного обеспечения могут возникнуть несколько ключевых угроз. Вот некоторые из них:

1. Недекларированные возможности
   Это скрытые функции или возможности, которые неожиданно появляются в исходном коде, загруженном в публичные репозитории, например, на GitHub. Такие изменения могут внедряться без ведома разработчиков и служить для атаки на систему.

2. Раскрытые секреты организаций
   Одна из частых ошибок — это случайная публикация чувствительной информации в открытых репозиториях. Это могут быть пароли, ключи API, токены доступа или другие критически важные данные, которые злоумышленники могут использовать для проникновения в системы компании.

3. Уязвимости в артефактах
   Проблемы могут возникнуть на уровне управления артефактами, такими как пакеты, контейнеры или библиотеки. Недостаточная проверка загружаемого кода, отсутствие информации о том, кто его собирал, и о том, как он изменялся при доставке, создают риски для безопасности.

4. Уязвимости в системах CI/CD
   Этот аспект заслуживает особого внимания. CI/CD-системы, которые автоматизируют сборку и развертывание приложений, всё ещё недостаточно изучены с точки зрения безопасности, особенно в российском сегменте. Пока не появятся качественные материалы и методики защиты CI/CD, этот важный аспект останется под угрозой. Злоумышленники могут использовать уязвимости в цепочках CI/CD для проникновения в финальные системы.

5. Уязвимости реестров и платформ исполнения
   Реестры контейнеров, системы непрерывной интеграции, а также платформы исполнения (например, Kubernetes) также могут быть подвержены атакам.

   

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

   Стандарты и фреймворки для защиты цепочки поставок ПО (SSCS)

   Для защиты цепочки поставок программного обеспечения разработано множество стандартов и фреймворков. Вот некоторые из наиболее значимых:

   1. CIS (Center for Internet Security)

      • CIS Software Supply Chain Guide: руководство по защите цепочки поставок ПО.

      • CIS Software Supply Chain Benchmarks: набор эталонных показателей для оценки безопасности цепочки поставок.

   2. S2C2F (Secure Supply Chain Consumption Framework)
      Включает практические требования и инструменты, которые помогают организациям безопасно внедрять и потреблять open-source решения.

   3. SCITT (Supply Chain Integrity, Transparency and Trust)
      Инициатива, направленная на обеспечение прозрачности и доверия в цепочке поставок ПО. SCITT устанавливает стандарты, касающиеся подлинности субъектов, доказательств, политик и артефактов в цепочке поставок.

   4. OSC&R (Open Software Supply Chain Attack Reference)

      • Attack Matrix for Software Supply Chain Security: матрица атак на цепочку поставок ПО, позволяющая систематизировать возможные угрозы и атаки.

      • PBOM (Pipeline Bill of Materials): спецификация, позволяющая отслеживать все этапы разработки и сборки ПО для обеспечения безопасности.

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

   1. SLSA (Supply-chain Levels for Software Artifacts)
      Это фреймворк, который предлагает контрольный список стандартов и мероприятий для предотвращения вмешательства в цепочку поставок, повышения целостности и обеспечения безопасности пакетов и инфраструктуры. Подробнее о том, как использовать SLSA, можно узнать здесь.

   2. TUF (The Update Framework)
      TUF предоставляет гибкую структуру и спецификацию для защиты процессов обновления программного обеспечения. Этот фреймворк позволяет разработчикам интегрировать его в любую систему обновлений для обеспечения безопасности пакетов и предотвращения атак на обновления. Подробнее о TUF можно прочитать здесь.

   3. in-toto
      In-toto — это фреймворк для обеспечения целостности цепочки поставок программного обеспечения. Он предлагает расширяемый стандарт метаданных для документирования всех шагов в процессе разработки, тем самым гарантируя, что каждый шаг выполняется корректно и безопасно. Узнать больше о in-toto можно здесь.

   Какие практики стоит внедрять для защиты цепочки поставок?

   Теперь перейдём к практической части. Чтобы обеспечить безопасность цепочки поставок программного обеспечения (SSCS), необходимо убедить всех участников процесса — будь то люди или системы — что этот процесс герметичен. Глобально, включает три ключевых этапа:

   1. Сбор доказательств
      Нам нужна система, которая будет собирать и сохранять все данные, подтверждающие безопасность на каждом этапе цепочки поставок.

   2. Публикация и хранение доказательств
      Доказательства должны быть опубликованы и сохранены для дальнейшей проверки. Это важный этап, поскольку обеспечивает прозрачность процесса.

   3. Валидация доказательств
      На финальном этапе все собранные данные проверяются для подтверждения их подлинности и достоверности.

   

   Эволюция процесса до 2022 года

   Ранее процесс включал несколько шагов, таких как:

   • Provenance — это артефакт, который фиксирует изменения окружения во время сборки и указывает на то, какой продукт был создан.

   • Аттестация — это подписанное заявление, подтверждающее, что артефакт прошёл все необходимые проверки.

   • Подпись — подтверждение происхождения артефакта.

   • SBOM (Software Bill of Materials) — список всех компонентов программного обеспечения и их зависимостей.

   Упрощённая схема

   Сегодня этот процесс можно упростить до двух ключевых элементов: подписи и аттестации. В рамках фреймворка in-toto аттестация может включать любое заявление (statement), которое собирается в процессе разработки. Например, различные DevOps и DevSecOps-инструменты (такие как CI/CD, системы поиска секретов, DAST, SAST и т.д.) могут генерировать отчёты, и эти отчёты могут быть включены в аттестацию как доказательства.

   

   Типы таких заявлений или предикатов в SLSA и in-toto могут включать:

   • .cyclonedx

   • .spdx

   • .provenance 

   • .realise

   • .test-result

   • .vuln

   • .link 

   • .vsa

   • .scai

   • .runtime-trace

Можно разработать собственную спецификацию при наличии ИБ-инструмента, который принимает решения или генерирует какие-либо данные. Например: https://swordfishsecurity.com/attestation/assessment-result/v0.1.Ознакомиться с полным описание спецификации in-toto можно здесь.

Как сделать корректное заявление?

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

Технологии для защиты цепочки поставок программного обеспечения (SSCS)

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

• Где хранить метаданные SSCS?

• Как безопасно распространять эти данные?

• Какие метаданные необходимы нашим пользователям?

• Как потребитель может оценить безопасность артефакта?

• Как защитить данные от взлома?

• Подходят ли существующие данные SSCS для всех типов артефактов?

Эти вопросы помогают выработать требования к хранилищу метаданных: оно должно быть неизменяемым, защищённым от взломов и независимым от самих артефактов.

Хранение данных в SSCS: что использовать?

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

Среди интересных хранилищ для данных цепочки поставок можно выделить:

1. TLOG (Transparency Log Server)
   Журнал прозрачности, который записывает и хранит метаданные цепочки поставок. Пример реализации — Rekor.

2. OCI Registry/CAS (Content Addressable Storage)
   Контентно-адресуемое хранилище, которое позволяет сохранять как артефакты, так и связанные с ними доказательства.

Действия с хранилищем метаданных

С адресуемым хранилищем выполняются два основных действия: загрузка данных и получение доказательств. Для этого используются различные системы, такие как TLOG и CAS. Например, Rekor может записывать и хранить данные с помощью таких систем, как Trillian (система для управления журналами прозрачности) или MariaDB (база данных для хранения метаданных).

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

Особенности различных систем хранения

Каждая система имеет свои уникальные особенности, и их выбор зависит от целей организации. Например:

• TLOG (например, Rekor):

  • Хранит только метаданные.

  • Не использует управление доступом на основе ролей (RBAC).

  • Поддерживает только добавление данных (без удаления).

  • Независим от артефактов.

  • Имеет проверяемый журнал и карту метаданных.

• OCI Registry/CAS:

  • Хранит как артефакты, так и доказательства.

  • Поддерживает RBAC (управление доступом на основе ролей).

  • Позволяет создавать и удалять артефакты.

  • Совместим с OCI-стандартами.

Валидация доказательств

Процесс валидации доказательств также довольно прост и уже хорошо зарекомендовал себя в индустрии. Есть несколько классических систем для проверки, к которым относятся:

• CRI (Container Runtime Interface) — интерфейс исполнения контейнеров, через который можно загружать ключи для верификации артефактов (например, Docker, Podman и другие).

• Контроллеры — такие системы как Gatekeeper, Kyverno, Kubewarden и Sigstore/Policy Controller, которые помогают внедрять политики безопасности.

• Специализированные утилиты — например, Notary, Rekor-CLI, Sigstore/Cosign, которые обеспечивают удобные инструменты для подписи и проверки артефактов.

Решения

Как мы уже упоминали ранее, цепочка поставок программного обеспечения (SSCS) включает три ключевых этапа: генерация, хранение и валидация доказательств. Рассмотрим, какие технологии и решения можно использовать на каждом из этих этапов.

Генерация доказательств

Для генерации доказательств мы можем использовать широкий стек инструментов DevSecOps. В нашей компании основное внимание уделяется таким спецификациям, как in-toto и Notary, которые позволяют эффективно отслеживать и фиксировать происхождение артефактов. В качестве источников данных для генерации доказательств мы используем инструменты DevOps и DevSecOps.

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

Хранение доказательств

Для хранения доказательств существует множество решений. Наиболее популярные — это OCI-реестры (реестры контейнеров), которые поддерживают хранение артефактов и метаданных. Примеры таких реестров включают:

• Yandex Container Registry

• Nexus

• Harbor

Эти решения обеспечивают безопасное и централизованное хранение данных, необходимых для обеспечения целостности цепочки поставок.

Валидация доказательств

Для валидации доказательств можно использовать как кастомные решения, так и готовые системы. Примеры кастомных решений включают:

• Kyverno, Gatekeeper, Policy Controller — это политики и контроллеры доступа, которые проверяют соответствие артефактов установленным требованиям безопасности.

• CRI (Container Runtime Interface) — интерфейс, через который загружаются ключи для верификации контейнеров, таких как Docker и Podman.

• Cosign — инструмент для подписи и проверки контейнеров.

Для тех, кто не хочет разрабатывать собственные системы, существует множество готовых платформ. Одним из самых удобных вариантов является использование CNAPP (Cloud-Native Application Protection Platform) — платформы для защиты облачно-ориентированных приложений. Эти платформы автоматически управляют процессами генерации, хранения и валидации доказательств, обеспечивая полный цикл защиты цепочки поставок.

Также можно обратить внимание на решения класса CSP (Content Security Platform) и ASOC (Application Security Orchestration and Correlation), которые собирают и анализируют доказательства безопасности на всех этапах разработки и развертывания программного обеспечения.

Заключение (О нашем опыте построения)

В этой статье я рассказал о ключевых технологиях, практиках и инструментах для защиты цепочки поставок программного обеспечения (SSCS). Мы обсудили важность генерации, хранения и валидации доказательств, а также рассмотрели такие решения, как in-toto, Notary, OCI-реестры и платформы для валидации.

Хотелось бы подробно объяснить, как мы применяем эти технологии в Swordfish Security, однако детализировать весь процесс с помощью 15-20 иллюстраций на Хабре было бы слишком избыточным. Поэтому, если вас заинтересовала эта тема, я рекомендую посмотреть полное видео моего доклада с конференции PHD2. В видео я подробно рассказываю, как мы внедрили эти инструменты и решения в наши проекты и как это работает.

Спасибо!