Утечка секретной информации не всегда связана с плохим кодом или уязвимыми библиотеками. Иногда это зависит от того, как мы управляем секретной информацией во время непрерывной интеграции, и CVE‑2025‑30066 — хрестоматийный пример того, к чему это может привести. Действие GitHub tj‑actions/changed‑files, широко используемое для обнаружения изменённых файлов в pull requests, стал скрытым каналом для утечки секретной информации. Вот что произошло и как вы можете заблокировать свой CI/CD секреты pipeline.
Что произошло в CVE‑2025‑30066?
В середине марта 2025 года tj‑actions/changed‑files был скомпрометирован. Злоумышленник переписал существующие теги версий (до версии 45.0.7), чтобы указать на вредоносную версию. commit. Это изменило поведение действия, и разработчики этого не заметили; новая версия не была выпущена, была лишь скрыта подделка тега.
Полезная нагрузка была простой, но опасной: она извлекала удалённый скрипт Python в кодировке Base64, который сканировал память исполнителя на предмет учётных данных, сохраняя их в журналах или извлекая из системы. Это не было логической ошибкой кода в tj-actions/changed-files; это было злоупотреблением тем, как утечка секретных данных может происходить в рабочих процессах непрерывной интеграции (CI), использующих это повторно используемое действие. CVE-2025-30066 была связана не с переполнением буфера, а с ошибкой в конструкции CI, которая допускала утечку секретных данных.
Воздействие: любой репозиторий, использующий уязвимые версии tj-actions/changed-files, рисковал утечкой секретной информации, особенно если конфиденциальные токены или файлы обрабатывались небезопасно в шаблонах файлов или выходных данных CI.
Почему это влияет на рабочие процессы, основанные на повторно используемых действиях
Рабочие процессы DevSecOps активно использовать tj-actions/changed-files для:
- Автоматизиция pull request проверки
- Определить измененные файлы по определенным путям
- Избегайте избыточных задач непрерывной интеграции
Но эти рабочие процессы часто упускают из виду один момент: как шаблоны glob могут содержать конфиденциальные данные. Разработчики предполагают, что tj‑actions/changed‑files по умолчанию ведут себя безопасно. Однако, если вы glob конфиги/** и секреты хранятся в configs/secrets.env, вы только что добавили секретный файл в выходные данные или журналы CI. Это не ошибка в действии, это ошибка CI/CD Ошибка проектирования, приводящая к утечке секретной информации. CVE‑2025‑30066 — яркий пример.
Как произошла утечка секретной информации (анализ уязвимостей)
Давайте разберем основную ошибку, лежащую в основе CVE‑2025‑30066:
- Шаблоны сглаживания, такие как **/*.env непреднамеренно сопоставил секретные файлы
- tj‑actions/changed‑files обрабатывал эти секреты как измененные файлы
- Секреты оказались в выходных данных шагов, журналах или последующих заданиях
Это произошло из-за того, что секретные данные хранились в путях с контролем версий (плохая идея), а конфигурация CI явно не исключила их из подстановки (тоже плохо). Так что это не ошибка кода, а ненадлежащее проектирование CI, приводящее к утечке секретных данных через выходные данные tj-actions/changed-files.
Практический путь эксплуатации: от работы инженера-консультанта до раскрытия учетных данных
Пример настройки CI, вызвавшей утечку секретной информации через tj‑actions/changed‑files:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Check changed files
id: changed
uses: tj‑actions/changed‑files@v45
with:
files: configs/**
If configs/secrets.env изменена:
- Он был отмечен tj‑actions/changed‑files.
- Он был включен в шаги.измененные.выходы.все_измененные_файлы
- Более поздние шаги регистрировали это или передавали в скрипты, раскрывая секреты.
Эта утечка произошла из-за того, что логика CI обрабатывала секреты как обычные файлы. Именно здесь и начинается утечка секретов, вызванная не переполнением буфера, а неправильным использованием tj-actions/changed-files в некорректной архитектуре CI.
Распространение происходит с такими выходами:
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If секреты.env Если файл находится в этом списке, его имя и, возможно, содержимое могут появиться в журналах сборки. Даже условная логика, например:
yaml
if: contains(steps.changed.outputs.all_changed_files, 'secrets.env')
Может выявлять чувствительные артефакты. Это CI/CD ошибка проектирования, допускающая утечку секретной информации, а не изъян в коде Действия.
Как безопасно использовать многоразовые рабочие процессы и предотвращать утечки
Вам не нужно отказываться от tj-actions/changed-files. Используйте многоразовые Actions с ориентацией на секреты:
Лучшие практики обращения с секретами
- Никогда не используйте контроль версий секретов.
- Избегайте шаблонов шаров, соответствующих чувствительным путям
- Используйте секреты на основе среды (GITHUB_ENV, хранилища, секреты GitHub)
CI/CD Конфигурация Guardrails
- Всегда прикрепляйте действия к неизменяемым SHA, а не к тегам (никогда не используйте @v45)
- Обрабатывать выходные данные tj‑actions/changed‑files как испорченные, очищать или фильтровать их.
- Устанавливать выходы только в случае их очистки
⚠️ Небезопасный пример:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Detect all changes
id: changed
uses: tj‑actions/changed‑files@v45
with:
files: '**/*' # ⚠️ This glob includes secrets.env, which may leak credentials
Вышеизложенное — это именно то злоупотребление, которое стоит за утечкой секретной информации и CVE‑2025‑30066.
Безопасная альтернатива:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Detect non‑sensitive file changes
id: changed
uses: tj‑actions/changed‑files@<SHA> # pinned to SHA
with:
files: 'src/**'
files‑ignore: '**/secrets.env' # ⚠️ Excludes secret file
Делая это, вы избегаете CI/CD ошибка проектирования, которая приводит к утечке секретной информации через tj-actions/changed-files.
Дополнительно:
- Отключить или ограничить ведение журнала, в котором могут появляться секреты
- Используйте секретные функции маскировки GitHub
- Ограничить доступ к журналам сборки и артефактам
Quick Secrets‑Безопасное использование CI: контрольный список
| Best Practice |
|---|
| Не храните секреты в файлах с контролем версий |
| Используйте хранилища или GitHub Secrets для учетных данных |
| Всегда закрепляйте tj-actions/changed-files в неизменяемых SHA-файлах |
| Фильтрация или очистка выходных данных из tj‑actions/changed‑files |
| Никогда не включайте секретные пути в шаблоны глобусов |
| Маскируйте или ограничивайте журналы, которые могут раскрыть конфиденциальные данные |
| Регулярно проверяйте унаследованные конфигурации CI |
Роль Xygeni: обеспечение соблюдения конфиденциальности CI в больших масштабах
Ксигени Secures CI/CD pipelines, сосредоточившись на как секреты обрабатываются, используются и раскрываются в реальном мире Рабочие процессы DevOps. Речь идёт не только о сканировании кода, но и о внедрении передовых практик управления секретами в режиме реального времени. pipeline анализа.
Обнаружение небезопасного использования выходных данных
- Сканирование действий GitHub для использования echo, run и выводит, где ${{ steps.*.outputs.* }} могут включать конфиденциальные значения
- Определяет, когда секреты упоминаются или печатаются напрямую, намеренно или по ошибке.
Мониторинг утечки секретов
- Обнаруживает высокоэнтропийные значения (ключи API, токены) в журналах и выходных данных шагов
- Запускает оповещения, когда в системе появляются секреты. pipeline журналы, даже если они замаскированы ниже по течению
Неправильно настроенное использование действия
- Отслеживает все действия GitHub pipelineдля обнаружения использования скомпрометированных версий (например, tj-actions/changed-files@v45)
- Аудит шаблонов сопоставления файлов, которые включают потенциальные секреты, такие как **/*.env, *.key или .env.*
CI на основе политики Guardrails
- Обеспечивает закрепление SHA для сторонних действий
- Блокирует использование небезопасных файловых шаблонов, которые могут занести секреты в журналы.
- Препятствует pipelines от передачи конфиденциальных значений в рамках выходных данных рабочего процесса
Рассматривая рабочие процессы как часть поверхности угроз, Xygeni гарантирует, что секретная гигиена — это не просто передовая практика, а встроенная защита.
Вывод: утечка секретной информации может начаться с простого действия — злоупотребления
CVE‑2025‑30066 не была ошибкой библиотеки; это была CI/CD Ошибка проектирования, вызванная неправильным использованием tj-actions/changed-files. Что должны усвоить команды DevSecOps:
- Рассматривать каждую ссылку на файл/глобал в CI как потенциальную точку утечки
- Регулярно проверяйте рабочие процессы на предмет случайного включения секретов.
- Используйте безопасные хранилища или секреты среды, никогда не отправляйте секреты в систему контроля версий.
- Очищайте или фильтруйте все результаты рабочего процесса
- Регистрируйте конфиденциальную активность рабочего процесса для обеспечения возможности аудита
Непрерывная интеграция (CI) — это код. Рабочие процессы — это код. Журналы и выходные данные — это код. Защищайте свои секреты на каждом этапе, иначе рискуете столкнуться с утечкой, для которой не нужен хакер, а нужен лишь плохой CI/CD выбор дизайна.
