O vazamento de segredos nem sempre está relacionado a código ruim ou bibliotecas vulneráveis. Às vezes, tudo se resume à forma como gerenciamos segredos durante execuções de CI, e o CVE‑2025‑30066 é um exemplo clássico de como isso pode dar errado. A ação do GitHub tj‑actions/changed‑files, amplamente utilizada para detectar arquivos alterados em pull requests, tornou-se um canal silencioso para vazamentos secretos. Veja o que aconteceu e como você pode bloquear seu CI/CD segredos! pipeline.
O que aconteceu em CVE‑2025‑30066?
Em meados de março de 2025, tj-actions/changed-files foi comprometido. O invasor reescreveu as tags de versão existentes (até v45.0.7) para apontar para um malware commit. Isso alterou o comportamento da Ação sem que os desenvolvedores percebessem; nenhuma nova versão foi lançada, apenas adulteração invisível de tags.
O payload era simples, mas perigoso: ele puxava um script Python remoto codificado em Base64 que escaneava a memória do executor em busca de credenciais, despejando-as em logs ou exfiltrando-as. Não se tratava de uma falha lógica de código nas tj-actions/changed-files; era um abuso de como o vazamento de segredos pode ocorrer em fluxos de trabalho de CI usando essa Ação reutilizável. O CVE-2025-30066 não se referia a estouros de buffer; tratava-se de uma falha de projeto de CI que permitiu o vazamento de segredos.
Impacto: qualquer repositório que usasse as versões afetadas de tj-actions/changed-files corria o risco de vazamento de segredos, especialmente se tokens ou arquivos confidenciais fossem manipulados de forma insegura em padrões de arquivo ou saídas de CI.
Por que isso afeta os fluxos de trabalho que dependem de ações reutilizáveis
Fluxos de trabalho DevSecOps dependem fortemente de tj-actions/changed-files para:
- Automatize pull request cheques
- Identificar arquivos alterados em caminhos específicos
- Evite trabalhos de CI redundantes
Mas esses fluxos de trabalho frequentemente ignoram um ponto: como os padrões glob podem incluir dados confidenciais. Os desenvolvedores presumem que tj-actions/changed-files se comportam de forma segura por padrão. No entanto, se você usar glob configurações/** e os segredos são armazenados em configs/secrets.env, você acabou de adicionar um arquivo secreto nas saídas ou logs do CI. Isso não é um bug na Ação; é um CI/CD falha de projeto que leva ao vazamento de informações secretas. O CVE‑2025‑30066 é um exemplo claro disso.
Como ocorreu o vazamento secreto (análise de vulnerabilidades)
Vamos analisar a falha central por trás do CVE‑2025‑30066:
- Padrões globalizantes como **/*.env arquivos secretos combinados involuntariamente
- tj‑actions/changed‑files tratou esses segredos como arquivos alterados
- Os segredos acabaram em saídas de etapas, logs ou trabalhos posteriores
Isso aconteceu porque os segredos eram armazenados em caminhos controlados por versão (má ideia) e a configuração do CI não os excluía explicitamente do globbing (também ruim). Portanto, não se trata de um bug de código, mas sim de uma higiene inadequada do projeto do CI, causando vazamento de segredos com saídas de tj-actions/changed-files.
Caminho Prático de Exploração: Do Trabalho de CI à Exposição de Credenciais
Exemplo de configuração de CI que causou vazamento de segredo por meio de 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 alterado:
- Foi sinalizado por tj-actions/changed-files
- Foi incluído em etapas.alterado.saídas.todos_os_arquivos_alterados
- Etapas posteriores registraram ou passaram para scripts, vazando segredos
Esse vazamento ocorreu porque a lógica do CI tratava segredos como arquivos comuns. É aí que o vazamento de segredos começa, não devido a um estouro de buffer, mas ao uso indevido de tj-actions/arquivos alterados em um projeto de CI falho.
A propagação ocorre com saídas como:
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If segredos.env estiver nessa lista, seu nome de arquivo e possivelmente seu conteúdo podem aparecer nos logs de compilação. Até mesmo lógica condicional como:
yaml
if: contains(steps.changed.outputs.all_changed_files, 'secrets.env')
Pode expor artefatos sensíveis. Este é um CI/CD falha de projeto permitindo vazamento secreto, não uma falha no código de ação.
Como usar fluxos de trabalho reutilizáveis com segurança e evitar vazamentos
Você não precisa abandonar tj-actions/changed-files. Você deve usar Ações reutilizáveis com uma mentalidade que prioriza os segredos:
Melhores práticas de manuseio de segredos
- Nunca controle a versão de segredos
- Evite padrões glob que correspondam a caminhos sensíveis
- Use segredos baseados em ambiente (GITHUB_ENV, cofres, GitHub Secrets)
CI/CD Configuração Guardrails
- Sempre fixe ações em SHAs imutáveis, não em tags (nunca use @v45)
- Trate a saída de tj-actions/arquivos alterados como contaminados, higienize-os ou filtre-os
- Defina saídas somente se higienizadas
⚠️ Exemplo inseguro:
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
O exposto acima é exatamente o uso indevido por trás do vazamento secreto e do CVE‑2025‑30066.
Alternativa Segura:
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
Ao fazer isso, você evita o CI/CD falha de projeto que leva ao vazamento de segredos por meio de tj-actions/arquivos alterados.
Além disso:
- Desabilitar ou restringir o registro onde segredos podem aparecer
- Use os recursos secretos de mascaramento do GitHub
- Limitar o acesso a registros de construção e artefatos
Segredos rápidos - Lista de verificação de uso seguro de CI
| Melhores Práticas |
|---|
| Não armazene segredos em arquivos com controle de versão |
| Use cofres ou segredos do GitHub para credenciais |
| Sempre fixe tj-actions/alterados-arquivos em SHAs imutáveis |
| Filtrar ou higienizar saídas de tj-actions/changed-files |
| Nunca inclua caminhos secretos em padrões glob |
| Mascarar ou restringir registros que podem expor dados confidenciais |
| Audite configurações de CI herdadas com frequência |
Papel da Xygeni: Aplicação de segredos de CI em escala
Xygeni Protege CI/CD pipelines concentrando-se em como os segredos são tratados, usados e expostos no mundo real Fluxos de trabalho DevOps. Não se trata apenas de escanear código; trata-se de aplicar as melhores práticas de gerenciamento de segredos por meio de pipeline análise.
Detecção de uso de saída insegura
- Verifica ações do GitHub para usos de eco, execução e saídas onde ${{ steps.*.outputs.* }} pode incluir valores sensíveis
- Identifica quando os segredos são referenciados ou impressos diretamente, intencionalmente ou por engano
Monitoramento de Segredos Vazados
- Detecta valores de alta entropia (chaves de API, tokens) dentro de logs e saídas de etapas
- Dispara alertas quando segredos aparecem no pipeline logs, mesmo que mascarados a jusante
Uso de ação mal configurado
- Rastreia todas as ações do GitHub em pipelines para detectar o uso de versões comprometidas (por exemplo, tj-actions/arquivos-alterados@v45)
- Audita padrões de correspondência de arquivos que incluem segredos potenciais como **/*.env, *.key ou .env.*
CI baseado em políticas Guardrails
- Aplica SHA-pinning para ações de terceiros
- Bloqueia o uso de arquivos inseguros que podem espalhar segredos para os logs
- Previne pipelines de emitir valores sensíveis como parte das saídas do fluxo de trabalho
Ao tratar os fluxos de trabalho como parte da sua superfície de ameaças, a Xygeni garante que a higiene secreta não seja apenas uma prática recomendada, mas uma defesa integrada.
Conclusão: Vazamento de segredos pode começar com uma simples ação de uso indevido
CVE‑2025‑30066 não era um bug de biblioteca; era um CI/CD Falha de design decorrente do uso indevido de tj-actions/arquivos alterados. O que as equipes de DevSecOps devem levar em conta:
- Trate cada referência glob/file no CI como um ponto de vazamento potencial
- Audite os fluxos de trabalho regularmente para detectar a inclusão acidental de segredos
- Use cofres seguros ou segredos de ambiente, nunca verifique segredos no controle de versão
- Sanitizar ou filtrar todas as saídas do fluxo de trabalho
- Registre a atividade do fluxo de trabalho sensível para manter a capacidade de auditoria
CI é código. Fluxos de trabalho são código. Logs e saídas são código. Proteja seus segredos a cada passo, ou arrisque-se em um cenário de vazamento de segredos que não precisa de um hacker, apenas de um hacker mal-intencionado. CI/CD escolha de design.
