Como proteger chaves API de extensões VS Code maliciosas

Em 20 de maio de 2026, o GitHub confirmou que invasores roubaram dados de aproximadamente 3.800 de seus repositórios de código internos. O ponto de entrada não foi uma zero-day nos servidores do GitHub. Foi uma extensão do VS Code comprometida instalada no laptop de um único funcionário. Uma vez que essa extensão foi executada com as mesmas permissões de sistema de arquivos do desenvolvedor, ela pôde ler tudo ao seu alcance: código-fonte, arquivos de configuração e quaisquer credenciais presentes no workspace. Se você deseja proteger chaves de API da mesma classe de ataque, a lição é desconfortável, mas simples. O elo mais fraco raramente é a nuvem. É a máquina do desenvolvedor e as ferramentas que nela são executadas.

TL;DR

Para proteger as chaves de API contra uma extensão de IDE comprometida ou um repositório vazado, pare de armazenar credenciais ativas onde as ferramentas de desenvolvimento podem lê-las. Mantenha os segredos fora do código-fonte e dos arquivos .env commitados. Trate o .gitignore como uma conveniência, não como um controle de segurança. Delimite cada chave a um único ambiente, use credenciais de curta duração e com o menor privilégio, e rotacione-as regularmente. Ferramentas como o Apidog ajudam mantendo as credenciais de API em variáveis de ambiente com valores apenas locais, em vez de texto simples espalhado pelo seu repositório e workspace.

Por que a violação do GitHub é um alerta para todo desenvolvedor

O incidente do GitHub parece um ataque de cadeia de suprimentos clássico. O grupo de ameaças, rastreado como TeamPCP, tem um histórico de trojanizar pacotes em ecossistemas npm, PyPI e PHP. Desta vez, a carga maliciosa chegou por meio de uma extensão do VS Code. De acordo com o relatório do TechCrunch, os invasores exfiltraram dados de cerca de 3.800 repositórios internos e agora estão vendendo o conjunto de dados por mais de US$ 50.000 em fóruns clandestinos. O GitHub afirma não ter evidências de que os dados de clientes armazenados fora desses repositórios internos tenham sido afetados, e a investigação está em andamento.

Aqui está a parte que deve fazer você parar para pensar. Uma extensão do VS Code é apenas código. Quando você instala uma, ela é executada dentro do processo do editor com suas permissões de usuário. Ela pode listar arquivos, abri-los e ler seus conteúdos. Ela pode monitorar alterações de arquivo. Pode fazer requisições de rede de saída. Nada disso é uma vulnerabilidade; é o modelo de extensão funcionando conforme o projetado. A maioria das extensões precisa de acesso a arquivos para realizar seu trabalho. O problema é que uma extensão maliciosa ou comprometida usa exatamente o mesmo acesso para coletar o que encontrar.

O que ela encontra? Em um projeto típico, ela encontra muito. Um arquivo .env na raiz do repositório. Um config/secrets.yml. Um token hardcoded em um script de teste rápido que você pretendia excluir. Credenciais da AWS em ~/.aws/credentials. Um .npmrc com um token de autenticação. Chaves SSH. O grupo TeamPCP é o mesmo ator por trás da campanha do worm npm “Mini Shai-Hulud”, que coletou credenciais de desenvolvedores, CI/CD, nuvem e ferramentas de IA de máquinas infectadas. O padrão é consistente: fazer com que o código seja executado na máquina de um desenvolvedor e, em seguida, procurar por qualquer coisa que se pareça com uma credencial.

Isso não é novo em tipo, apenas em perfil. Escrevemos sobre um padrão de exposição similar em nossa análise das lições de segurança de API da violação da Vercel, e a mecânica da cadeia de suprimentos se alinha de perto com o que abordamos no guia de segurança da cadeia de suprimentos npm. O incidente do GitHub é a mesma história com um nome maior anexado. Então, a pergunta que vale a pena fazer hoje é direta: se uma extensão maliciosa fosse executada em seu editor agora, com o que ela sairia?

Chaves hardcoded e arquivos .env commitados são uma responsabilidade permanente

A maioria dos vazamentos de credenciais não é sofisticada. Eles ocorrem quando um desenvolvedor cola uma chave no código “por enquanto” e se esquece, ou um arquivo .env escapa para um commit. Ambos criam uma vulnerabilidade que permanece em seu repositório indefinidamente.

Chaves hardcoded são o pecado óbvio. Você já deve ter visto um código como este:

import requests

# Teste rápido do endpoint de pagamentos
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"

response = requests.post(
    "https://api.stripe.com/v1/charges",
    auth=(STRIPE_KEY, ""),
    data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)
print(response.json())

Essa chave sk_live_ agora faz parte do arquivo. Ela está no seu diretório de trabalho, onde qualquer extensão pode lê-la. Se o arquivo for commitado, a chave estará em seu histórico Git para sempre, mesmo depois de você excluir a linha em um commit posterior. Qualquer um que clone o repositório, ou qualquer ferramenta que o escaneie, obtém a chave.

O arquivo .env deveria ser a solução. A ideia é sólida: manter segredos fora do código, carregá-los em tempo de execução. Um .env real se parece com isto:

# .env (carregado em tempo de execução, nunca destinado a ser enviado)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350

Isso é melhor do que hardcoding. Mas observe o que não mudou. Esse arquivo ainda reside em seu workspace, em texto simples, legível por todo processo que o editor executa. Uma extensão maliciosa não se importa se seus segredos estão em app.py ou em .env. Ambos são arquivos. Ambos estão a um fs.readFileSync de distância. O padrão .env resolve o problema de “segredos no histórico do Git” apenas se o arquivo nunca for commitado, e não faz absolutamente nada pelo problema de “ferramenta local comprometida”.

O .env commitado é o pior resultado. É alarmantemente comum. Um desenvolvedor adiciona .env ao projeto, escreve chaves reais nele e se esquece de ignorá-lo antes do primeiro commit. Ou um colega de equipe clona o repositório, vê .env.example, copia-o para .env, preenche as chaves de produção, e um git add . posterior o inclui. Agora as credenciais de produção estão no histórico compartilhado de um repositório que pode ser público, pode ser espelhado, ou pode acabar em uma violação como a do GitHub. Aprofundamos no ângulo de vazamento de repositório em nosso artigo complementar sobre documentação de API e segurança de repositórios Git.

.gitignore não é um controle de segurança

Isso merece uma seção própria porque o equívoco é muito difundido. Adicionar .env ao .gitignore parece trancar a porta. Mas não é. É um lembrete que diz “por favor, não pegue isso.”

Aqui está o que o .gitignore realmente faz. Ele diz ao Git para ignorar arquivos não rastreados que correspondam a um padrão quando você executa git add. Esse é o escopo total. Ele tem três modos de falha que importam para a segurança:

1. Não faz nada para arquivos já rastreados. Se o .env foi commitado uma vez, antes de você adicionar a regra de ignorar, o Git continua rastreando-o. A regra de ignorar é silenciosamente substituída. Você precisa executar git rm --cached .env e commitar essa remoção, e o segredo ainda estará em cada commit histórico.
2. Não faz nada para o arquivo no disco. .gitignore é uma instrução do Git. O arquivo .env ainda permanece em seu diretório de trabalho em texto simples. Uma extensão maliciosa do VS Code lê o sistema de arquivos, não o índice do Git. Sua regra de ignorar é invisível para ela. Este é o modo de falha que mais importa para o ataque no estilo GitHub.
3. Está a um erro de distância de ser ignorado. git add -f .env ignora a regra de ignorar. O mesmo acontece ao adicionar o arquivo através da interface de controle de código-fonte de um editor. O mesmo ocorre com um .gitignore diferente em um subdiretório que não repete o padrão.

Você pode confirmar o primeiro ponto por si mesmo. Se você suspeita que um segredo foi commitado alguma vez, este comando mostra:

# Lista cada commit que já tocou o arquivo, mesmo que ele esteja "ignorado" agora
git log --all --full-history --oneline -- .env

# Veja os valores reais dos segredos que ainda estão no histórico
git log -p --all -- .env | grep -iE "key|secret|token|password"

Se isso retornar algo, a credencial estará comprometida no momento em que o repositório for exposto. A solução não é uma regra de ignorar melhor. A solução é rotacionar a chave e remover o arquivo do histórico com uma ferramenta como git filter-repo. A solução mais profunda é garantir que a credencial ativa nunca esteve em um arquivo, para começar.

Ainda vale a pena usar o .gitignore. Ele detecta erros honestos e mantém seus diffs limpos. Apenas não o confunda com uma fronteira que um invasor respeita. É higiene, não defesa.

Escopo, separe, encurte, rotacione: os quatro hábitos que diminuem o raio de impacto

Você não pode garantir que uma credencial nunca vazará. Você pode garantir que uma credencial vazada seja quase inútil. Quatro hábitos fazem a maior parte do trabalho.

Delimite segredos por ambientes

Uma chave vazada deve destravar uma coisa, não todo o seu patrimônio. A falha de escopo mais comum é usar a mesma chave de API em desenvolvimento, staging e produção porque era mais fácil. Quando essa chave vaza, todos os ambientes caem de uma vez.

Dê a cada ambiente suas próprias credenciais. Sua máquina local usa uma chave de desenvolvimento com acesso a um projeto sandbox e dados de teste. Staging usa uma chave de staging. Produção usa uma chave de produção que existe em exatamente um lugar e nunca é copiada para um laptop. Se a chave de desenvolvimento vazar através de uma extensão comprometida, o invasor alcança um sandbox com clientes falsos. Isso é um incômodo, não um incidente.

Separe os ambientes corretamente

A separação de ambientes é mais do que três valores de chave diferentes. Significa que os ambientes não podem se alcançar. O banco de dados de desenvolvimento é um banco de dados diferente, não uma réplica de leitura da produção. O provedor de pagamentos de staging está no modo de teste do provedor, então uma chave de staging vazada não cobra nada real. Ferramentas e humanos não devem ser capazes de apontar uma configuração “dev” para dados de produção simplesmente alterando uma variável.

Quando a separação é real, a pergunta “de qual ambiente veio esta chave?” tem uma resposta clara, e essa resposta lhe diz exatamente quão ruim é um vazamento.

Use chaves de menor privilégio e de curta duração

Duas propriedades decidem o quanto uma chave roubada pode causar de dano.

Privilégio. Uma chave deve possuir o conjunto mais restrito de permissões que sua função exige. Uma construção de frontend que lê um catálogo público de produtos precisa de uma chave somente leitura delimitada a esse recurso específico. Não precisa de acesso de escrita, não precisa de acesso de faturamento, e certamente não precisa de administrador. A maioria dos provedores de API suporta chaves delimitadas ou tokens de granularidade fina; os próprios tokens de acesso pessoal de granularidade fina do GitHub são um bom modelo. Se você está avaliando estilos de token, nossa comparação de chaves de API versus OAuth explica quando tokens OAuth de curta duração superam as chaves estáticas.

Tempo de vida. Uma chave que expira em uma hora é uma recompensa ruim. Quando um invasor compra um conjunto de dados roubado e chega à sua chave, ela já está morta. Chaves estáticas que duram para sempre são o oposto: elas funcionam até que alguém perceba, o que muitas vezes leva meses. Prefira tokens de curta duração emitidos sob demanda. Onde uma chave de longa duração é inevitável, defina a expiração mais curta que o fluxo de trabalho tolera.

Rotacione em um cronograma, não em pânico

Rotação é a alteração do valor de uma credencial para que a antiga pare de funcionar. A maioria das equipes rotaciona apenas após uma violação, com pressa, sob estresse. Esse é o pior momento para descobrir que seu processo de rotação não está documentado.

Em vez disso, rotacione em um cronograma. Escolha um intervalo por classe de credencial; chaves de produção de alto privilégio mensalmente, chaves de menor risco trimestralmente. A rotação rotineira faz duas coisas. Ela limita a vida útil de qualquer vazamento que você ainda não detectou, já que uma chave roubada hoje para de funcionar no próximo ciclo. E mantém a mecânica, atualizando o valor em cada ambiente consumidor, praticada e sem surpresas. Quando um incidente real acontece, a rotação é um botão que você apertou cinquenta vezes, não um exercício de incêndio. Para um tratamento mais completo, veja nosso resumo de ferramentas de gerenciamento de chaves de API.

Mantenha as credenciais em variáveis de ambiente do Apidog, não soltas no seu workspace

Aqui está a apresentação honesta. O Apidog vem com uma extensão para VS Code e um servidor MCP próprios. O argumento não é “nossa ferramenta é imune à classe de ataque que atingiu o GitHub”. Nenhuma ferramenta do lado do cliente é. O argumento é sobre onde seus segredos residem e quão expostos eles ficam quando algo em sua máquina se comporta mal.

Pense no cenário realista. Você está construindo e testando APIs o dia todo. Você precisa de um token de portador, uma chave de API, uma string de conexão de banco de dados. O movimento padrão é colocá-los em um arquivo .env ou em um script para que seu cliente possa usá-los. Isso coloca credenciais ativas em arquivos de texto simples no workspace, que é exatamente a superfície que uma extensão maliciosa raspa. O sistema de ambiente do Apidog muda o local onde esses valores ficam.

Variáveis de ambiente em vez de arquivos de texto simples

No Apidog, você armazena credenciais como variáveis de ambiente, em vez de como texto solto em seu repositório. Uma requisição faz referência à variável por nome, como {{access_token}} em um cabeçalho Authorization, e o Apidog a resolve no momento do envio. O cabeçalho na sua definição de requisição lê Bearer {{access_token}}, não Bearer sk-proj-aB3dEf.... O segredo literal não está em um arquivo .env na raiz do projeto esperando para ser lido.

Isso importa pela mesma razão que o .env supera o hardcoding, levado um passo adiante. A credencial não é mais uma linha de texto simples em um arquivo que reside ao lado do seu código-fonte. É um valor gerenciado dentro do cliente de API, referenciado indiretamente.

Valores locais mantêm os segredos em sua máquina

O Apidog traça uma linha deliberada entre dois tipos de valores para cada variável. Existe um valor compartilhado, ou inicial, que sincroniza com os servidores do Apidog e é visível para sua equipe. E há um valor local, ou atual, que permanece em sua máquina e nunca é enviado. A orientação oficial é explícita: coloque dados sensíveis, como tokens e senhas, no valor local para que nunca saiam do seu cliente.

O efeito prático é que um colega de equipe ao clonar a estrutura do projeto obtém o nome e o formato da variável, access_token, db_password, e o restante, mas não o seu segredo real. Cada desenvolvedor preenche seu próprio valor local. Nenhum token de produção ativo de ninguém é transportado nos dados do projeto sincronizados, e não há um arquivo compartilhado de chaves reais para vazar.

Gerenciamento e isolamento de ambiente

O gerenciamento de ambientes do Apidog é construído em torno do hábito de escopo da seção anterior. Você define ambientes separados, Desenvolvimento, Staging, Produção, e cada um possui sua própria URL base e seu próprio conjunto de valores de variáveis. As variáveis são delimitadas por ambiente: apenas os valores do ambiente ativo estão em vigor, e a troca de ambientes alterna todo o conjunto de credenciais de uma vez.

Isso lhe dá isolamento de ambiente por construção. Sua variável payment_api_key contém uma chave sandbox em Desenvolvimento e uma chave de produção em Produção. Você nunca edita uma requisição para alternar entre elas; você troca o ambiente. Como os valores estão vinculados ao ambiente, uma credencial de desenvolvimento não pode acidentalmente parar em uma chamada de produção, e um segredo de produção nunca precisa existir em seu ambiente de desenvolvimento local. Um ambiente de desenvolvimento vazado expõe valores de desenvolvimento. A produção permanece intocada.

Para equipes que precisam de um limite rígido: segredos de cofre

Se sua equipe precisa que os segredos de produção nunca toquem o cliente API, o plano Enterprise do Apidog adiciona um recurso de Segredo de Cofre que busca segredos diretamente do HashiCorp Vault, Azure Key Vault ou AWS Secrets Manager. O Apidog armazena apenas o caminho do cofre e os metadados. Os valores reais dos segredos são puxados sob demanda, criptografados no cliente local e nunca compartilhados com colegas de equipe através do projeto. O lar da credencial permanece sendo o gerenciador de segredos dedicado, que é exatamente onde uma credencial de produção deve viver.

Para experimentar o fluxo de trabalho de variáveis de ambiente, Baixe o Apidog, crie um projeto, abra o Gerenciamento de Ambiente e adicione suas credenciais como variáveis de ambiente com valores apenas locais. Leva apenas alguns minutos e tira os segredos ativos dos arquivos de texto simples que uma extensão pode ler.

Uma ressalva honesta. Mover segredos para o Apidog reduz a quantidade de credenciais em texto simples que ficam em seu repositório e workspace. Isso não torna sua máquina imune a uma ferramenta comprometida. A defesa em profundidade ainda se aplica: audite as extensões que você instala, mantenha as chaves de produção com o mínimo de privilégio e de curta duração, e rotacione-as regularmente. O Apidog lida com a parte “onde as credenciais vivem”. O resto ainda é com você.

Conclusão

A violação do GitHub é um sinal claro. Os invasores descobriram que a máquina do desenvolvedor, com suas ferramentas confiáveis e seus arquivos de configuração em texto simples, é um alvo mais fácil do que qualquer servidor de produção. Você não pode tornar essa máquina perfeitamente segura. Você pode garantir que uma extensão de IDE comprometida ou um repositório vazado entregue muito pouco a um invasor.

Comece com uma auditoria. Abra o repositório em que você mais trabalha e procure por key, secret, token e password. Verifique se .env está no seu histórico do Git. O que quer que você encontre, trate como exposto: rotacione-o, então mova o valor ativo para um lugar onde uma ferramenta desonesta não possa lê-lo. Baixe o Apidog e coloque seu próximo conjunto de credenciais de API em variáveis de ambiente em vez de um arquivo de texto simples. Para um contexto mais amplo, nossos artigos complementares sobre ferramentas de API auto-hospedadas após a violação do GitHub e ferramentas de gerenciamento de chaves de API são boas leituras a seguir.

FAQ

Uma extensão do VS Code pode realmente ler meu arquivo .env e chaves de API?

Sim. Uma extensão do VS Code é executada dentro do processo do editor com as permissões de arquivo da sua conta de usuário. Ela pode listar diretórios, abrir arquivos e ler seus conteúdos, incluindo arquivos .env, arquivos de configuração e arquivos de credenciais como ~/.aws/credentials. Este é o comportamento normal de uma extensão, já que muitas extensões legitimamente precisam de acesso a arquivos. O risco é que uma extensão maliciosa ou comprometida use o mesmo acesso para coletar segredos. Esse é o mecanismo por trás da violação do GitHub de maio de 2026.

Adicionar .env ao .gitignore é suficiente para proteger as chaves de API?

Não. O .gitignore apenas diz ao Git para ignorar arquivos não rastreados durante git add. Ele não faz nada para arquivos já commitados antes da regra existir, e o segredo permanece no histórico do Git de qualquer forma. Ele também não faz nada para o arquivo no disco: o arquivo .env ainda está em seu workspace em texto simples, totalmente legível por qualquer ferramenta ou extensão local. Trate o .gitignore como uma forma de prevenir erros honestos, não como uma barreira de segurança.

O que devo fazer se encontrar uma chave de API no meu histórico do Git?

Trate-a como comprometida imediatamente, mesmo que o repositório seja privado. Primeiro, rotacione a chave para que o valor exposto pare de funcionar. Em seguida, remova o arquivo do histórico usando uma ferramenta como git filter-repo, e force o push do histórico limpo após coordenar com sua equipe. Finalmente, mova a credencial ativa para fora de qualquer arquivo de texto simples para que o mesmo vazamento não aconteça novamente. Consulte nosso guia de ferramentas de gerenciamento de chaves de API para práticas contínuas.

Como armazenar chaves de API no Apidog reduz minha exposição?

O Apidog permite que você armazene credenciais como variáveis de ambiente e as referencie por nome em requisições, de modo que o segredo literal não esteja em um arquivo .env de texto simples em seu repositório. Cada variável suporta um valor apenas local que permanece em sua máquina e nunca sincroniza com servidores ou colegas de equipe, que é onde a documentação recomenda manter tokens e senhas. Variáveis com escopo de ambiente também mantêm as credenciais de desenvolvimento e produção separadas. Isso reduz o número de segredos ativos que ficam em arquivos que uma ferramenta pode raspar; não torna sua máquina imune a uma ferramenta comprometida.

O Apidog também tem uma extensão para VS Code, e isso é um risco?

Sim, o Apidog vem com uma extensão para VS Code e um servidor MCP. O objetivo deste artigo não é dizer que qualquer ferramenta é imune a ataques de cadeia de suprimentos; nenhuma ferramenta do lado do cliente é. O objetivo é onde seus segredos residem. Manter as credenciais em variáveis de ambiente com valores apenas locais, ou em uma integração de cofre, significa que menos chaves em texto simples são expostas se qualquer ferramenta em sua máquina, incluindo a própria extensão do Apidog, for comprometida. A defesa em profundidade, auditoria de extensões, menor privilégio e rotação ainda se aplicam.

Qual a diferença entre delimitar e rotacionar chaves de API?

A delimitação limita o que uma chave pode fazer e onde se aplica: uma chave de desenvolvimento alcança apenas um sandbox, e uma chave somente leitura não pode escrever. A rotação altera o valor de uma chave em um cronograma para que o valor antigo pare de funcionar. A delimitação diminui o dano que uma chave vazada pode causar; a rotação diminui a janela de tempo em que uma chave vazada permanece útil. Você quer ambos. Usados juntos, uma chave roubada destrava pouco e expira rapidamente.

Com que frequência devo rotacionar as chaves de API?

Rotacione em um cronograma fixo, em vez de apenas após um incidente. Um ponto de partida razoável é mensalmente para credenciais de produção de alto privilégio e trimestralmente para chaves de menor risco, ajustado à sua tolerância ao risco e a quaisquer regras de conformidade. A rotação programada limita a vida útil de vazamentos que você não detectou e mantém o processo de rotação bem praticado, de modo que um incidente real seja rotineiro em vez de um corre-corre.

Chaves de API de produção devem estar em um laptop de desenvolvedor?

Idealmente, não. Uma credencial de produção deve existir no menor número de lugares possível, normalmente em um gerenciador de segredos dedicado e no ambiente de execução de produção, nunca copiada para uma máquina de desenvolvedor. Os desenvolvedores devem trabalhar com credenciais de desenvolvimento ou staging delimitadas a dados não-produção. Se um laptop for comprometido, o invasor alcança um sandbox, não sistemas de clientes reais. O isolamento de ambiente do Apidog e a integração com cofre apoiam isso mantendo os valores de produção fora dos ambientes de desenvolvimento local.