Защитите цепочку поставок ПО: Управляемый приватный реестр OVHcloud

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

Именно здесь на сцену выходит безопасность цепочки поставок программного обеспечения (Software Supply Chain Security, SSCS): она защищает не только сам код, но и процессы его сборки, доставки и использования.

Атаки вроде SolarWinds и Log4Shell — не изолированные инциденты, а тревожные сигналы, серьезность которых со временем возросла.

В этой статье блога рассматриваются рекомендуемые решения и лучшие практики для OVHcloud Managed Private Registry (MPR), реестра артефактов, совместимого со спецификацией OCI, которые помогут вам повысить безопасность вашей цепочки поставок ПО.

Генерация реестра компонентов программного обеспечения (SBOM)

SBOM предоставляет список всех компонентов (ОС, библиотеки, код) и всего, что входит в образы, которые будут запускаться в вашем кластере Kubernetes.

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

Создание SBOM вручную

Чтобы вручную сгенерировать SBOM для вашего образа, нажмите кнопку «GENERATE SBOM»:

В течение нескольких секунд в столбце SBOM для вашего образа появится статус «Queued» (В очереди), затем он сменится на «Generating» (Генерация), и появится ссылка «SBOM details» (Детали SBOM).

Нажмите на ссылку «SBOM details», чтобы просмотреть SBOM:

SBOM вашего приложения генерируется инструментом Trivy в формате SPDX. Затем этот элемент добавляется в реестр как аксессуар (accessory) для вашего образа.

Нажмите на тип аксессуара «sbom.harbor», чтобы увидеть больше деталей:

Автоматическая генерация SBOM

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

Перейдите в проект, к которому относится ваш образ, откройте вкладку «Configuration» (Конфигурация), затем поставьте галочку в чекбоксе SBOM generation (Генерация SBOM):

Сканирование на уязвимости

Мы рекомендуем запускать сканирование уязвимостей на образах, чтобы убедиться, что:

• предоставленные образы не содержат известных уязвимостей (CVE);
• заплатки безопасности корректно интегрированы перед развертыванием;
• образы, используемые в продакшене, соответствуют политикам безопасности и соответствия (compliance).

Существует несколько доступных сканеров уязвимостей, таких как Trivy, Docker Scout и Grype.

OVHcloud Managed Private Registry использует Trivy в качестве сканера уязвимостей по умолчанию, но при необходимости вы можете добавить другие сканеры. Перейдите в панель Administration (Администрирование), нажмите «Interrogation Services» (Сервисы проверки), затем откройте вкладку «Scanners» (Сканеры):

Ручное сканирование образа

Чтобы вручную запустить сканирование уязвимостей для вашего образа, перейдите в свой проект и нажмите кнопку SCAN VULNERABILITIES (СКАНИРОВАТЬ УЯЗВИМОСТИ):

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

Нажмите на ваш образ, чтобы просмотреть список CVE:

Автоматическое сканирование образа

Чтобы автоматически сканировать образы при загрузке (push), перейдите в проект, к которому относится ваш образ, откройте вкладку «Configuration» и поставьте галочку в чекбоксе «Vulnerabilities scanning» (Сканирование уязвимостей):

Планирование сканирований уязвимостей

Еще один способ быть в курсе — настроить ваш сканер уязвимостей на ежедневное выполнение проверок. Перейдите в панель Administration, нажмите «Interrogation Services», затем откройте вкладку «Vulnerability» (Уязвимости):

Вы можете выбрать периодичность сканирования: ежечасно, ежедневно, еженедельно или настроить собственное расписание.

Плановые сканирования гарантируют, что существующие образы регулярно/периодически анализируются на предмет вновь обнаруженных уязвимостей (CVE).

Запрет запуска уязвимых образов

Вы также можете настроить проект таким образом, чтобы запретить вытягивание (pull) уязвимых образов. Для этого установите флажок Prevent vulnerable images from running (Запретить запуск уязвимых образов).

Выберите уровень серьезности уязвимостей, при котором следует запрещать запуск образов, от «None» (Нет) до «Critical» (Критический).

При такой конфигурации образы нельзя будет вытянуть (pull), если их уровень серьезности равен или выше выбранного.

Эксплуатируемые уязвимости

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

В этом примере мое приложение собрано на основе golang 1.25-alpine, но Trivy обнаружил несколько CVE, которые можно эксплуатировать только в golang 1.19.1 или более ранних версиях.

Для того чтобы удалить/пропустить такие «ложные срабатывания», существует решение.

VEX (Vulnerability Exploitability eXchange) — это стандартный «формат» для указания, является ли уязвимость эксплуатируемой или нет в конкретном контексте.

Вы можете сгенерировать VEX-файл с помощью инструментов vexctl или govulncheck.

Пример:

# С помощью vexctl
$ VULN_ID="CVE-2022-27664"
$ PRODUCT="pkg:golang/golang.org/x/net@v0.0.0-20220127200216-cd36cc0744dd"
$ vexctl create --file vex.json --author 'Aurélie Vache' --product "pkg:oci/demo@sha256:$HASH?repository_url=$REGISTRY/$HARBOR_PROJECT/demo" --vuln "$VULN_ID" --status 'not_affected' --justification 'vulnerable_code_not_present' --impact-statement "HTTP/2 vulnerability $VULN_ID is not exploitable because the image is compiled with Go 1.20, which contains the patched library."

# С помощью govulncheck (для приложений на Go)
$ govulncheck -format openvex ./... > ../demo.vex.json

На данный момент OVHcloud MPR (управляемый Harbor) не поддерживает VEX-файлы (и формат OpenVEX) но это планируется в будущем.

💡Но хорошая новость в том, что вы можете настроить белый список (whitelist) CVE, указав в нем неэксплуатируемые уязвимости, чтобы игнорировать их при сканировании:

При необходимости вы можете снять флажок Never expires (Никогда не истекает) и с помощью календаря установить дату истечения срока действия белого списка.

Подписание образов

Рекомендуется подписывать ваши образы, чтобы гарантировать, что они не были изменены и происходят из вашего пайплайна (CI/CD).

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

Без подписи нет гарантии, что развернутый образ — это тот, который вы изначально собрали!

Вы можете подписывать свои образы с помощью инструментов Sigstore Cosign или Notation:

$ export HARBOR_PROJECT=supply-chain
$ export IMAGE=xxxxxx.c1.de1.container-registry.ovh.net/$HARBOR_PROJECT/demo
$ export HASH=$(skopeo inspect docker://${IMAGE}:latest | jq -r .Digest | sed "s/^sha256://")

# Подписать с помощью Cosign
## Сгенерировать приватный и публичный ключи
$ cosign generate-key-pair
## Подписать образ с использованием OCI 1.1 Referrers API
$ cosign sign -y --key cosign.key $IMAGE@sha256:$HASH 

# Подписать с помощью Notation
## Сгенерировать RSA ключ и самоподписанный тестовый сертификат X.509
$ notation cert generate-test --default "test"

## Подписать образ с использованием OCI 1.1 Referrers API
$ export NOTATION_EXPERIMENTAL=1 ; notation sign -d --allow-referrers-api ${IMAGE}@sha256:${HASH}

Вы можете использовать Cosign или Notation для подписи своих образов, OVHcloud MPR поддерживает оба инструмента.

Ваша подпись появится рядом с вашим образом как аксессуар, а также зеленая галочка ✅ в вашей колонке:

⚠️ Имейте в виду, MPR (Harbor) не поддерживает подписи, сгенерированные Cosign v3 (подпись загрузится и появится как аксессуар, но метка останется красной вместо того, чтобы стать зеленой). Эта ошибка должна быть исправлена в Harbor 2.15 💪.

Подписывать свои OCI-артефакты и привязывать их к образам рекомендуется, и вы можете сделать это с помощью Cosign:

$ cosign attest -y --predicate sbom.spdx.json --key cosign.key $IMAGE@sha256:$HASH

Они будут загружены в приватный реестр OVHcloud и отображены как аксессуары.

Обеспечьте, чтобы в проекты вашего реестра отправлялись только проверенные образы

Чтобы разрешить развертывание в проекте только проверенных/подписанных образов, нажмите на проект, в котором находится ваш образ, перейдите на вкладку «Конфигурация» и отметьте галочку Cosign и/или Notation:

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

Неизменяемость тегов (Tag immutability)

По умолчанию теги являются изменяемыми (мутабельными). Это означает, что вы можете отправить образ demo с тегом 1.0.0, внести изменения в код и отправить его снова с тем же тегом.

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

Более того, в Harbor (а значит, и в OVHcloud MPR) из-за ограничений вышестоящей спецификации OCI Distribution реестр не обеспечивает строгой связи между тегом и дайджестом образа.

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

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

Для этого нажмите на ваш проект, затем на вкладку Политика (Policy) и выберите НЕИЗМЕНЯЕМОСТЬ ТЕГОВ (TAG IMMUTABILITY):

Затем нажмите кнопку ДОБАВИТЬ ПРАВИЛО (ADD RULE).

Заполните списки репозиториев и тегов в соответствии с вашими потребностями.

Пример:

⚠️ Вы можете добавить максимум 15 правил неизменяемости на проект.

В заключение

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