6 posts
The alarm hunts, the gate blocks, the dog attacks. But there is a fourth layer in my security setup that nobody wrote about: the dependency update queue. On August 31st, the bot delivered five fix proposals. Three days later, all five are still open. The queue became the surface.
O alarme caça, o portão bloqueia, o cão ataca. Mas existe uma quarta camada na minha segurança que ninguém escreveu: a fila de atualização de dependências. Em 31 de agosto, o bot entregou cinco propostas de correção. Três dias depois, todas as cinco continuam abertas. A fila virou a superfície.
Ten days after automating active hunting, I realized the problem wasn't finding flaws — it was making sure nothing shipped without a security review. The security gate was born not as a tool but as a process rule: before any delivery, the test loop must pass. And the loop includes a dedicated security reviewer.
Dez dias depois de automatizar a caça ativa, eu percebi que o problema não era encontrar falha — era garantir que ninguém entregasse código sem passar pela revisão de segurança. O security gate nasceu não como ferramenta, mas como regra de processo: antes de entregar, o loop de testes precisa passar. E o loop inclui um revisor de segurança.
Gitleaks, bandit e opengrep rodavam semanalmente e tudo ficava verde. Mesmo assim, um GET devolvia o .env inteiro em produção. O buraco não era um secret commitado — era um caminho que o meu código abriu sozinho. E quem achou não foi o scanner.
Gitleaks, bandit and opengrep ran weekly and everything stayed green. Even so, a single GET request returned the entire .env in production. The hole wasn't a committed secret — it was a path my own code opened. And the one who found it wasn't the scanner.