A BrassCoders descobriu segredos codificados diretamente em dois dos quinze scripts Python gerados por IA que examinou, expondo um risco concreto para desenvolvedores que copiam e colam código diretamente de saídas de modelos de linguagem de grande escala. As descobertas mostram que uma única chave ou senha mal posicionada pode transformar um trecho de código útil em um vazamento de credenciais em ambientes de controle de versão e de produção.

O que o teste revelou

O primeiro script, token_check.py, foi produzido a partir de um prompt que solicitava uma função para assinar tokens de sessão e incluir um “exemplo utilizável”. Para tornar o código executável, o modelo inseriu uma chave de assinatura HMAC literal diretamente no arquivo de origem.

  • Problema: A chave secreta reside na base de código.
  • Risco: Qualquer pessoa com acesso de leitura ao repositório pode ver a chave, e qualquer implantação que puxe o arquivo herda o segredo.
  • Consequência: Um invasor que obtenha a chave pode forjar tokens de sessão válidos, contornando as verificações de autenticação.

O segundo script, email_sender.py, respondeu a uma solicitação de uma função que envia e-mail via SMTP. O modelo forneceu novamente uma senha literal para que o exemplo funcionasse pronto para uso.

  • Problema: A senha aparece como uma string de texto simples na chamada da função.
  • Risco: Rotacionar a senha exige uma alteração no código e uma nova implantação, e a credencial se espalha para todos os ambientes que utilizam o arquivo.
  • Consequência: A senha pode ser coletada do controle de código-fonte, logs ou pacotes compilados, dando a um adversário acesso não autorizado ao servidor de e-mail.

Por que a IA fornece segredos

Modelos de linguagem de grande escala geram texto completando o prompt. Quando um usuário solicita um “exemplo utilizável”, o modelo interpreta isso como “código que funciona sem configuração adicional”. Portanto, ele preenche valores ausentes — chaves de API, senhas, tokens — com espaços reservados plausíveis. O modelo não tem consciência das melhores práticas de gerenciamento de segredos, a menos que o prompt as mencione explicitamente.

Uma análise recente da Veracode de código gerado por IA descobriu que 45% dos trechos contêm pelo menos uma vulnerabilidade listada no OWASP Top 10, com a exposição de credenciais representando uma parcela considerável. A estatística ressalta que o problema não é isolado a alguns casos excepcionais; é um subproduto sistêmico de como esses modelos são treinados e instruídos.

Etapas de mitigação que os desenvolvedores podem adotar agora

A defesa mais simples é manter qualquer segredo fora do próprio arquivo de código. Variáveis de ambiente são o método mais comum e independente de linguagem:

# token_check.py – secure version
import os
import hmac
import hashlib

SECRET_KEY = os.environ["HMAC_SECRET_KEY"]

def sign_token(data: bytes) -> str:
    return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()

# email_sender.py – secure version
import os
import smtplib

smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)

O uso de os.environ busca o valor do ambiente de execução, mantendo-o fora do controle de versão e permitindo a rotação sem tocar nos arquivos de origem. O mesmo padrão funciona com arquivos de configuração que são excluídos de commits, serviços de gerenciamento de segredos ou segredos orquestrados por containers.

Salvaguardas adicionais

  • Revisões de código que sinalizem strings literais correspondentes a padrões comuns de segredos (ex: sequências alfanuméricas longas).
  • Ferramentas de análise estática ajustadas para detectar credenciais codificadas em arquivos recém-adicionados.
  • Engenharia de prompt: peça explicitamente ao modelo para “usar variáveis de ambiente para todos os segredos” ou “omitir credenciais reais”.
  • Linting pós-geração: execute um script rápido que procure por literais suspeitos antes de copiar o código para um projeto.

Contraponto: Isso significa que o código de IA é inseguro?

A presença de segredos codificados diretamente não implica que o código gerado por IA seja universalmente inseguro. Em muitos casos, o modelo produz uma lógica limpa e bem estruturada que pode acelerar o desenvolvimento. O risco surge quando os desenvolvedores tratam a saída como pronta para produção sem uma auditoria de segurança. Trate a IA como um assistente de rascunho, não como um substituto para práticas de segurança estabelecidas.

O que observar a seguir

  • Atualizações de ferramentas: plataformas de IA estão começando a incorporar filtros de segurança que substituem segredos por placeholders. Monitorar essas mudanças pode reduzir a exposição.
  • Mudanças de política: organizações podem formalizar diretrizes para codificação assistida por IA, exigindo verificações de gerenciamento de segredos como parte do pipeline de CI.
  • Padrões da comunidade: à medida que os desenvolvedores compartilham mais “prompts seguros”, modelos de melhores práticas podem se tornar o padrão para tarefas comuns, como assinatura de tokens ou envio de e-mail.

Resumo: A IA pode produzir código funcional em segundos, mas, a menos que os desenvolvedores imponham uma disciplina de gerenciamento de segredos, a conveniência traz um custo oculto — credenciais expostas que podem comprometer um sistema inteiro. Trate cada trecho de código como um rascunho, remova quaisquer segredos literais e injete-os por meio de variáveis de ambiente ou um cofre dedicado antes de realizar o commit.