Segredos à mostra: como uma linha de código pode matar um projeto

Por que a ilusão de segurança custa tão caro

Muitos pensam «é um repo privado» ou «vou comentar essa linha antes do commit». Na prática isso falha cedo ou tarde. Eis as três armadilhas principais:

1. O Git não esquece nada. Se você commitar sem querer um arquivo com a senha do banco ou uma chave de gateway de pagamento, apagar no próximo commit não resolve. O segredo fica para sempre no histórico do Git. A um atacante (ou a um júnior curioso) basta olhar o histórico.
2. O efeito copiar-colar. Com a configuração fixa, mover a app de Dev para Stage ou Prod vira um campo minado. É preciso trocar chaves à mão a cada deploy. Um erro de digitação, e o servidor de teste começa a cobrar dinheiro real da conta de produção.
3. Vazamentos por prints e logs. O que está fixo aparece em logs de erro, traces ou na tela durante o pair programming. As variáveis de ambiente ficam invisíveis ao código — vivem no nível do servidor.

O padrão-ouro da PolyCode Systems

Criamos um processo simples, mas sem concessões. Não exige ferramentas enterprise caras, e sim disciplina de ferro.

• O arquivo .env existe, mas não no repo. Na raiz há sempre um .env.example — um modelo com todas as variáveis necessárias (ex. DB_HOST=, STRIPE_API_KEY=) sem valores. O dev copia, renomeia para .env e põe suas chaves. O próprio .env está estrita e permanentemente no .gitignore.
• Acesso isolado. O código não deve saber onde roda. Ele só pede ao sistema: «me dê o token do banco». No local, vem de um arquivo local; em produção, das configurações de ambiente pela interface de infraestrutura (ex. Coolify ou as variáveis do servidor Linux).
• Chaves no CI/CD. No build e deploy automáticos, os segredos passam só pelas configurações seguras do pipeline (ex. GitHub Secrets), que os injetam direto no build. Sem enviar arquivos de config em pacotes.

Da teoria à prática

Vejamos o antipadrão clássico. Iniciantes costumam começar assim:

O antipadrão

// ❌ How NOT to do it (a straight path to grey hair)
export const dbConfig = {
  host: "192.168.1.100",
  user: "admin",
  password: "SuperSecretPassword123" // Hello, public repository!
};

Parece que migrar para variáveis de ambiente é só trocar por process.env.PASSWORD. Mas vamos além. Ler process.env é metade. A outra metade é validação estrita na inicialização (fail fast). Se faltar a chave do banco, a app não deve iniciar. Melhor cair com estrondo no start do que subir em silêncio e jogar 500 nos usuários reais. Eis o padrão em TypeScript (com zod) que virou nosso padrão:

O padrão-ouro: validar o ambiente

// ✅ Gold standard: validate the environment
import { z } from 'zod';

// 1. Declare the variables we truly need
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  API_SECRET_KEY: z.string().min(10),
  NODE_ENV: z.enum(['development', 'test', 'production']).default('development'),
});

// 2. Validate whatever the system gave us
const env = envSchema.safeParse(process.env);

if (!env.success) {
  console.error('❌ Critical error: missing environment variables', env.error.format());
  process.exit(1); // Hard-stop the application
}

// 3. Export a typed config for the whole project
export const config = env.data;

Onde está a mágica?

E no seu time?

Como seu time entrega os segredos dos desenvolvedores ao DevOps? Já teve vazamentos épicos de chaves em produção? Conte sua história nos comentários.