Когда злоумышленники скомпрометировали популярное действие tj-actions/changed-files, в сообществе начали активно рекомендовать фиксацию SHA-хэшей, ограничение разрешений токенов и ручной обзор workflow. Эти советы верны, но они решают проблему лишь частично. Главный недостаток подхода с фиксацией хэшей стал очевиден: он защищает только в том случае, если зафиксированная версия изначально не содержит вредоносного кода. Если атака уже присутствует в закреплённом коммите, то SHA-пиннинг обеспечивает детерминированность, но не безопасность.
С распространением AI-агентов для написания кода эта проблема приобрела новые масштабы. Модели часто предлагают два полярных подхода к безопасности CI: либо минималистичные исправления вроде фиксации хэшей, либо комплексные enterprise-решения с усиленными раннерами, аттестациями, контролем исходящего трафика и дополнительными джобами. Первый вариант оставляет систему уязвимой, второй — создаёт непомерную операционную нагрузку для обычного проекта.
Поиск баланса между безопасностью и сложностью
Типичный сценарий выглядит так: разработчик просит AI-агент предложить «минимальное безопасное исправление», и в ответ получает всё те же рекомендации по SHA-пиннингу и базовому ограничению разрешений. Хотя это лучше, чем ничего, такой подход не меняет фундаментальный риск — если действие уже скомпрометировано, его выполнение приведёт к негативным последствиям независимо от фиксации версии.
Возник закономерный вопрос: существует ли архитектура CI/CD, которая действительно сдерживает последствия запуска вредоносного действия, не требуя при этом реализации полноценного корпоративного стека безопасности? Целью стало найти решение, которое значительно сокращает радиус поражения при компрометации, но не добавляет существенных операционных затрат.
Бенчмарк для оценки архитектур CI
Чтобы получить объективные данные, а не строить предположения, был создан воспроизводимый бенчмарк. Его ключевой принцип — изменение только одной переменной: архитектуры workflow. Все остальные компоненты остаются постоянными:
- Репозиторий с исходным кодом
- Исходный файл, который должен обрабатываться
- Специально созданное вредоносное действие, имитирующее компрометированное
- Платформа GitHub Actions
Таким образом, можно объективно сравнить, как разные архитектуры CI справляются с одной и той же угрозой. Бенчмарк запускает идентичное вредоносное действие в четырёх различных конфигурациях workflow, фиксируя, какая из них действительно предотвращает или ограничивает ущерб.
Архитектурные подходы к изоляции
Первая и самая распространённая архитектура — прямой вызов действия из workflow. В этом случае скомпрометированное действие выполняется в том же контексте, что и основные шаги сборки, получая доступ ко всем секретам, артефактам и разрешениям workflow. SHA-пиннинг здесь не помогает, если вредоносный код уже присутствует в зафиксированной версии.
Вторая архитектура использует составные действия (composite actions) в качестве прослойки. Хотя это добавляет уровень абстракции, изоляция остаётся минимальной — вредоносное действие по-прежнему выполняется в основном раннере с доступом к критическим ресурсам.
Третий подход предполагает запуск потенциально опасных действий в изолированных контейнерах через Docker. Это создаёт более чёткие границы: действия выполняются в отдельной среде с ограниченным доступом к файловой системе и переменным основного workflow. Однако настройка требует дополнительных усилий, а производительность может снизиться из-за необходимости сборки и запуска контейнеров.
Четвёртый вариант использует отдельные репозитории для действий с запуском через repository_dispatch или Reusable Workflows. Это обеспечивает максимальную изоляцию, поскольку потенциально опасный код выполняется в совершенно отдельном контексте, с собственными секретами и разрешениями. Компрометация такого действия не даёт автоматического доступа к ресурсам основного проекта.
Практические рекомендации для проектов
Результаты бенчмарка показывают, что оптимальный баланс между безопасностью и сложностью достигается при использовании контейнеризации для сторонних действий. Docker-контейнеры обеспечивают достаточную изоляцию, чтобы сдержать большинство атак через компрометированные действия, при этом не требуя радикального изменения существующих процессов.
Для особо критичных проектов или организаций с высокими требованиями безопасности стоит рассмотреть архитектуру с выносом потенциально опасных операций в отдельные репозитории. Хотя это добавляет операционные сложности, такой подход минимизирует риск распространения атаки на основные производственные системы.
AI-агенты пока не способны учитывать все нюансы архитектурной безопасности CI/CD. Их рекомендации часто сводятся к шаблонным решениям, которые либо недостаточны, либо избыточны для конкретного проекта. Осознанный выбор архитектуры workflow, учитывающий реальные риски и операционные возможности, остаётся задачей, требующей человеческого экспертизы и понимания контекста.