Управление уязвимостями контейнеров для неразработческих организаций

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

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

Для правильного управления этим, как организация-разработчик, вы бы извлекали Dockerfile для вашего базового образа и создавали образ самостоятельно, включая сканирование уязвимостей, SCA и SAST. Этот образ хранится в вашем собственном реестре, и вы используете его как базовый.

Существует ли другой способ, который не включает в себя запуск собственного реестра, перестройку всех образов самостоятельно и их развертывание?

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

1. Попросить владельца образа обновить его (либо подав заявку на открытом проекте, либо связавшись с поставщиком коммерчески поддерживаемых образов).
2. Обновить образ самостоятельно.
3. Перейти на лучше поддерживаемый образ, который предоставляет те же возможности.

Для варианта 2 вам не нужно запускать полностью свой собственный реестр, вы можете просто получить аккаунт в реестре, таком как Docker Hub, и затем клонировать/исправлять образы в этом аккаунте.

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

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

Начните с управления поставщиками. Когда вы используете какие-либо произведенные извне продукты, вам нужно понять, кто их производит. Есть ли у поставщика политики и процедуры для снижения рисков? Имеют ли они контроль над тем, кто может вносить изменения в проекты с открытым исходным кодом? Сканиуют ли они и устраняют уязвимости? Взаимодействует ли поставщик с пользователями или имеет ли сообщество пользователей, которое поддерживает друг друга? Предпочитайте продукты, у которых есть такого рода контроль.

Рассмотрите возможность хранения локальных копий артефактов, чтобы смягчить неожиданные изменения или ошибки. Это выходит за рамки уязвимостей, но охватывает более широкие проблемы цепочки поставок, где версия может быть неожиданно удалена из внешних репозиториев, или ссылка на версию может привести к несообщённым/недокументированным изменениям. Это касается всего, от проектов с открытым исходным кодом до контейнеров и пакетов. Хранение собственного репозитория артефактов на вашей инфраструктуре требует поддержки ИТ, но также существуют и SaaS-решения.

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