Trivy: полный чек-лист по защите CI/CD и разбор инцидента

Что произошло: компрометация Trivy в 2026 году

В марте 2026 Trivy — один из наиболее популярных open-source сканеров уязвимостей — был скомпрометирован дважды за три недели. Пострадали тысячи CI/CD-пайплайнов по всему миру. Если ваш проект использует Trivy или связанные с ним GitHub Actions, эта информация критически важна для защиты вашей инфраструктуры.

Хронология инцидентов: две атаки за три недели

Первая атака: CVE-2026-28353 и hackerbot-claw

Даты: 21–28 февраля 2026

Злоумышленники эксплуатировали критическую уязвимость в GitHub Actions-воркфлоу через механизм pull_request_target. Автономный бот hackerbot-claw автоматически создал Pull Request #10252, что позволило выполнить произвольный код в контексте с доступом к секретам репозитория. Через эту атаку было скомпрометировано VSCode-расширение Trivy, а вредоносная версия v1.8.12 попала в Open VSIX Registry.

Инцидент получил идентификатор CVE-2026-28353 с максимальной оценкой критичности CVSS 10.0. Это означает полную компрометацию конфиденциальности, целостности и доступности системы. Причём исходный disclosure discussion (#10265) был удалён во время второго инцидента, что вызвало критику сообщества за недостаточную прозрачность в обработке уязвимостей.

Вторая атака: TeamPCP и ретроактивное отравление тегов

Дата: 19 марта 2026

Группа TeamPCP использовала учётные данные, украденные в первом инциденте, и опубликовала вредоносный релиз v0.69.4. Однако главная особенность этой атаки — ретроактивное отравление тегов: атакующие переместили (force-push) 76 из 77 существующих тегов релизов так, чтобы они указывали на вредоносный код.

Это означает, что даже если вы использовали «старую стабильную версию», вы также могли получить малварь. Команды, которые зафиксировали версии через теги, оказались под ударом, поскольку теги были изменены задним числом. Полезная нагрузка обеих атак была направлена на кражу секретов CI/CD: GitHub-токенов, npm-токенов, API-ключей и других данных из GitHub Secrets.

Каскадный эффект: CanisterWorm

Ситуация усугубилась каскадным эффектом: украденные npm-токены запустили CanisterWorm — самораспространяющегося червя, который заразил от 28 до 47 пакетов в npm-реестре.

Как проверить свой проект на компрометацию: инструкция

Если вы использовали Trivy или связанные GitHub Actions в период с февраля по март 2026 года, по умолчанию считайте, что ваш пайплайн скомпрометирован. Выполните следующие проверки в указанном порядке.

1. Проверьте версии Trivy и GitHub Actions

Откройте ваши workflow-файлы (.github/workflows/*.yml) и найдите использования trivy-action и setup-trivy. Обратите особое внимание на версии.

Статус версий на момент публикации (22.03.2026, 14:30 GMT+3):

2. Проанализируйте логи CI/CD на подозрительную активность

Вредоносный код выполнял запросы к внешним серверам для эксфильтрации данных. При анализе логов workflow-запусков обращайте внимание на следующие индикаторы компрометации:

• Необъяснимые HTTP-запросы к неизвестным доменам или IP-адресам.
• Запросы к canister-контейнерам на блокчейне Internet Computer (ICP), это характерный признак CanisterWorm. 
• Странное поведение переменных окружения, особенно GITHUB_TOKEN и NPM_TOKEN. 
• Подозрительные base64-кодированные строки в выводе, которые могут маскировать полезную нагрузку.

3. Проверьте npm-пакеты на заражение CanisterWorm

Если ваши npm-токены были скомпрометированы, злоумышленники могли опубликовать через них вредоносные версии ваших пакетов. CanisterWorm самораспространяется: каждый заражённый пакет пытается заразить другие пакеты, к которым имеет доступ.

Используйте инструменты для сканирования ваших npm-пакетов на наличие вредоносного кода, зарубежные кибербез-издания рекомендуют Socket.dev или Snyk.

Особое внимание стоит уделить пакетам, опубликованным или обновлённым в период с 19 по 22 марта 2026 года — именно в это время происходила первичная волна распространения CanisterWorm.

4. Проведите аудит учётных данных и токенов

Надо определить, какие секреты были доступны скомпрометированным workflow. Проверьте следующие категории токенов:

GITHUB_TOKEN — автоматически предоставляется workflow → доступ к репозиторию и коду
NPM_TOKEN — публикация npm-пакетов → публикация вредоносных версий
DOCKER_USERNAME/PASSWORD — публикация контейнеров → компрометация образов
AWS_ACCESS_KEY_ID/SECRET — доступ к облаку → несанкционированный доступ к инфраструктуре

Как защитить CI/CD пайплайн: практическое руководство

1. Немедленно ротируйте все секреты

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

Последовательность действий:

1. Сгенерируйте новые токены для всех сервисов (GitHub, npm, Docker Hub, AWS и других).
2. Обновите секреты в настройках репозитория
3. Проверьте, что новые токены работают корректно (запустите тестовый workflow).
4. Отзовите старые токены.

2. Закрепляйте версии GitHub Actions через SHA-хеши

Вместо тегов используйте неизменяемые ссылки по SHA-хешу. Это один из наиболее эффективных методов защиты от атак на зависимости.

Для получения SHA-хеша конкретной версии перейдите на страницу релиза или используйте команду git ls-remote для получения хеша конкретного тега.

3. Реализуйте принцип минимальных привилегий для GITHUB_TOKEN

По умолчанию GITHUB_TOKEN имеет достаточно широкие права доступа. Ограничьте их до минимально необходимых для каждого конкретного workflow:

• Отключите запись, если workflow только читает данные
• Используйте блок permissions в каждом workflow для явного указания требуемых прав
• Не передавайте токен в шаги, которым он не нужен

4. Защитите pull_request_target

Этот тип триггера особенно опасен: workflow выполняется в контексте базовой ветки с доступом к секретам. Если вам необходим pull_request_target, применяйте следующие меры защиты:

Никогда не выполняйте код из PR в контексте с секретами — сначала проверяйте источник.

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

Рассмотрите альтернативные паттерны запуска workflow, например pull_request вместо pull_request_target.

Изолируйте привилегированные операции в отдельные workflow с ограниченным доступом.

5. Настройте мониторинг и оповещения

Настройте мониторинг на все критичные точки входа в ваш CI/CD процесс:

• Уведомления о необычных workflow-запусках — особенно в нерабочее время или из незнакомых источников.
• Алерты на подозрительные исходящие запросы из CI/CD (особенно на неизвестные домены и IP).
• Контроль публикаций пакетов — отслеживайте, кто, когда и откуда публикует пакеты в ваши реестры.

А ещё чистите зубы, мойте руки с мылом и надевайте шапку.

Технические детали для юных детективов: как сработали атаки на Trivy

Бот hackerbot-claw

Инцидент начался 27 февраля 2026 года, когда автономный бот hackerbot-claw создал Pull Request #10252 в репозитории Trivy. Бот эксплуатировал workflow с использованием pull_request_target, который позволял выполнить произвольный код в контексте с доступом к секретам репозитория.

Результат атаки — скомпрометированное VSCode-расширение Trivy. Версия 1.8.12, попавшая в Open VSIX Registry, содержала вредоносный код, который выполнял следующие действия:

1. Собирал конфиденциальные данные из среды разработки пользователя.
2. Эксфильтрировал украденные данные на командный сервер злоумышленников.
3. Создавал персистентный бэкдор для повторного доступа.

NVD зарегистрировала инцидент как CVE-2026-28353 с оценкой CVSS 10.0 — максимально возможной оценкой, указывающей на полную компрометацию информационной безопасности.

Ретроактивное отравление тегов

Группа TeamPCP получила write-доступ к репозиторию Trivy через скомпрометированные учётные данные, украденные в первом инциденте.

Ключевая инновация атаки — ретроактивное отравление тегов. Атакующие не просто опубликовали новую вредоносную версию — они переместили 76 из 77 существующих тегов так, чтобы те указывали на вредоносный код. Это означает, что под удар попадает любой пользователь, который:

• Использовал trivy-action@latest
• Использовал конкретную версию через тег
• Фиксировал зависимости через теги

CanisterWorm: блокчейн как командный сервер

Отдельного внимания заслуживает CanisterWorm — малварь, распространившаяся через скомпрометированные npm-токены.

Ключевые особенности CanisterWorm:

1. Использование блокчейна Internet Computer (ICP) как C2-сервера — децентрализованная инфраструктура, устойчивая к традиционным методам блокировки доменов и IP-адресов.
2. Автоматическое распространение — каждый заражённый пакет пытается заразить другие пакеты в экосистеме.
3. Кража токенов из среды разработчиков и CI/CD окружения для расширения сферы влияния.
4. Персистентный бэкдор для повторного несанкционированного доступа.

FAQ / TLDR

Как проверить, использовал ли я скомпрометированную версию Trivy?

Проверьте ваши workflow-файлы в .github/workflows/*.yml на наличие версий v0.69.4 для Trivy или любых версий для trivy-action от 19 марта 2026 года. Также проверьте логи CI/CD на подозрительную активность: исходящие запросы к неизвестным доменам, особенно к canister-контейнерам на ICP.

Что делать, если я обнаружил компрометацию?

Немедленно ротируйте все секреты, которые передавались в workflow, отдельное внимание уделите GITHUB_TOKEN и NPM_TOKEN. Проверьте npm-пакеты на заражение CanisterWorm с помощью Socket.dev или Snyk. Проведите аудит всех публикаций в реестры за период с февраля по март 2026 года.

Почему атака на сканер уязвимостей особенно опасна?

Инструменты безопасности работают с максимальными привилегиями в инфраструктуре. Они имеют доступ к коду, секретам и конфиденциальным данным. Компрометация инструмента безопасности даёт злоумышленнику всё то, что этот инструмент защищает — секреты CI/CD, код и доступ к инфраструктуре.

Как защититься от атак на зависимости в будущем?

Используйте SHA-хеши вместо тегов для закрепления версий зависимостей.

Применяйте принцип минимальных привилегий для всех токенов в CI/CD.

Настройте регулярную ротацию секретов.

Мониторьте исходящий трафик из CI/CD на предмет аномалий.

Проводите регулярный аудит зависимостей и их источников.

Материал подготовлен по открытым данным.

Основные источники: CrowdStrike, StepSecurity, Socket.dev, Ars Technica, Apache Foundation, Aikido Security, The Hacker News, NVD (CVE-2026-28353), GitHub Discussion #10265, Chainguard.