Checklist de segurança para lançamento de um novo sistema

Todo lançamento tem prazo apertado, e segurança costuma ser a primeira coisa deixada para "depois". O problema é que "depois" muitas vezes significa depois que o sistema já está exposto e recebendo tráfego real — inclusive de quem está procurando falhas.

• O ambiente de produção usa credenciais e segredos diferentes dos usados em desenvolvimento e testes?
• Todas as rotas administrativas exigem autenticação e não estão indexáveis por buscadores?
• Mensagens de erro exibidas ao usuário não revelam detalhes internos do sistema (stack trace, versão de software, estrutura de banco)?
• Existe HTTPS forçado em todas as páginas, sem exceção?
• Headers de segurança básicos (como Content-Security-Policy e X-Frame-Options) estão configurados?
• Backups do banco de dados já foram testados com uma restauração real, não só configurados?
• Existe um responsável definido para monitorar erros e comportamento anômalo nas primeiras semanas após o lançamento?
• Dependências e bibliotecas usadas no projeto estão atualizadas e sem vulnerabilidades conhecidas?
• Formulários públicos têm alguma proteção contra automação abusiva (rate limiting, captcha quando apropriado)?
• Existe um plano documentado do que fazer se uma vulnerabilidade crítica for descoberta logo após o lançamento?

Esse checklist não substitui um pentest

Serve como uma primeira triagem, especialmente para sistemas que vão lidar com dados de clientes ou pagamentos desde o primeiro dia. O ideal é que um teste de segurança mais profundo aconteça antes do lançamento — não depois que o sistema já estiver em uso real.