O chamado que ninguém quer atender
Imagine receber, numa sexta-feira à tarde, a seguinte mensagem no Slack da empresa: "a tabela de usuários ficou exposta em um endpoint público, alguém já baixou os dados." É basicamente esse cenário startup em hipercrescimento, código subindo rápido, QA correndo atrás do prejuízo que motiva este artigo. Fui chamado como consultor de Qualidade e Segurança para uma startup fictícia que sofre exatamente com isso: bugs constantes em produção e vazamento de dados. A proposta aqui não é vender medo, é mostrar como SAST, DAST e uma suíte de testes automatizados bem desenhada resolvem esse problema sem travar a velocidade de entrega que, cedo ou tarde, é o motivo pelo qual controles de segurança são vistos como "vilões" dentro de squads de produto.
***1. Fundamentação: o que são SAST e DAST, e onde eles entram no CI/CD*
SAST — Static Application Security Testing:
SAST é uma análise estática: a ferramenta lê o código-fonte, bytecode ou binário sem executar a aplicação. É chamada de teste "caixa-branca" porque tem visibilidade total da lógica interna. O SAST varre o repositório em busca de padrões inseguros conhecidos SQL Injection por concatenação de string, segredos e chaves de API hardcoded, uso de algoritmos criptográficos fracos, falhas de controle de acesso no próprio código e aponta exatamente o arquivo e a linha onde o problema está.
