Meu Pipeline CI/CD Explotou Chaves de API – Aqui Está Minha Solução

Oi pessoal, Pat Reeves aqui, de volta ao botsec.net. Espero que todos estejam tendo um bom começo de abril. Hoje, quero mergulhar em algo que tem me mantido acordado à noite e, sinceramente, deveria estar preocupando você também se está construindo ou defendendo algo envolvendo bots: a exposição silenciosa de chaves de API em pipelines de CI/CD. Estamos falando de uma vulnerabilidade que é tão comum que quase se tornou uma característica, e está deixando a porta dos fundos escancarada para operadores de botnets e ladrões de dados.

Eu sei, eu sei. “Chaves de API, CI/CD, bocejo.” Mas ouça-me. Não se trata de algum zero-day teórico. Trata-se de erros básicos, repetidos infinitamente, levando a consequências verdadeiramente desagradáveis. Eu vi isso de perto, e é feio.

A Chave Pública Acidental: Uma História Tão Antiga Quanto o Tempo (ou pelo Menos, Tão Antiga Quanto o GitHub)

Pense em seu fluxo de trabalho típico de desenvolvimento. Você tem seu aplicativo, talvez um bot que interage com um serviço de terceiros – um gateway de pagamento, uma plataforma de mídia social, uma API de nuvem. Para fazer isso, você precisa de uma chave de API. Justo. Agora, onde você a coloca?

Em um mundo perfeito, você está usando variáveis de ambiente, um sistema de gerenciamento de segredos como o HashiCorp Vault ou o AWS Secrets Manager. Você está seguindo todas as melhores práticas, rotacionando chaves, limitando permissões. Mas sejamos realistas. Não vivemos em um mundo perfeito, especialmente não quando os prazos são apertados e a cafeína está acabando.

O que vejo, repetidamente, são desenvolvedores fazendo isso:

// config.js
const API_KEY = "sk_live_XXXXXXXXXXXXXXXXXXXXXX"; 

Ou ainda pior, embutindo-a diretamente em um script que depois é enviado ao Git. E muitas vezes, esse repositório Git é público. Ou é privado, mas então alguém faz um fork, o torna público, ou um pipeline interno de CI/CD registra a chave durante um processo de build, e esses logs ficam acessíveis publicamente por um curto período. Acredite, isso acontece. Muito.

Alguns meses atrás, eu estava fazendo uma pesquisa sobre ameaças para um cliente. Estávamos investigando uma família de botnets específica que estava aproveitando contas de nuvem comprometidas. Parte da minha rotina envolve verificar repositórios públicos do GitHub em busca de credenciais vazadas relacionadas aos serviços que esses bots estavam atacando. É como pescar com dinamite, honestamente. Em uma hora, eu encontrei uma dúzia de chaves de API ativas de vários provedores de nuvem – AWS, Azure, GCP – todas pertencentes a empresas legítimas. Algumas dessas chaves concediam acesso administrativo total. Imagine um operador de botnet colocando as mãos nisso. Não se trata apenas de roubar dados; trata-se de usar sua infraestrutura para lançar seus ataques, minerar criptomoedas, hospedar malware. É um pesadelo.

O problema não é apenas o commit inicial. É todo o ciclo de vida. Pipelines de CI/CD, projetados para velocidade e automação, muitas vezes se tornam cúmplices involuntários nesse drama de exposição de chaves. Durante builds, testes e implantações, essas chaves são frequentemente passadas, às vezes registradas, e se não forem manuseadas com extremo cuidado, podem acabar em lugares onde absolutamente não deveriam estar.

O Perigo do CI/CD: Onde Segredos Vão para Morrer (Publicamente)

Pipelines de CI/CD são fantásticos. Eles automatizam tarefas repetitivas, garantem a qualidade do código e aceleram implantações. Mas também representam uma superfície de ataque significativa se não forem configurados de forma segura. Aqui está como as chaves de API frequentemente são expostas nesses ambientes:

1. Codificação em Scripts ou Arquivos de Configuração

Esse é o erro clássico e egregio. Um desenvolvedor precisa de uma chave de API para um passo de build, então ele a codifica diretamente em um script shell ou em um arquivo de configuração YAML. Esse arquivo então é enviado ao repositório. Mesmo que o repositório seja privado, um insider malicioso ou uma conta de desenvolvedor comprometida pode ter acesso. E como mencionei, isso acaba se tornando público eventualmente.

Exemplo do que NÃO fazer:

# build.sh
export MY_API_KEY="sk_live_XXXXXXXXXXXXXXXXXXXXXX"
npm run deploy -- --api-key $MY_API_KEY 

Essa chave aparecerá no histórico de shell, possivelmente nos logs de build, e definitivamente no código-fonte se enviado.

2. Registrando Segredos Inadvertidamente

Muitos sistemas de CI/CD registram cada comando executado, cada saída de um script. Se você não tomar cuidado, informações sensíveis, incluindo chaves de API, podem facilmente acabar nesses logs. Embora a maioria das plataformas modernas de CI/CD tenha algum nível de redimensionamento de segredos, não é infalível, especialmente se a chave for parte de uma string maior ou uma saída de comando que não está explicitamente marcada como segredo.

Eu me lembro de um incidente em que uma equipe estava depurando uma implantação instável. Eles aumentaram a verbosidade dos seus logs de CI/CD. E não é que um API key crucial, mascarado na saída normal, se tornou totalmente visível quando o nível de log foi aumentado. Ele ficou visível por algumas horas até que perceberam e o rotacionaram, mas isso é tudo o que um atacante sofisticado precisa.

3. Uso inadequado de Variáveis de Ambiente

Usar variáveis de ambiente é um passo na direção certa, mas não é uma solução milagrosa. Se o seu sistema de CI/CD permite definir variáveis de ambiente para suas builds, isso é ótimo. O problema surge quando essas variáveis são ecoadas para depuração ou se um processo filho as herda e as registra.

Exemplo de um erro comum:

# .gitlab-ci.yml (ou similar para GitHub Actions, Jenkins, etc.)
build_job:
 script:
 - echo "Implantando com API Key: $MY_API_KEY" # ENORME NÃO FAÇA!
 - npm run deploy -- --api-key $MY_API_KEY 

Mesmo que MY_API_KEY esteja definido como uma variável secreta nas configurações do seu CI/CD, ecoá-la diretamente imprimirá seu valor nos logs da build, tornando-o visível para qualquer um com acesso a esses logs.

4. Chaves Obsoletas ou Não Rotacionadas

Isso não é estritamente um problema de CI/CD, mas é exacerbado pela automação. Os desenvolvedores costumam configurar uma chave, fazê-la funcionar no pipeline e depois esquecê-la. Se essa chave for comprometida, mesmo que seja rapidamente removida dos logs públicos, ela permanece ativa e vulnerável por meses ou anos. Pipelines automatizados frequentemente dependem dessas chaves de longa duração, tornando a rotação de chaves uma prática de segurança crucial, mas frequentemente negligenciada.

Defendendo os Portões Digitais: Passos Práticos para Proteger suas Chaves

Bem, já chega de pessimismo. Vamos falar sobre como resolver isso. Proteger suas chaves de API em CI/CD não é ciência de foguetes, mas requer disciplina e um compromisso com as melhores práticas de segurança. Aqui estão alguns passos acionáveis:

1. Use Sistemas Dedicados de Gerenciamento de Segredos

Esse é o padrão ouro. Ferramentas como HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou GCP Secret Manager são projetadas especificamente para armazenar e gerenciar segredos com segurança. Integre esses sistemas aos seus pipelines de CI/CD. Em vez de embutir chaves diretamente, seu pipeline solicita o segredo do gerenciador em tempo de execução. Dessa forma, o segredo nunca vive em seu repositório de código ou em texto simples nos logs.

Exemplo Prático (integração simplificada do AWS Secrets Manager):

# .github/workflows/deploy.yml
name: Implantar Aplicação

on: [push]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Configurar Credenciais AWS
 uses: aws-actions/configure-aws-credentials@v4
 with:
 aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
 aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 aws-region: us-east-1
 - name: Recuperar API Key do Secrets Manager
 id: get-api-key
 run: |
 API_KEY=$(aws secretsmanager get-secret-value --secret-id "my-app/api-key" --query SecretString --output text)
 echo "API_KEY=$API_KEY" >> $GITHUB_ENV
 - name: Implantar com API Key
 run: |
 npm run deploy -- --api-key ${{ env.API_KEY }}
 # Certifique-se de que esta chave NÃO seja ecoada ou registrada explicitamente!

Neste exemplo, a chave da API é recuperada dinamicamente em tempo de execução e está disponível apenas dentro do escopo do trabalho, nunca hardcoded. O GITHUB_ENV do GitHub Actions é uma boa maneira de passar segredos entre etapas sem expô-los nos logs, desde que você tenha cuidado para não echoá-los.

2. Aproveite as Variáveis Secretas de CI/CD (Com Cuidado)

A maioria das plataformas de CI/CD (GitHub Actions, GitLab CI/CD, Jenkins, CircleCI) fornece uma maneira de definir variáveis de ambiente “secretas” que são injetadas em tempo de execução e muitas vezes ocultadas nos logs. Use essas variáveis. Sempre. Nunca hardcode chaves diretamente em seus scripts ou arquivos de configuração que sejam commitados.

Regras Principais para Variáveis Secretas de CI/CD:

• Nunca ecoe-as: Não imprima variáveis secretas na saída padrão ou de erro.
• Limite o escopo: Se possível, limite o escopo dos segredos a trabalhos ou etapas específicas.
• Use a ocultação embutida: Certifique-se de que os recursos de ocultação de segredos da sua plataforma de CI/CD estejam ativos.

3. Implemente a Verificação Automática de Segredos

Integre ferramentas como GitGuardian, TruffleHog ou a própria verificação de segredos do GitHub em seu fluxo de trabalho de desenvolvimento. Essas ferramentas podem escanear seus repositórios (tanto os atuais quanto os históricos) em busca de padrões comuns de chaves de API, tokens e outras credenciais. Configure-as para serem executadas em cada push ou pull request. Se um segredo for detectado, bloqueie a mesclagem e alerte a equipe imediatamente.

Eu pessoalmente vi essas ferramentas capturarem chaves antes mesmo de atingirem o branch principal. Elas não são perfeitas, mas adicionam uma camada crítica de defesa, especialmente para capturar aqueles commits acidentais.

4. Rode Chaves Regularmente e Implemente o Princípio do Menor Privilégio

Isso é higiene básica de segurança, mas muitas vezes negligenciada.

• Rode chaves: Estabeleça um cronograma para rodar todas as chaves de API, especialmente aquelas usadas por processos automatizados. Se uma chave for comprometida, sua vida útil é limitada.
• Menor privilégio: Conceda chaves de API apenas as permissões mínimas necessárias. Se um bot só precisa ler dados, não lhe dê acesso de escrita. Se ele só precisa acessar um endpoint específico, restrinja-o a isso. Isso limita o raio de impacto se uma chave for exposta.

5. Eduque Sua Equipe de Desenvolvimento

Esse é, sem dúvida, o passo mais importante. Nenhuma quantidade de ferramentas impedirá completamente vazamentos se seus desenvolvedores não estiverem cientes dos riscos. Realize sessões regulares de treinamento sobre práticas de codificação segura, a importância da gestão de segredos e como usar corretamente os recursos secretos do seu CI/CD. Promova uma cultura onde a segurança é responsabilidade de todos, não apenas da “equipe de segurança”.

Principais Ações para Defensores de BotSec:

Se você está construindo ou defendendo bots, esses princípios são inegociáveis. Chaves de API comprometidas são um caminho direto para atacantes assumirem o controle de sua infraestrutura, manipularem seus bots ou roubarem os dados com os quais interagem. Não deixe que seu pipeline de CI/CD seja o elo mais fraco.

1. Audite Seus Repositórios: Escaneie imediatamente todos os seus repositórios de código (públicos e privados) em busca de chaves de API e credenciais codificadas. Use ferramentas como GitGuardian ou TruffleHog. Assuma que qualquer coisa encontrada está comprometida e a rode.
2. Centralize Segredos: Implemente uma solução dedicada de gestão de segredos (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) e integre-a em seus fluxos de trabalho de CI/CD.
3. Use Variáveis Secretas no CI/CD: Para quaisquer segredos que devem ser passados via variáveis de ambiente, use os recursos de gestão de segredos integrados da sua plataforma de CI/CD, garantindo que nunca sejam ecoados ou registrados.
4. Automatize a Varredura de Segredos: Integre a varredura de segredos em seus hooks de pré-commit e no pipeline de CI/CD para capturar commits acidentais antes que se tornem públicos.
5. Imponha Menor Privilégio & Rotação: Garanta que todas as chaves de API usadas por bots e CI/CD tenham as permissões mínimas necessárias e sejam rodadas em um cronograma regular.
6. Treine Sua Equipe: Eduque os desenvolvedores sobre os perigos da exposição de chaves de API e os procedimentos corretos para manuseio de segredos.

Os atacantes lá fora, especialmente aqueles que operam botnets, estão constantemente em busca de alvos fáceis. Chaves de API vazadas são um prato cheio. Vamos garantir que seus sistemas não estejam fornecendo a colheita. Fique seguro por aí, e até a próxima.

🕒 Published: April 5, 2026