SAST (Static Application Security Testing).

O SAST analisa o código, transformando-o em representações intermédias — uma árvore de sintaxe abstrata (AST), um grafo de fluxo de controlo (CFG) e um grafo de fluxo de dados (DFG) — e depois aplica regras de padrões ou análise de taint para detetar construções inseguras mapeadas para identificadores CWE. A análise de taint é o motor central: marca fontes não confiáveis (um parâmetro HTTP, a leitura de um ficheiro), acompanha como esses dados se propagam através de variáveis e chamadas de função, e levanta um alerta quando estes chegam a um sink perigoso (uma query SQL, exec, uma resposta HTML) sem passar por um sanitizador reconhecido. Como nada é executado, o SAST corre em IDEs, hooks pre-commit e CI, e pode analisar o código muito antes de este entrar em produção.

Os seus pontos cegos estão bem documentados. O SAST é forte em bugs determinísticos (SQL injection, sinks de XSS, segredos hard-coded, criptografia fraca), mas gera falsos positivos em caminhos inacessíveis em tempo de execução, e não deteta falhas de configuração, de lógica de autenticação e as que só se manifestam em runtime — por isso os programas maduros combinam-no com SCA e DAST. Ajustar rulesets e triar o ruído são os verdadeiros custos operacionais. Normas como o OWASP ASVS e o NIST SSDF referenciam a análise estática como um controlo de verificação. Motores comuns incluem o Semgrep, o GitHub CodeQL (que consulta o código como uma base de dados), o SonarQube, o Checkmarx, o Fortify e o Snyk Code.

flowchart LR
  SRC[Código-fonte / bytecode] --> P[Parsing para AST + CFG + DFG]
  P --> T[Análise de taint + regras]
  SO[Fonte não confiável] -. fluxo rastreado .-> T
  T --> SK{Chega a um sink<br/>sem sanitizador?}
  SK -->|Sim| F[Alerta mapeado para CWE]
  SK -->|Não| OK[Sem alerta]
  F --> TR[Triagem: corrigir ou marcar como falso positivo]