Я бы начал не с выбора между ними.

Главная ошибка — рассматривать рабочую станцию разработчика и CI/CD как два отдельных объекта защиты.

На практике они образуют одну цепочку:

developer identity → workstation → repository → pipeline → cloud role → production.

Если злоумышленник получает контроль над началом цепочки, дальнейшее продвижение может происходить через штатные механизмы.

Ему необязательно обходить защиту production. Он может изменить источник, из которого production будет автоматически обновлён.

В отчёте Google Cloud Threat Horizons H1 2026 описана именно такая последовательность. Компрометированный NPM-пакет похитил GitHub PAT разработчика. Затем атакующие получили доступ к CI/CD и через легитимное GitHub-to-AWS OIDC-доверие воспользовались чрезмерно привилегированной cloud role. Менее чем за 72 часа они получили административный доступ к AWS, извлекли данные и остановили production-ресурсы. (Google Cloud)

Можно установить лучший EDR и всё равно сохранить критический риск, если: - developer PAT обладает широкими правами; - один человек может изменить workflow и одобрить его; - pipeline получает постоянный административный доступ; - build выполняется в изменяемой среде; - signing service доверяет скомпрометированному builder; - SOC не видит repository и CI/CD telemetry; - после компрометации endpoint никто не проверяет уже выпущенные artifacts.

Можно усилить pipeline и всё равно оставить открытым путь атаки через IDE, плагины, package managers, локальные credentials и AI-инструменты разработчика.

Поэтому зрелый подход начинается не с продукта, а с attack path.

Нужно определить:

Какие разработчики и automation identities могут воздействовать на критические системы.

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

Где один субъект совмещает создание, одобрение и развёртывание.

Какой blast radius возникает после компрометации каждой точки.

Где атака должна быть остановлена независимым контролем.

Моя позиция: developer identity, workstation и CI/CD нужно относить к Tier-0 не по названию роли, а по способности изменить критические системы.

Не каждый разработчик должен проходить процедуру как администратор домена. Но любой путь, позволяющий одной скомпрометированной идентичности изменить production, требует: - phishing-resistant MFA; - управляемой developer environment; - короткоживущих workload identities; - минимальных cloud permissions; - isolated builds; - проверяемого provenance; - независимого approval критических изменений; - сквозной telemetry от repository до production.

Подписанный artifact не является безопасным, если скомпрометирована система, которая его собрала и подписала.

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

Автоматизация не является контролем, если атакующий способен изменить её правила.

Поэтому вопрос не в том, что важнее — EDR или pipeline security.

Вопрос в другом:

Где в вашем developer-to-production path находится независимая граница, которую не сможет пересечь одна скомпрометированная идентичность?