Использование Valint для применения политик к вашему SDLC

Valint — основной инструмент Scribe для создания, управления, подписания и проверки доказательств. В предыдущей публикациимы рассмотрели теорию использования подписи и проверки доказательств в качестве основного инструмента проверки безопасности вашего конвейера CI/CD. Напоминаем, что предлагаемая модель Scribe включает в себя несколько строительных блоков, которые можно перемешивать и складывать так, как вам удобно. Строительные блоки включают собранные доказательства (SBOM, SLSA происхождение, любые результаты сторонних испытаний, которые вы хотите включить), экологический контекст собранных доказательств (кто их создал, где, когда и т. д.), а также политику, которую вы хотите применить к этим доказательствам.

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

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

Начните здесь: подписание и проверка доказательств

Валинт это очень универсальный инструмент, но для простоты этой статьи в качестве примера мы будем использовать главным образом интерфейс CLI Valint.

Первым шагом будет загрузка Valint:

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

Команда для создания SBOM из репозитория или образа — «bom». Так, например, если вы хотите bom образ busybox:latest команда будет выглядеть так:

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

Обратите внимание, что attest это псевдоним для attest-cyclonedx-json.

По умолчанию Валинт использует Сигстор интерактивный поток как движок механизма подписи, встроенный в библиотеку Scribe Cocosign. Эта библиотека занимается цифровыми подписями для подписания и проверки. После применения команды вам необходимо сначала подтвердить свое желание подписать свидетельство с помощью опции Да/[Нет]:

Вы также можете использовать для подписи стандартный PKI (мы поддерживаем сертификаты x509). Существует несколько вариантов хранения ключа подписи — например, KMS, секретное хранилище GitHub, и вы можете легко настроить Valint для использования любого механизма подписи, который вы пожелаете.

Если вы одобрите подпись, вы будете перенаправлены в Sigstore в своем браузере, где вам нужно будет войти в систему, используя свою учетную запись GitHub, свою учетную запись Google или свою учетную запись Microsoft:

После входа в систему вы увидите, что вход прошел успешно:

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

Аттестация по умолчанию записывается в локальный кэш, местоположение которого предоставляется --output-directory флаг в файле конфигурации flag. Вы также можете использовать -выходной файл флаг, чтобы указать собственный путь для аттестации.

Теперь, когда мы создали подписанное свидетельство, давайте попытаемся убедиться, что оно существует и подписано. Команда для проверки доказательств: verify. Способ использования практически идентичен bom команда, за исключением того, что мы будем использовать флаг -iчто является сокращением от --input-format и значение по умолчанию для него, как в bom, attest-cycledx-json. Команда проверки сначала будет искать необходимые доказательства в расположении по умолчанию, используемом Valint. Вы можете указать другое место, если хотите сохранить улики и найти их позже.

Итак, если мы хотим проверить busybox:latest Подтверждение изображения, которое мы сгенерировали и подписали в предыдущем примере, команда будет выглядеть так:

$HOME/.scribe/bin/valint verify busybox:latest -i attest

Если вы все сделали правильно, результат должен выглядеть так:

Вы можете просмотреть список электронных писем, включающий адрес электронной почты подписывающего лица в исходном подтверждении, а также увидеть тип проверенного подтверждения, в данном случае cycledx-json. 

Кажется довольно простым, не так ли? Давайте поднимем это на ступеньку выше.

Шаблоны политик

A и политика состоит из набора модули. Политика проверена, если все входящие в нее модули оценены и проверены. Модуль проверяется, если обнаружено ЛЮБОЕ свидетельство, соответствующее конфигурации и настройкам модуля.  

Политики настраиваются как часть файла конфигурации Валинта в разделе политик. Это пример части файла конфигурации Valint, части, содержащей потенциальные политики. 

Помните, что вам не обязательно включать файл конфигурации в ваш проект — Valint может прекрасно работать только с включенными параметрами по умолчанию. Кроме того, поскольку все в этом файле не является обязательным, вполне допустимо иметь такой файл, включающий ТОЛЬКО ваши политики. 

Файл конфигурации, называемый по умолчанию .valint.yaml, должен быть включен в корень вашего репозитория. В зависимости от политик, которые вы включаете в этот файл, при запуске команды valint verify он будет запускать любые включенные политики и модули. Поскольку базовая политика проверки используется по умолчанию, вам не нужно ничего настраивать для verify команда работает правильно даже без файла .valint.yaml.

Какую бы политику вы ни добавили в файл конфигурации, это зависит от наличия доказательств, которые нужно искать. По умолчанию, когда вы запускаете команду bom в своем конвейере, полученные доказательства будут загружены в хранилище доказательств Scribe. Аналогичным образом, когда вы запускаете команду «verify», она будет искать доказательства в хранилище доказательств Scribe. Вы можете изменить это значение по умолчанию и использовать OCI или кэш в качестве хранилища доказательств, но в этой статье мы предполагаем, что используется значение по умолчанию, и все доказательства загружаются и извлекаются из хранилища доказательств Scribe.

Итак, на основе этого примера давайте рассмотрим составляющие политики. и политика поддерживает следующие поля:

• имя, имя политики (обязательно).
• включить, включите модуль (по умолчанию — false).
• модули, список конфигураций модуля политики.  

 

Команда модуль разделы поддерживают следующие поля:

• имя, имя модуля политики (обязательно).
• включить, включите модуль (по умолчанию — false).
• напишите, тип модуля, поддерживающего в данный момент проверка-артефакт и git-владелец.
• совпадение, сопоставьте доказательства с конкретным контекстом.
• вход, конфигурация для конкретного модуля.

Политика может иметь несколько модулей, и все включенные модули будут запущены после выполнения команды «verify». 

Поскольку я знаю, что сухой список полей не очень информативен, давайте сразу перейдем к следующему разделу — примерам политик.

Примеры политик

Политика проверки изображений

Начнем с самой простой политики, которая выражает поток проверки подписи Valint. 

attest: cocosign: политики: - имя:verify_policy включить: true модули: - имя: Signed_sbom тип: проверить-артефакт включить: true ввод: подписано: true формат: attest-cycledx-json идентификатор: электронные письма: - barak@scribesecurity.com

Опять же, эта политика должна быть включена в файл .valint.yaml в корне вашего репозитория. Чтобы это работало, вам необходимо заранее создать подписанный SBOM, запустив команду valint bom команда. Когда вы будете готовы это проверить, вам нужно будет запустить valint verify команда.

Глядя на этот пример, мы видим, что политика включена и что у нее есть один включенный модуль типа ‘verify-artifact‘. Модуль проверяет, что ввод подписан, имеет формат ‘attest-cyclonedx-json’, и что оно было подписано личностью, представленной в электронном письме ‘barak@scribesecurity.com’.

Чтобы запустить эту политику, нам нужно выполнить команду verifyкоманда в нашем конвейере следующим образом:

valint verify busybox:latest

С verify команда теперь основана на предоставленной нами политике и будет искать busybox:latest часть доказательства в вашем хранилище доказательств Scribe. Он будет искать подписанный SBOM формата `cyclonedx-json` и он проверит, что личность, подписавшая SBOM, использует адрес электронной почты, указанный в политике. `barak@scribesecurity.com`.

Вы можете сказать, что в этом хранилище улик может быть несколько таких изображений, и будете правы. Здесь в игру вступает контекст. По умолчанию, verify Команда будет искать ближайшее доступное совпадение. Однако вы можете указать, что команда должна соответствовать контексту идентификатора запуска конвейера или системе сборки, в которой был создан артефакт. Для этого вам нужно будет использовать поле match: с соответствующим типом контекста. Например:

            совпадение: context_type: github git_url: github.com/my_org/myimage.git ветка: основная

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

Политика двоичной проверки

Давайте рассмотрим другой пример. Эта политика предназначена для проверки того, что проверяемый нами exe-файл поступил из определенного репозитория и был подписан одним из нескольких известных лиц. 

attest: cocosign: политики: - имя:verify_policy включить: true модули: - имя: тип двоичного_модуля: проверить-артефакт включить: true ввод: подписано: true формат: attest-cycledx-json идентификация: электронная почта: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # Git URL-адрес среды. имя_входа: my_binary.exe

Глядя на этот пример, мы видим, что политика включена и что у нее есть один включенный модуль типа ‘verify-artifact‘ Модуль проверяет, подписан ли ввод, соответствует ли он формату ‘attest-cyclonedx-json’, и что оно было подписано одним из трех разрешенных адресов электронной почты, перечисленных в модуле. Кроме того, он проверяет, что verify команда получает входные данные для проверки того, что входные данные имеют имя ‘my_binary.exe’, что входные данные — это файл, созданный в Azure и полученный с определенного URL-адреса git: https://dev.azure.com/mycompany/somerepo.

Как видите, в этом примере гораздо больше требований для проверки политики.

Чтобы запустить эту политику, нам нужно выполнить команду verify команда в нашем конвейере следующим образом:

valint verify file:my_binary.exe

Чтобы убедиться, что в вашем хранилище доказательств Scribe имеется подписанная версия этого двоичного файла, вам следует сначала создать доказательства следующим образом:

valint bom file:my_binary.exe -o attest

Политика проверки доказательств третьих лиц

В нашем последнем примере давайте посмотрим, как мы можем проверить, что используемый нами сторонний инструмент правильно работает в нашем конвейере и создает ожидаемый результат в виде файла JSON. 

аттест: cocosign: политики: - имя:verify_policy включить: true модули: - имя: тип стороннего правила: проверка-артефакт включить: истина ввод: подписано: ложь формат: аттестованное общее удостоверение: электронная почта: - bob@scribesecurity. com match: target_type: общий context_type: azure git_url: https://dev.azure.com/mycompany/somerepo git_branch: main input_name: 3rd-party-scan.json

В этом примере мы представляем, что в какой-то момент конвейера мы запустили сторонний инструмент, который в результате создал файл `3rd-party-scan.json`. Чтобы соответствовать политике, этот файл должен был быть создан из Azure DevOps, инициирован `https://dev.azure.com/mycompany/somerepo`репозиторий и подписан `bob@scribesecurity.com`. 

Чтобы создать доказательства, которые мы ищем, сразу после запуска стороннего инструмента нам нужно захватить полученный файл и превратить его в доказательства с помощью Valint:

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

Что доказывают доказательства? 

Итак, мы увидели, что можем использовать Valine для проверки различных вещей в нашем конвейере. Для чего действительно можно использовать эту способность?

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

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

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