Um segredo que chega ao git já está comprometido

O momento que importa

O momento que importa não é quando alguém encontra uma chave de API escrita direto num repositório. É o git commit, o instante em que o valor literal de um segredo é gravado num objeto de commit. Tudo depois disso é só um jeito diferente de descobrir um estrago já feito: alguém do time clonando o repo, um runner de CI fazendo checkout, um fork público. Este curso trata de pegar o problema no único momento em que ainda dá para evitá-lo, antes desse commit.

O que este app já faz certo

Duas entradas no .gitignore deste projeto existem para manter segredos fora desse primeiro commit:

/.env*

# Ignore master key for decrypting credentials and more.
/config/master.key

O config/master.key descriptografa o config/credentials.yml.enc, o cofre criptografado de segredos deste app; sem a chave, o arquivo criptografado não serve para quem clonar o repo. O .env* cobre qualquer arquivo de ambiente local que alguém use para valores de cada máquina. Conferindo os arquivos rastreados deste repositório (git ls-files), nem o config/master.key nem nenhum arquivo .env* aparecem, então a regra se manteve na prática, e não só no papel.

Por que uma linha no .gitignore não resolve tudo

Uma entrada no .gitignore só barra um arquivo que alguém apontou antes como sensível. Ela não faz nada contra um segredo digitado numa linha de Ruby, JavaScript ou YAML de outro arquivo. Pense num valor como API_KEY = "sk-live-abc123..." num arquivo comum e rastreável. Esse tipo de segredo não tem nome de arquivo para bloquear, porque o arquivo em que ele está deve mesmo ser rastreado. Pegá-lo exige algo que leia o conteúdo do arquivo, além do nome. Essa é a lacuna que um detector de segredos, humano ou automático, existe para cobrir.

Onde a IA entra

Um assistente de IA que revisa um diff antes do commit pode receber uma pergunta estreita: algo neste diff parece uma credencial digitada como valor literal? É uma tarefa mais mecânica do que "revise este código atrás de bugs", mais perto de uma checagem de padrão do que de um julgamento. "Prompting de IA: zero-shot" mostrou que uma pergunta estreita e bem especificada recebe uma resposta mais confiável do que uma vaga.

O que este curso cobre

1. Como um segredo escrito no código aparece para um detector: sinais do nome e formato do valor juntos.
2. Onde um segredo deve ficar, com os dois padrões que este app usa.
3. Por que falsos positivos são a parte mais difícil de montar um detector confiável.
4. Pedir a uma IA que revise um diff atrás de segredos, uma pergunta mais estreita do que uma revisão geral.
5. O que precisa acontecer quando um segredo já entrou num commit, já que apagá-lo depois não basta.
6. Um pequeno detector com regex, montado e conferido à mão.

No fim, "esta linha deixa um segredo escrito no código?" vira uma pergunta específica e verificável, com uma resposta mecânica, em vez de um palpite esperançoso feito depois.