Do diagnóstico à engenharia.

Existe um intervalo conhecido entre o relatório e a correção. O relatório descreve o problema com precisão, a equipe concorda com ele, e ainda assim a correção não acontece — porque o time está ocupado, porque a mudança exige refatoração, porque ninguém sabe exatamente onde tocar, ou porque corrigir de verdade custa mais do que o orçamento previsto para isso.

Engenharia de segurança existe para fechar esse intervalo. É o trabalho de implementar a correção com a mesma seriedade com que ela foi diagnosticada: entender o código, projetar a mudança, escrever, integrar, testar e acompanhar o comportamento depois.

Isso vale tanto para uma correção pontual quanto para o desenho de um controle que ainda não existe.

• Correção de achados — implementar o que uma avaliação anterior identificou, quando não há equipe disponível para fazê-lo.
• Desenho de controle — projetar e implementar um controle que ainda não existe: autenticação, autorização, segregação de ambiente, limite de permissão para agentes.
• Endurecimento de integração — reduzir a confiança transferida entre sistemas que se comunicam, validando novamente o que hoje é aceito por origem.
• Automação de verificação — levar verificações de segurança para dentro do processo de desenvolvimento, onde elas rodam sem depender de disciplina manual.
• Resposta a incidente — conter, entender o caminho usado e fechar a causa real, não apenas o sintoma observado.
• Acompanhamento contínuo — revisar mudanças relevantes ao longo do tempo, em vez de uma avaliação isolada que envelhece.

O trabalho é técnico e é conduzido dentro da stack existente do cliente. Não há aqui a promessa de uma plataforma proprietária, de um produto próprio de segurança ou de tecnologia desenvolvida internamente que ainda não exista. O que é entregue é engenharia aplicada ao ambiente do cliente, com o ferramental que aquele ambiente já usa — ou com o mínimo de ferramental novo necessário, sempre acordado antes.

Toda alteração em produção é previamente autorizada, planejada com janela definida e reversível.

• Correção implementada — código e configuração aplicados, revisados e integrados ao fluxo do cliente.
• Registro da mudança — o que mudou, por quê, e qual era a condição anterior que a justificava.
• Verificação — procedimento reproduzível que comprova o funcionamento do controle.
• Documentação operacional — o que a equipe do cliente precisa saber para manter aquilo funcionando sem depender de quem escreveu.
• Recomendações seguintes — o que ficou fora desta rodada e por quê, sem transformar isso em lista aberta indefinida.