Изтичането на секретни данни не винаги е свързано с лош код или уязвими библиотеки. Понякога се свежда до това как управляваме секретните данни по време на изпълнение на непрекъсната интеграция (CI), а CVE‑2025‑30066 е учебникарски пример за това как това може да се обърка. GitHub Action tj‑actions/changed‑files, широко използван за откриване на променени файлове в pull requests, се превърна в тих канал за тайно изтичане на информация. Ето какво се случи и как можете да блокирате CI/CD тайни pipeline.
Какво се случи с CVE‑2025‑30066?
В средата на март 2025 г. tj-actions/changed-files беше компрометиран. Атакуващият е пренаписал съществуващите етикети на версиите (до v45.0.7), за да сочат към злонамерен софтуер. commitТова промени поведението на Action, без разработчиците да забележат; не беше пусната нова версия, а само невидима промяна на етикети.
Полезният товар беше директен, но опасен: той изтегляше отдалечен Python скрипт, кодиран в Base64, който сканираше паметта на бегача за идентификационни данни, записвайки ги в лог файлове или ги извличайки. Това не беше логическа грешка в кода в tj-actions/changed-files; това беше злоупотреба с това как може да възникне изтичане на секретни данни в рамките на CI работни процеси, използващи това многократно използваемо действие. CVE-2025-30066 не беше за препълване на буфера; ставаше дума за грешка в дизайна на CI, която е позволила изтичане на секретни данни.
Въздействие: Всяко хранилище, използващо засегнатите версии на tj-actions/changed-files, рискува изтичане на секретна информация, особено ако чувствителни токени или файлове са били обработвани несигурно във файлови шаблони или CI изходи.
Защо това се отразява на работните процеси, разчитащи на действия за многократна употреба
Работни процеси на DevSecOps силно разчитат на tj-actions/changed-files за:
- автоматизирам pull request проверки
- Идентифицирайте променени файлове в определени пътища
- Избягвайте излишни CI задачи
Но тези работни потоци често пренебрегват едно нещо: как глобалните модели могат да включват чувствителни данни. Разработчиците приемат, че tj-actions/changed-files се държи сигурно по подразбиране. Ако обаче глобирате конфигурации/** и тайните се съхраняват в configs/secrets.env, току-що добавихте секретен файл в CI изходите или логовете. Това не е грешка в действието; това е CI/CD грешка в дизайна, която води до тайно изтичане на информация. CVE‑2025‑30066 е ясен пример за това.
Как се е случило тайното изтичане (Разбивка на уязвимостите)
Нека разгледаме основната причина за повредата CVE‑2025‑30066:
- Глобиращи модели като **/*.env съпоставени секретни файлове неволно
- tj-actions/changed-files третираха тези тайни като променени файлове
- Тайните се озоваха в изходни данни от стъпки, лог файлове или задачи надолу по веригата
Това се случи, защото тайните бяха съхранявани в пътища с контролирани версии (лоша идея) и конфигурацията на CI не ги изключваше изрично от глобализиране (също лошо). Така че не е грешка в кода, а лоша хигиена на CI дизайна, причиняваща изтичане на тайни с изходите на tj-actions/changed-files.
Практически път на експлоатация: От CI задача до разкриване на идентификационни данни
Примерна 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-действия/променени файлове в дефектен CI дизайн.
Разпространението се случва с изходи като:
yaml ‑ name: Use changed file list run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}" If secrets.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-действия/променени файлове.
Допълнително:
- Деактивирайте или ограничете регистрирането, където може да се появят тайни данни
- Използвайте тайните функции за маскиране на GitHub
- Ограничете достъпа до лог файлове и артефакти за изграждане
Бърз контролен списък за използване на Secrets Safe CI
| Най-добра практика |
|---|
| Не съхранявайте тайни във файлове с контролирани версии |
| Използвайте трезори или GitHub Secrets за идентификационни данни |
| Винаги закрепвай tj-действия/променени файлове към непроменяеми SHA файлове |
| Филтриране или дезинфекция на изходи от tj-действия/променени файлове |
| Никога не включвайте тайни пътища в глобалните шаблони |
| Маскиране или ограничаване на регистрационни файлове, които могат да разкрият чувствителни данни |
| Често проверявайте наследените CI конфигурации |
Ролята на Xygeni: Прилагане на CI Secrets в голям мащаб
Ксигени обезапасява CI/CD pipelineчрез фокусиране върху как тайните се обработват, използват и разкриват в реалния свят DevOps работни процеси. Не става въпрос само за сканиране на код; става въпрос за прилагане на най-добрите практики за управление на тайни чрез pipeline анализ.
Откриване на опасно използване на изхода
- Сканира действия в GitHub за употреба на echo, run и извежда където ${{ steps.*.outputs.* }} може да включва чувствителни стойности
- Идентифицира кога тайните са посочени или отпечатани директно, умишлено или по погрешка
Мониторинг на изтекли тайни
- Открива стойности с висока ентропия (API ключове, токени) в лог файлове и изходи от стъпки
- Задейства известия, когато се появят тайни в pipeline лог файлове, дори ако са маскирани надолу по веригата
Неправилно конфигурирано използване на действие
- Проследява всички действия в GitHub pipelineза откриване на използването на компрометирани версии (напр. tj-actions/changed-files@v45)
- Проверява модели за съвпадение на файлове, които включват потенциални тайни, като например **/*.env, *.key или .env.*
CI, базирана на политики Guardrails
- Налага SHA-закрепване за действия на трети страни
- Блокира използването на опасни файлови глобуси, които биха могли да „поместят“ тайни в лог файлове
- Предотвратява pipelineот излъчване на чувствителни стойности като част от изходите на работния процес
Като третира работните процеси като част от вашата повърхност на заплахите, Xygeni гарантира, че тайната хигиена не е просто най-добра практика, а вградена защита.
Заключение: Тайното изтичане на информация може да започне с просто действие или злоупотреба
CVE‑2025‑30066 не беше библиотечна грешка; това беше CI/CD неуспех в дизайна, произтичащ от неправилно използване на tj-действия/променени файлове. Какво трябва да извлекат екипите на DevSecOps:
- Третирайте всяка препратка към глобален обект/файл в CI като потенциална точка на изтичане
- Редовно проверявайте работните процеси за случайно включване на тайни
- Използвайте защитени трезори или тайни данни за средата, никога не проверявайте тайните в контрола на версиите
- Почистете или филтрирайте всички изходи от работния процес
- Регистрирайте чувствителна активност по работния процес, за да поддържате възможност за одит
Непрекъснатата интеграция е код. Работните процеси са код. Регистрационните файлове и резултатите са код. Пазете тайните си на всяка стъпка или рискувайте сценарий за изтичане на тайна, който не се нуждае от хакер, а само от лош... CI/CD избор на дизайн.
