В марте 2026 года экосистема Trivy пережила supply chain-инцидент. Согласно официальному advisory компании Aqua Security, злоумышленник использовал скомпрометированные учетные данные для публикации вредоносного релиза Trivy v0.69.4, перепривязки большинства тегов trivy-action к credential-stealing malware и замены тегов setup-trivy. Позднее были опубликованы и вредоносные Docker Hub образы v0.69.5 и v0.69.6.
Практический смысл этого кейса заключается в том, что компрометация затронула не один контейнерный образ, а сразу несколько официальных каналов доставки. Для команды разработки из этого следует неприятный, но важный вывод: внешний security-инструмент не становится доверенным только потому, что он популярен, официально поддерживается или связан с безопасностью.
Как работала атака
Самая показательная часть инцидента — механика с trivy-action. Если пайплайн ссылался на action по тегу, workflow продолжал выглядеть штатно, но до запуска легитимного шага выполнялся вредоносный код. В этом случае вредоносный код попал в CI/CD не из-за ручной загрузки подозрительного файла, а через штатный канал поставки, которому обычно доверяют по умолчанию.
Именно поэтому этот кейс относится не только к классической ИБ, но и напрямую к AppSec и DevSecOps. Под угрозой оказываются не только контейнеры или бинарные файлы как таковые, но и весь доверительный контур вокруг автоматизации: шаги анализа, токены CI/CD, доступы к внутренним реестрам, правила обновления инструмента и права среды выполнения.
Что стоит сделать прямо сейчас
Проверить, не использовались ли внешние артефакты Trivy по плавающим тегам, а также не было ли автоматического потребления latest или аналогичных ссылок на релиз.
Если подозрительная версия или внешний шаг уже запускались, исходить из предположения, что среда выполнения могла быть скомпрометирована: перевыпустить секреты, отозвать токены, проверить сетевую активность и журналы, при необходимости пересоздать раннеры.
Зафиксировать правило, что для критичных security-инструментов нужен отдельный процесс обновления: приемка релиза, проверка изменений, пилот в карантинном контуре и только после этого тиражирование в рабочий контур.
Пересмотреть модель доверия конвейера. Внешний инструмент должен рассматриваться как потенциально недоверенный до тех пор, пока не подтверждены его происхождение, способ сборки, состав и возможность безопасного применения в рабочей среде.
Какие выводы важны именно для DevSecOps
Из этого инцидента следует один особенно неприятный вывод. Даже хороший сканер уязвимостей, action для проверки кода или toolchain-компонент могут стать точкой проникновения в доверенный контур. Поэтому в центре внимания должны быть не только сигнатуры атак или репутация вендора, но и политика допуска артефактов в CI/CD.
Если говорить коротко, то зрелая модель выглядит так: не доверять внешнему каналу по умолчанию, минимизировать привилегии среды выполнения, проверять происхождение и целостность артефакта, изолировать раннер, ограничивать исходящие соединения и контролировать порядок обновления security-инструментов. Именно такая логика и легла в основу нашей целевой модели защиты в Apsafe.
Как мы защитились в Apsafe
Apsafe — это сервис непрерывного анализа защищенности приложений, который помогает встроить практики безопасной разработки в рабочий процесс команды. Поскольку сервис работает с исходными артефактами, результатами сканирования и другой служебной информацией, для нас критично не только качество самого анализа, но и безопасность всего контура обработки данных. Именно поэтому в Apsafe отдельное внимание уделяется контролю происхождения инструментов, защите среды выполнения и снижению рисков, связанных с компрометацией цепочки поставки.
В Apsafe защита от такого класса инцидентов строится не вокруг одной проверки, а вокруг набора независимых барьеров. Мы исходим из того, что компрометация внешнего инструмента, тега или релизного канала — это не экзотика, а нормальный сценарий модели угроз для безопасной разработки.
Первый уровень защиты — это контролируемый внутренний реестр и внутренний выпуск образов. Мы не тянем чувствительные инструменты напрямую из внешнего публичного реестра в рабочий контур. Образ сначала принимается во внутренний процесс сборки и проверки, после чего попадает во внутренний registry. Для критичных инструментов сборка выполняется из исходников конкретного тега или коммита, а не из готового внешнего образа.
Второй уровень — строгая идентификация артефакта. В пайплайнах используется не плавающий тег, а конкретный digest. Это исключает сценарий, при котором под тем же именем в реестре внезапно появляется уже другое содержимое. Дополнительно внутренний образ подписывается доверенным релизным процессом, а перед использованием его подпись проверяется политикой допуска.
Третий уровень — подтверждение происхождения. Для нас важно не только знать, какой именно digest используется, но и понимать, откуда он появился. В целевой модели для каждого критичного образа сохраняется проверяемая связка:
репозиторий -> коммит -> pipeline -> итоговый digest образа
Это позволяет утвердить, что артефакт выпущен нашим доверенным контуром сборки, а не появился в реестре неизвестным способом.
Четвертый уровень — ограничение масштаба последствий в среде выполнения. Для каждого проекта под задачу создается отдельный раннер, который уничтожается после завершения работы. Сетевое взаимодействие ограничивается белыми списками, чтобы даже при исполнении вредоносного кода у него не было свободного канала вывода данных наружу. В раннере применяется модель минимальных привилегий: задаче доступны только необходимые права и секреты, а чувствительные учетные данные выдаются временно.
Пятый уровень — контроль изменений в CI/CD. Для такого класса рисков недостаточно только правильно собирать образ; нужно еще и контролировать, кто и как меняет логику его использования. Изменения .gitlab-ci.yml, смежной CI/CD-конфигурации, параметров сборки и правил подключения новых репозиториев проходят через контролируемый процесс согласования.
Шестой уровень — безопасное обновление security-инструментов. Обновление не должно автоматически попадать в продуктивный контур в день релиза. В Apsafe новая версия сначала попадает в выделенный карантинный процесс: сборка, проверка изменений, пилотный прогон на тестовом наборе репозиториев и только после этого решение о тиражировании в основную эксплуатацию.
Седьмой уровень — готовность к инциденту. Если подозрительная версия инструмента все же была запущена, у нас предусмотрен отдельный порядок реагирования: отзыв и перевыпуск секретов, анализ журналов, проверка сетевой активности, пересоздание затронутых раннеров и связанных систем. В кейсах, затрагивающих цепочку поставок, важно не только предотвратить компрометацию, но и быстро локализовать последствия, если она все-таки произошла.
Почему это важно для заказчиков
Для заказчика смысл этой модели заключается не в том, что сервис обещает абсолютную неуязвимость. Правильнее сформулировать обещание иначе: даже если внешний security-инструмент скомпрометирован, он не должен автоматически получить доверие, широкие полномочия и свободный выход во внешний мир. Чем больше независимых барьеров между внешним артефактом и рабочим контуром, тем ниже вероятность критического инцидента.
Именно поэтому история с Trivy для нас важна не как повод для тревоги, а как проверка правильности архитектурного подхода. Этот кейс еще раз подтверждает, что в безопасной разработке недостаточно выбрать хороший сканер. Нужно выстроить контролируемую цепочку приемки, запуска, обновления и изоляции таких инструментов.
Подведем итог
Компрометация Trivy — это наглядный пример того, что trusted-looking channel не равен trusted channel. Если инструмент или шаг автоматизации приходит из внешнего мира, к нему должна применяться такая же zero trust-модель, как и к любой другой внешней зависимости.
Для DevSecOps уже недостаточно сводить реакцию к обновлению сканера после инцидента. Требуется контролировать происхождение, выпуск, запуск и полномочия security-инструмента. В Apsafe мы исходим именно из такой модели: внутренний выпуск, контроль происхождения, неизменяемые идентификаторы, подпись и проверка артефактов, минимальные права среды выполнения, карантин обновлений и отдельный процесс реагирования. В результате supply chain-инцидент превращается в управляемый риск, а не в неожиданную катастрофу.
Автор:
Илья Новойдарский, руководитель группы инновационных решений направления безопасной разработки
