По мере того, как все становятся все более осведомленными, защита ваших цепочек поставок программного обеспечения должно быть жизненно важной частью стратегии кибербезопасности каждой организации.
Одной из основных трудностей в создании комплексной стратегии по снижению угроз в цепочках поставок программного обеспечения является сложность и разнообразие цепочек поставок. Каждая цепочка поставок уникальна, и ее элементы постоянно меняются, что затрудняет доверие к собственной цепочке поставок, не говоря уже о программном обеспечении, которое она производит.
В этой статье мы опишем платформу непрерывного соответствия требованиям, которая позволяет потребителям и производителям программного обеспечения прозрачно демонстрировать доверие и соответствие требованиям для защиты SDLC, продвигать передовые методы обеспечения безопасности, соблюдать нормативные требования и смягчать последствия. киберриски через aтесты.
Предлагаемая нами модель состоит из наборов блоков, которые можно легко расширить и интегрировать в ваш стек, независимо от предпочитаемой вами платформы или вариантов использования. Мы закончим демонстрацией базовой политики проверки, используя Инструмент Scribe's Valint чтобы показать, что этот процесс не так сложен, как вы могли сначала подумать.
Теория хаоса в цепочке поставок
Одной из основных проблем в обеспечении безопасности цепочек поставок является явная сложность задействованных систем. Ваша цепочка поставок программного обеспечения включает в себя каждую часть программного обеспечения, участвующую в создании вашего конечного продукта, либо как часть среды, либо как часть программного обеспечения, интегрированную в вашу кодовую базу. По этому описанию вы можете сказать, что эти цепочки поставок обширны и включают в себя все, начиная с момента, когда разработчик начинает писать код, вплоть до компиляции, тестирования, интеграции и до момента, когда конечный продукт запускается и включает в себя каждую часть программное обеспечение и библиотеки, используемые в ходе работы.
Определение модели безопасности для таких систем требует понимания широкого спектра программных средств. языки, менеджеры пакетов, продукты, стеки технологий, службы CI, облачные провайдеры, импорт зависимостей, виртуальные машины, операционные системы и другие компоненты, которые могут быть включены в данную цепочку поставок. Очень важно учитывать широкий спектр активов, которые могут подвергаться риску в такой системе, включая приложения, токены, ключи и другие формы разрешений доступа.
Обзор модели проверки политик
Предлагаемая нами модель включает в себя несколько строительных блоков, которые работают вместе, обеспечивая безопасность и соответствие требованиям цепочки поставок.. Эти стандартные блоки необходимы для постоянной проверки аспектов безопасности программного обеспечения и соблюдения правил цепочки поставок программного обеспечения.
- Доказательства: Неизменяемые объекты, которые предназначены для автоматического использования политиками. Эти объекты содержат метаданные, необходимые для обеспечения применения политики и соблюдения требований соответствия. Содержимое доказательств включает метаданные об артефактах, событиях и настройках, но также может собирать фактические отчеты, конфигурации или сканирования.
Доказательства может иметь как подписанную, так и неподписанную форму. Мы предлагаем следовать за iн-тото спецификация аттестации используя подписанный засвидетельствование и без подписи заявлении форматы соответственно.- Аттестации (также известные как проверяемые подписанные доказательства): Поддающиеся проверке доказательства, связанные с конкретным экологический контекст, передавая доверие с помощью той или иной формы подписей PKI.
- Экологический контекст: контекстная информация связывает модель воедино.
Оно отвечает на вопрос, откуда берутся доказательства и какую информацию они содержат. Важно, чтобы контекст был связан с доказательствами, а не был их частью, поскольку вы можете иметь несколько фрагментов доказательств, связанных с одним и тем же контекстом, и эта модель позволяет упростить и повысить эффективность поиска и извлечения доказательств.
Проще говоря, контекст окружающей среды — это система маркировки, в которой большая часть меток считывается из окружающей среды, платформы или артефактов. Метки обеспечивают нормализованный доступ ко многим процессам вашего процесса разработки и конвейеру CI/CD. Аспекты, связанные с происхождением доказательств, таких как репозитории Git, теги и коммиты, а также имена рабочих процессов, имена заданий, runID и т. д. Контекст среды также может включать аспекты объекта, такие как хэши артефактов, имена и теги.
Контекст можно рассматривать как расширение in-toto. Спецификация аттестации, интегрированный в подписанную полезную нагрузку. Используя систему маркировки, мы можем предоставить на этапе оценки политики возможность запрашивать доказательства по маркировке в различных аспектах. Кроме того, контекстные данные могут использоваться как часть процесса оценки политики, добавляя к фактическим данным «ситуационную осведомленность».
- политика: Набор настраиваемых пользователем модулей политики, которые определяют необходимый отчет о соответствии. Политики могут определять минимальные стандарты безопасности или требуемые уровни соответствия для различных типов продуктов или систем, включенных в ваш конвейер сборки или процесс разработки. Самое главное, что в результате оценок политики создаются отчеты о соблюдении, которые аттестаты также. Это позволяет нам не только управлять отчетами о соответствии (например, раскрывать ваш статус соответствия заинтересованным сторонам), но также использовать отчет о соответствии для более сложных политик, которые могут инкапсулировать более широкий объем регулирования соответствия для организации. Политики можно сгруппировать в модули политики. Это плагины, которые реализуют наборы правил политики, имеющих некоторые общие характеристики (аналогично программным модулям). Эти плагины предоставляются поставщиками политик (подробнее об этом позже).
Оценка модуля политики дает результаты, которые включают оценки, сведения о соответствии и вердикты, относящиеся к рассматриваемому регулированию безопасности. Кроме того, результаты включают в себя историю доказательств, необходимых для возврата модуля доказательств, оцененного на предмет соответствия. - Магазины: Службы, предоставляющие хостинг, возможность загрузки/выгрузки и запроса доказательств (подробнее об этом позже). Их можно использовать в реестрах образов (OCI в качестве хранилища), специализированных службах (например, Scribe Service) или просто в локальной файловой системе.
- Поставщики политик: Это субъекты (компании, организации), ответственные за подписание и предоставление модулей политики. Предоставляя политики в качестве типа подтверждения, поставщики придают самой политике доверие и прозрачность. Например, аттестация пакета OPA может дать регулирующим органам возможность публиковать и подписывать официальные пакеты OPA, реализующие модули политики.
Используя эти строительные блоки, наша модель позволяет организациям относительно легко проверять безопасность и соответствие своих конвейеров сборки и жизненного цикла разработки.
Как это работает
Отправной точкой этого рабочего процесса является разработчик или система, генерирующая доказательства для программного продукта или компонента. Содержание доказательств, а также контекстная информация, субъекты и подписи собираются и загружаются в хранилище доказательств.
С другой стороны, отчеты о соответствии создаются путем оценки политик, соответствующих потребностям и требованиям организации.
Используя контекстную информацию, оценки политики могут запросить доказательства, полученные в вашей цепочке поставок, и убедиться, что они содержат всю информацию, которую может потребовать регулирование..
Дополнительным преимуществом является то, что отчеты о политиках и соблюдении требований сами по себе доступны в качестве доказательств, что обеспечивает прозрачность и доверие, а также позволяет отслеживать историю всех задействованных доказательств. Это позволяет организациям управлять отчетами о соответствии требованиям, а также использовать их в качестве надежных аттестаций, чтобы передать доверие потребителям программного обеспечения..
Используя этот поток, организации и заинтересованные стороны могут снизить риски, обеспечить прозрачность и соблюдение требований в своей цепочке поставок, уменьшая влияние хаоса и повышая общую безопасность и доверие к своим продуктам.
Оценка политики
Команда оценка политики осуществляется путем проверки набора модулей политики, каждый из которых соответствует конкретным правилам и требованиям соответствия.
Оценка политики задает каждому модулю два простых вопроса:
- Какие доказательства необходимы для соответствия модулю?
- Каковы критерии доказательства соответствия?
Например, в контексте Структура SLSA (уровни цепочки поставок для программных артефактов)Модули политики могут указать, что подписанное свидетельство происхождения SLSA и сканирование состояния безопасности для конвейера сборки необходимы для соответствия требованиям безопасности. Доказательства, предоставленные этими модулями, затем будут проверены на предмет соответствия всем требованиям SLSA.
- Какие доказательства необходимы для соблюдения требований SLSA?
- Подтверждение происхождения SLSA (подписанное свидетельство) артефакта сборки.
- Сканирование состояния безопасности конвейера CI, создающего артефакт.
- Каковы критерии доказательства соответствия требованиям SLSA?
- Оба доказательства должны включать информацию, соответствующую всем требованиям SLSA.
В этом примере аттестация происхождения SLSA должна полностью описать процесс сборки образа, а аттестация состояния безопасности должна подтвердить, что SCM, в котором хранился источник образа, использует правила защиты ветвей.
- Оба доказательства должны включать информацию, соответствующую всем требованиям SLSA.
Другим примером модуля политики является Проверьте модуль артефакта, который указывает, что некоторые артефакты должны быть подписаны доверенным источником. Использование аттестатов (проверяемое подписанное доказательство) Подпись PKI (инфраструктура открытых ключей) для удовлетворения требований определенного лица/субъекта, которому необходимо подписать артефакты, а также подтвердить контекст происхождения артефактов.
Команда Проверьте модуль артефакта отвечает на следующие вопросы:
1. Какие доказательства необходимы для демонстрации соблюдения требований безопасности?
- Доказательства, описывающие артефакт, включающие подпись PKI (аттестацию).
2. Как можно проверить эти доказательства для обеспечения соответствия?
- Подпись PKI аттестации действительна.
- Идентичность сертификата PKI соответствует требованиям пользователя.
- Тематика доказательств соответствует требованиям пользователя.
- Формат и происхождение соответствуют требованиям пользователя.
От теории к практике
Давайте углубимся в реализацию этой модели, которая в настоящее время поддерживается инструментом Valint.
Давайте рассмотрим простой пример политики, которая определяет, как проверять подписи и происхождение изображения.
В частности, нам необходимо убедиться, что доказательства удовлетворяют следующим критериям:
- Тип доказательства — это аттестация CycloneDX SBOM, описывающая изображение.
- Артефакт подписан mycompany.com.
- Изображение получено в результате рабочего процесса Circle-CI, инициированного my_image_src Сделки РЕПО.
Политика шаблонов
В предыдущем примере политика была статической и проверялась только для определенного изображения с именем моякомпания/мое_изображение. Однако зачастую предпочтительнее иметь политики, поддерживающие возможности шаблонов и переменных. Это позволяет вам определить требования, которые можно применять к множеству аналогичных процессов или артефактов в вашем конвейере сборки CI/CD.
Чтобы создать шаблон политики, вы можете использовать переменную вместо статической привязки политики к продукту. В приведенном выше примере вы можете изменить имя_артефакта значение для `$MY_IMAGE` вместо этого позволяя оценщикам настраивать одну политику для множества изображений, требующих одних и тех же правил соответствия.
«Взгляд вперед» в соавторстве с Кеннетом Кейсом,
At ПисецНаша конечная цель — снизить риски в цепочке поставок с помощью поддающейся проверке модели соответствия, основанной на фактических данных. Одним из первых мест, где можно опробовать эту модель, является конвейер сборки CI/CD. Мы считаем, что такой подход, основанный на проверке доказательств, является ключом к обеспечению прозрачности и подотчетности в цепочке поставок, принося пользу всем заинтересованным сторонам. Наша модель воплощает в себе многие из новых идей в сообществе цепочек поставок программного обеспечения, определяя взаимосвязь между многими из них. Мы стремимся к инновациям и повышению прозрачности цепочки поставок программного обеспечения. Если эта модель заинтересовала вас, я советую вам ознакомиться с нашим Документация Valint CLI где мы расширяем возможности и использование инструмента. Не стесняйтесь попробовать.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
