Chave de API, segredo da AWS ou token Stripe Live comprometido com repositório público do GitHub: extração automatizada de bot em 60 segundos, rotação imediata de chave e interruptor de eliminação de faturamento¶

No instante em que você corre git push para um repositório público GitHub, GitLab ou Bitbucket (or temporarily flip a private repository to "Public" for even 10 seconds) enquanto um arquivo, .env configuração, notebook Jupyter (.ipynb), ou o histórico de commits do Git mais antigo contém uma chave secreta ativa (such as an AWS Access Key ID starting with AKIA, a Stripe Live Secret Key sk_live_, an OpenAI key sk-proj-, an Anthropic key sk-ant-, or a Google Cloud service account .json), uma rede global de bots automatizados de coleta de credenciais intercepta esse segredo em 2 a 60 segundos. Porque o público do GitHub Events API, GH Archivee webhook firehoses em tempo real transmitem todos os públicos PushEvent globalmente, os scraper bots maliciosos analisam seu diff com expressões regulares e começam a executar comandos automatizados na nuvem antes mesmo que você possa digitar git revert.

Dentro 90 seconds de um AWS ou GCP segredo atingindo um repositório público, botnets automatizados geram instâncias de GPU/CPU de tamanho máximo (such as p4d.24xlarge or c6i.32xlarge em regiões obscuras como ap-east-1 Hong Kong, me-south-1 Bahrein, ou sa-east-1 São Paulo) para minerar Monero (XMR), solicite o AWS Simple Email Service (SES) aumentos de cota para explodir spam de phishing ou clonar seu privado S3 baldes e RDS bancos de dados, gerando $5,000 to $80,000+ em contas de computação em nuvem durante a noite. Da mesma forma, um vazamento OpenAI ou Anthropic A chave de API é imediatamente agrupada em mercados LLM de "proxy reverso" subterrâneos que drenam milhares de dólares em créditos de token por minuto, enquanto um vazamento Stripe chave secreta ativa (sk_live_...) concede aos invasores acesso total de leitura/gravação programática para emitir reembolsos fraudulentos, exportar clientes PIIou acionar pagamentos não autorizados do Connect. Se um invasor estiver extorquindo ativamente sua organização após exfiltrar bancos de dados de clientes com sua chave vazada, consulte as linhas diretas locais de aplicação da lei e incidentes cibernéticos por meio de nosso números de emergência diretório imediatamente e revise nossos guias relacionados sobre queda acidental do banco de dados de produção, git force-push e triagem de vazamento secreto, banco de dados de produção descartado ou bucket S3 excluído sem backup recentee segurança de trabalho remoto de emergência e privacidade de dados.

Faça isso agora¶

1. NÃO desperdice seus primeiros 60 segundos correndo git rm .env ou git push --force: VÁ DIRETAMENTE PARA O CONSOLE DO PROVEDOR (AWS IAM, Stripe, OpenAI, GCP) E REVOGAR/DESATIVAR A CHAVE IN < 30 SECONDS. Excluindo o arquivo em um novo commit do Git (or even making the GitHub repository Private) não faz nada para impedir os bots que já copiaram sua chave do firehose dos eventos do GitHub há 10 segundos. A chave em si deve ser eliminada primeiro na fonte.
2. Se um AWS chave (AKIA... ou ASIA...) vazou: Abrir AWS IAM -> Users -> Security credentials e clique em Desativar/Excluir na chave de acesso imediatamente e anexe o AWSCompromisedKeyQuarantineV2 (or a blanketNegar *inline policy) para o usuário IAM e incrementar o usuário RevokeOldSessions política para matar qualquer temporário STS tokens que o invasor já cunhou (see the exact STS bypass trap below).
3. Se um Stripe Chave secreta ativa (sk_live_... ou rk_live_...) vazou: Vá para dashboard.stripe.com/apikeys, clique em ... -> Role a chave e defina a expiração da chave antiga para "Agora (Immediately)" (NOT "in 24 hours"). Verifique imediatamente Stripe Dashboard -> Logs e Balance -> Payouts / Refunds para chamadas de API não autorizadas.
4. Se um OpenAI, Anthropic, Google Gemini, ou SendGrid / Twilio chave vazada: Exclua a chave de API no painel do provedor imediatamente e defina um Limite rígido de gastos mensais ($0 ou seu limite normal) nas configurações de faturamento para cortar solicitações de streaming durante o voo.
5. ** Varrer TODAS as regiões da nuvem (especially disabled/opt-in regions) para instâncias EC2 não autorizadas, funções Lambda, tarefas ECS, buckets S3 e usuários backdoor IAM criados pelo bot durante a janela de exposição de 2 minutos.** Os invasores lançam especificamente instâncias de mineração de criptografia em regiões nas quais você nunca clica no console (like Stockholm eu-north-1, Osaka ap-northeast-3, or Mumbai ap-south-1) e crie um segundo usuário IAM oculto (or SSH key pair) para que eles possam permanecer na sua conta depois que você excluir a chave vazada.
6. Somente DEPOIS que o segredo for revogado e as contas IAM backdoor forem eliminadas, limpe o commit do Git (using git-filter-repo) E entre em contato com o suporte do GitHub (or remove cached PR/commit views) para limpar caches SHA de commit pendentes e, em seguida, registre uma Solicitação de isenção de cobrança por vazamento acidental da AWS/GCP se os bots gerarem uma conta enorme na nuvem.

Árvore de decisão: resposta de emergência em 60 segundos por tipo de segredo vazado¶

Siga este fluxograma de contenção de incidentes para eliminar a credencial comprometida, cortar a persistência do invasor e reverter o faturamento descontrolado da nuvem.

flowchart TD
    A["Segredo ao vivo comprometido com o repositório público GitHub / GitLab (.env, código-fonte ou histórico do git)"] --> B["SEGUNDO 0 A 30: NÃO execute git rm primeiro. Abra o console do provedor de nuvem/API e a chave REVOKE imediatamente"]
    B --> C{"Que tipo de credencial ativa foi exposta?"}
    C -->|"1. Chave de acesso AWS (AKIA... / ÁSIA...)"| D["1. Desativar/excluir chave no IAM 2. Anexar política 'Negar tudo' inline ao usuário (mata tokens STS cunhados) 3. Auditar CloudTrail para usuários backdoor IAM"]
    C -->|"2. Chave secreta Stripe Live (sk_live_... / rk_live_...)"| E["1. Role a chave com expiração = 'Imediatamente' 2. Verifique /v1/refunds, /v1/transfers e endpoints de Webhook 3. Avalie a exposição de PII do cliente"]
    C -->|"3. OpenAI (sk-proj-...), Antrópico (sk-ant-...) ou Gemini Key"| F["1. Revogar a chave no console do desenvolvedor 2. Reduzir temporariamente o limite de faturamento da organização para US$ 0 3. Verificar os registros de uso para drenagem de token"]
    C -->|"4. URI do banco de dados (postgres://, mongodb+srv://) ou URL Redis"| G["1. Alterne a senha do banco de dados imediatamente 2. Execute pg_terminate_backend() / KILL para descartar conexões ativas 3. Bloqueie o grupo de segurança apenas para IPs VPC"]
    D --> H["Execute varredura de computação multirregional (encerrar Rogue EC2/EKS/SageMaker/Lambda em todas as mais de 30 regiões)"]
    E --> I["Limpar o histórico do Git por meio de 'git filter-repo' + limpar visualizações SHA de commit em cache do GitHub"]
    F --> I
    G --> I
    H --> J{"Os bots automatizados acumularam uma conta de nuvem de US$ 1.000 a US$ 100.000 ou mais?"}
    J -->|"SIM"| K["Abrir caso de suporte de faturamento da AWS/GCP -> Enviar auditoria de segurança pós-correção + Solicitar perdão único de cortesia por fraude/leak Bill"]
    J -->|"NÃO"| I

Parte 1: Kill-Switch e Matriz Forense Provedor por Provedor (First 5 Minutes)¶

Use esta tabela de referência para localizar o botão de revogação exato, o comportamento automático da verificação secreta do GitHub e o vetor de persistência oculto para sua credencial vazada.

Parte 2: Aprofundamento: Como expulsar um invasor de sua conta AWS (The 4-Step Cloud Eviction Protocol)¶

Porque vazou AWS credenciais carregam o maior raio de explosão financeira (up to $50,000+ per day in EC2/SageMaker/Bedrock bills), você deve executar todas as quatro etapas abaixo sempre que um AKIA... ou ASIA... chave atinge um repositório público:

+-----------------------------------------------------------------------------+
|     ANATOMY OF A 60-SECOND AUTOMATED AWS GITHUB SCRAPER BOT ATTACK          |
+-----------------------------------------------------------------------------+
|                                                                             |
|  [ SEC 00 ] Developer runs 'git push origin main' with .env (AKIA...)       |
|       |                                                                     |
|  [ SEC 04 ] Bot scrapes GitHub Events API Firehose -> Extracts AKIA key     |
|       |                                                                     |
|  [ SEC 06 ] Bot calls 'sts:GetCallerIdentity' & 'sts:GetSessionToken'       |
|       |     (Mints temporary ASIA... token that survives AKIA deletion.)    |
|       v                                                                     |
|  +----+------------------------------------------------------------------+  |
|  | [ SEC 15 TO 90: PARALLEL MULTI-REGION EXPLOITATION ]                  |  |
|  |  1. Persistence: Calls 'iam:CreateUser' / 'iam:CreateAccessKey'       |  |
|  |     (Creates hidden user 'aws-support-backup' with AdministratorAccess)|  |
|  |  2. Compute Abuse: Launches Auto-Scaling Groups of c6i.32xlarge /     |  |
|  |     g5.48xlarge in 12 regions + AWS Bedrock / SageMaker LLM endpoints |  |
|  |  3. Spam Abuse: Calls 'ses:PutAccountSendingAttributes' (50k emails)  |  |
|  |  4. Data Exfiltration: Lists & downloads S3 buckets / RDS snapshots   |  |
|  +-----------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------+

Etapa 1: mate a estática AKIA Chave E Tudo Cunhado ASIA Tokens de sessão¶

Excluindo o AKIA chave no Console AWS não invalida STS credenciais já emitidas por sts:GetSessionToken. Para eliminar tudo imediatamente por meio da AWS CLI (using a separate clean admin profile):

# 1. Delete the compromised Access Key immediately
aws iam delete-access-key --user-name CompromisedUser --access-key-id AKIAIOSFODNN7EXAMPLE

# 2. Attach an explicit 'Deny All' inline policy to the IAM User to immediately
#    invalidate any STS tokens minted by that user AND block all further actions:
aws iam put-user-policy --user-name CompromisedUser --policy-name EmergencyKillSwitch \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }]
  }'

Etapa 2: localizar usuários, funções e chaves de acesso do Backdoor IAM no CloudTrail¶

Execute estes comandos da AWS CLI para verificar se o bot criou um usuário backdoor IAM oculto ou anexou uma chave de acesso secundária a uma de suas contas de funcionários existentes durante a janela:

# List all IAM users created recently across the account
aws iam list-users --query 'Users[?CreateDate>=`2026-10-30`].[UserName,CreateDate]' --output table

# Audit CloudTrail for every API call made by the compromised user in the last 24 hours
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=CompromisedUser \
  --max-results 50 \
  --query 'Events[].[EventTime,EventName,EventSource]' --output table

Etapa 3: varrer tudo 30+ Regiões da AWS para instâncias Rogue EC2, grupos de Auto Scaling e trabalhos Bedrock/SageMaker¶

Por que as vítimas ainda recebem um $12,000 fatura no final do mês depois de "verificarem o painel do EC2 e não verem nenhuma instância"? Como o Console AWS mostra apenas uma região por vez (e.g., us-east-1), enquanto o bot girava 20 instâncias em ap-south-1 (Mumbai), eu-north-1 (Stockholm), e sa-east-1 (Sao Paulo) e os escondeu dentro de EC2 Auto Scaling Groups (ASGs) para que, se você encerrar a instância do EC2 manualmente, o Auto Scaling Group inicie uma substituição 30 seconds mais tarde.

Execute este bash multirregional para listar todas as instâncias EC2 em execução ou pendentes em cada região ativa da AWS em 10 seconds:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "=== Checking Region: $region ==="
  aws ec2 describe-instances --region "$region" \
    --filters "Name=instance-state-name,Values=running,pending,stopped" \
    --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,LaunchTime]' \
    --output table
done

Parte 3: Desvendando o Segredo da História do Git (git-filter-repo) e limpando o cache de commit oculto do GitHub¶

Depois que a credencial estiver inoperante no nível do provedor, você deverá remover a string secreta do repositório do seu repositório. .git comprometa o histórico para que nem colegas de trabalho nem futuros scrapers possam vê-lo (and so GitHub's Push Protection stops blocking your branches).

1. Por que git rm .env + git commit NÃO remove o segredo do Git¶

Correndo git rm .env && git commit -m "remove env" remove apenas o arquivo do latest commit (HEAD); o segredo do texto simples permanece permanentemente legível dentro do commit pai (the parent commit) para qualquer pessoa que clicar em "Commits" no GitHub.

2. Reescreva o histórico do repositório de forma limpa usando git-filter-repo¶

1. Se apenas o último commit (HEAD) continha o segredo (and nobody else has pulled it yet):

   # Remove the sensitive file from the staging index while keeping it on your local disk
   git rm --cached .env
   echo ".env" >> .gitignore
   git add .gitignore
   git commit --amend --no-edit
   git push --force-with-lease origin main
   

2. Se o segredo estiver enterrado em vários commits no seu histórico (or inside a code file you want to keep): Usar git-filter-repo (the official, fast replacement recommended by Git and GitHub instead of the deprecated git filter-branch):

   # Option A: Completely purge a file (.env) from every commit in history
   git filter-repo --path .env --invert-paths --force
   
   # Option B: Replace a specific secret string with '***REMOVED***' across all files in history
   echo "sk_live_51NzExampleSecretKey12345==>***REMOVED***" > expressions.txt
   git filter-repo --replace-text expressions.txt --force
   
   # Force-push the rewritten history to GitHub across all branches and tags
   git push origin --force --all
   git push origin --force --tags
   

3. A armadilha oculta do cache do GitHub (Dangling Commit SHAs)¶

Mesmo depois de você correr git filter-repo e git push --force, Os servidores web do GitHub ainda mantêm o commit SHA antigo e não referenciado ("pendente") ativo e acessível publicamente em https://github.com/<owner>/<repo>/commit/<old-40-char-sha> (and in any forks or Pull Requests) até que a coleta de lixo seja executada. - Como limpar um commit SHA armazenado em cache no GitHub imediatamente: 1. Copie o completo 40-character commit SHA do commit vazado antes de reescrever o histórico. 2. Abrir https://support.github.com/contact -> peça para "Remover dados confidenciais / Limpar visualizações em cache para um commit SHA inacessível" no repositório owner/repo e forneça o commit SHA exato (or use the GitHub Support portal's automated cache-purge workflow).

Parte 4: Como conseguir um $5,000 to $100,000+ Projeto de lei do AWS ou GCP Bot dispensado (The Courtesy Forgiveness Appeal)¶

E se você empurrasse um .env arquivo na tarde de sexta-feira, não verifiquei seu e-mail até segunda de manhã e acordei com um **$28,400.00 Fatura da AWS ou Google Cloud ** de bots de mineração de criptografia ou proxy LLM?

NÃO entre em pânico e NÃO cancele seu cartão de crédito ou solicite um estorno bancário ainda. Ambos Amazon Web Services (AWS) e Google Cloud Platform (GCP) ter uma política interna estabelecida de ajuste único de cobrança por vazamento de credencial acidental/crédito de cortesia para desenvolvedores individuais, estudantes e startups, desde que você preencha 100% da lista de verificação obrigatória de correção de segurança antes da equipe de revisão de faturamento avaliar sua apelação.

O protocolo de isenção de faturas AWS/GCP em 5 etapas (90%+ Success Rate for First-Time Leaks)¶

1. Conclua primeiro todas as etapas de correção de segurança (AWS Will Reject Your Waiver Until the Account Is Clean):
   • Exclua a chave de acesso do IAM comprometida (and the IAM User if possible).
   • Encerre todas as instâncias EC2, grupos de Auto Scaling, volumes EBS, Elastic IP, instâncias RDS e buckets S3 não autorizados em todas as regiões (verify via AWS Cost Explorer and AWS Billing -> Bills -> Charges by Region that daily accrual has dropped back to $0.00).
   • Ativar MFA de hardware ou aplicativo autenticador (Multi-Factor Authentication) na sua conta raiz da AWS e em todos os usuários do IAM.
2. Abra um caso de suporte em "Account and Billing" (Free for All AWS/GCP Tiers, No Paid Support Plan Required):
   • Vá para console.aws.amazon.com/support/home -> Criar caso -> Conta e cobrança -> Serviço: Faturamento -> Categoria: Disputar uma cobrança/conta comprometida.
3. Envie este resumo factual exato de remediação e dificuldades:
   • Reconheça o cronograma e a causa: Indique claramente quando a chave foi acidentalmente exposta no GitHub (e.g., "October 30 at 22:14 UTC") e quando foi revogado ("October 31 at 09:05 UTC").
   • Detalhe as cobranças não autorizadas por região e serviço: Liste os valores exatos em dólares da atividade fraudulenta do bot em comparação com sua fatura mensal histórica normal (e.g., "My normal monthly AWS bill for the past 8 months is $14.50/month in us-east-1; the unauthorized charges total $18,420.12 across ap-east-1, eu-north-1, and sa-east-1 EC2/Bedrock usage").
   • Confirme 100% de correção: Marque as etapas exatas que você já concluiu (1. Deleted IAM key AKIA...; 2. Terminated all unauthorized resources across all regions; 3. Audited CloudTrail for backdoor users; 4. Enabled Root & IAM MFA; 5. Configured AWS Budgets alerts).
   • Solicite educadamente um ajuste único de cobrança de cortesia: Explique que você é um desenvolvedor individual/estudante/startup em estágio inicial, que pagar um $18,420 uma conta de bot não autorizada causaria graves dificuldades financeiras e solicitaria um crédito/isenção única de cobrança de cortesia pelo uso fraudulento.
4. Troque ou limite temporariamente seu cartão de pagamento vinculado se o faturamento automático for iminente:
   • Enquanto seu caso do AWS Billing Support estiver em análise (which usually takes 5 to 15 business days enquanto as equipes de segurança e serviços de faturamento da AWS verificam se todos os recursos não autorizados foram encerrados), entre em contato com o AWS Support dentro do ticket e peça que coloquem uma retenção temporária de faturamento (defer auto-charge) na fatura contestada para que sua conta bancária não seja saque a descoberto enquanto o ajuste de crédito estiver sendo processado.

(Para incidentes de segurança de desenvolvedor e trabalho remoto relacionados, consulte Queda acidental de banco de dados de produção, git force-push, vazamento secreto e triagem de incidentes, Banco de dados de produção descartado ou bucket S3 excluído sem backup recente, Folha de pagamento confidencial, PII do cliente ou planilha HIPAA enviada acidentalmente por e-maile Segurança de trabalho remoto de emergência e privacidade de dados.)

Violação de dados regional e autoridades de relatórios de segurança na nuvem¶

Perguntas frequentes¶

Se eu percebesse que empurrei um .env arquivo para um repositório público do GitHub e tornei o repositório privado 2 minutos depois, ainda preciso girar minhas chaves?¶

Sim, 100 por cento das chaves desse arquivo devem ser consideradas comprometidas e revogadas imediatamente. Os bots automatizados de coleta de credenciais não esperam que o Google indexe seu repositório; eles se inscrevem diretamente no serviço público em tempo real do GitHub `Events API` mangueira de incêndio (`and GH Archive`), que transmite todos os públicos `PushEvent` globalmente dentro de 1 a 3 segundos após o seu `git push`. No momento em que você clicou em "Configurações -> Alterar visibilidade do repositório -> Tornar privado" dois minutos depois, dezenas de scraper bots automatizados já haviam baixado seu commit diff e enfileirado suas credenciais AWS, Stripe, OpenAI e banco de dados para exploração.

Por que os bots continuaram lançando instâncias do EC2 na minha conta da AWS mesmo depois de eu excluir as instâncias vazadas? AKIA chave de acesso?¶

Excluindo uma estática `AKIA...` a chave de acesso no AWS IAM desativa apenas aquela chave permanente específica; não invalida temporário `ASIA...` Serviço de token de segurança (`STS`) tokens de sessão que o invasor já gerou usando `sts:GetSessionToken` ou `sts:AssumeRole` durante os primeiros segundos após raspar sua chave (`which remain valid for up to 12 to 36 hours`). Além disso, os scripts de ataque automatizados da AWS chamam rotineiramente `iam:CreateUser` e `iam:CreateAccessKey` no primeiro segundo de acesso para plantar uma segunda conta de administrador backdoor oculta. Para interromper completamente uma invasão ativa da AWS, você deve excluir o `AKIA` chave, anexe um explícito `Deny *` política inline para o usuário IAM comprometido (`which immediately invalidates all minted STS tokens`) e auditar o CloudTrail para quaisquer usuários ou funções do IAM recém-criados.

A AWS ou o Google Cloud perdoarão uma enorme $10,000+ cobrar se hackers roubarem minha chave de API do GitHub e minerarem criptografia?¶

Na grande maioria dos primeiros vazamentos acidentais, sim, desde que você aja rapidamente, coopere totalmente com a equipe de segurança e não ignore a fatura. Tanto a AWS quanto o Google Cloud têm uma política interna única de ajuste de cobrança de cortesia para desenvolvedores e pequenas empresas atingidas por picos de vazamento de credenciais não autorizados. Antes de solicitar a isenção de fatura no suporte "Conta e faturamento", você deve primeiro provar que o vazamento está 100% fechado: revogar as chaves IAM expostas, encerrar todas as instâncias de computação e grupos de Auto Scaling não autorizados em todas as mais de 30 regiões globais, ativar a autenticação multifator (`MFA`) em sua conta raiz e configure alertas de custo do AWS Budgets.

Por que git rm .env não remover minha chave secreta do GitHub?¶

Git é um livro de controle de versão imutável: quando você executa `git rm .env` e enviar um novo commit, o Git registra apenas que o arquivo está ausente no snapshot mais recente (`HEAD`), mantendo o conteúdo completo do texto simples de `.env` armazenado permanentemente dentro do commit anterior (`the parent commit`) no histórico de commits do seu repositório. Mesmo se você reescrever sua história com `git filter-repo` e push forçado, qualquer pessoa ainda poderá ler o segredo se você não o tiver revogado no console do provedor. Sempre revogue e gire a chave secreta primeiro no painel do seu provedor de nuvem e depois use `git filter-repo` para limpar a string morta do seu histórico de commits.

Guias relacionados¶

• Queda acidental de banco de dados de produção, git force-push, vazamento secreto e triagem de incidentes
• Banco de dados de produção descartado ou bucket S3 excluído sem backup recente
• Folha de pagamento confidencial, PII do cliente ou planilha HIPAA enviada acidentalmente por e-mail para o destinatário errado
• Compartilhamento acidental de tela de folha de salário confidencial, gerenciador de senhas ou lista de demissões no Zoom/Teams
• Segurança de trabalho remoto de emergência e privacidade de dados
• Números de emergência

Fontes e orientações oficiais¶

• Amazon Web Services (AWS Security Incident Response Guide & AWS Knowledge Center: "What should I do if I notice unauthorized activity or exposed IAM access keys?"): AWSCompromisedKeyQuarantineV2 Comportamento político, invalidação de temporário STS Tokens de sessão (RevokeOldSessions) e auditoria de recursos multirregionais.
• Documentação do GitHub (GitHub Secret Scanning, Push Protection, & "Removing sensitive data from a repository" using git-filter-repo): Programa de revogação automática de parceiros (Stripe, AWS, OpenAI, NPM), git-filter-repo Reescrita de histórico e limpeza de SHAs de commit em cache inacessíveis.
• ** Stripe Inc.Stripe Developer Security Guide: API Key Rotation & Compromised Key Incident Triage):** Imediato sk_live_ Expiração de chave, auditoria /v1/events e /v1/webhook_endpointse Restringindo chaves por meio de rk_live_ Escopos.
• NIST (Special Publication 800-61 Rev. 2 / Rev. 3: Computer Security Incident Handling Guide) e OWASP (Secrets Management Cheat Sheet): Contenção de credenciais, Federação de identidade de carga de trabalho OIDC efêmera (replacing static CI/CD keys) e verificação secreta pré-confirmação.