Análise estática (SAST) — ferramentas, falsos positivos, integração no CI

SAST (Static Application Security Testing) examina o código-fonte — ou bytecode — sem executar a aplicação. É a primeira linha de defesa automatizada no ciclo de desenvolvimento: encontra problemas cedo, quando o custo de correção é baixo.

Como o SAST Funciona

A ferramenta percorre a árvore sintática do código e aplica regras que detectam padrões inseguros:

Código-fonte
    │
    ▼
Parser / AST (Abstract Syntax Tree)
    │
    ▼
Motor de regras (taint analysis, dataflow, pattern matching)
    │
    ▼
Relatório de achados (vulnerabilidade, linha, severidade)

Taint analysis rastreia dados de fontes não confiáveis (HTTP input) até sumidouros perigosos (query SQL, exec, eval). Se o dado chega sem sanitização, a ferramenta sinaliza.

Ferramentas Populares por Linguagem

Linguagem	Ferramenta gratuita/OSS	Ferramenta comercial
Python	Bandit, Semgrep	Checkmarx, Veracode
JavaScript/TS	ESLint security plugin, Semgrep	Snyk Code
Java	SpotBugs + FindSecBugs	SonarQube
Go	Gosec, Semgrep	—
PHP	PHPCS Security Audit	Snyk Code
Multi-lang	Semgrep	SonarQube, Checkmarx

Exemplo com Bandit (Python)

# Instalar
pip install bandit

# Escanear diretório
bandit -r ./src -ll

# Saída típica
>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection via string-based query construction.
   Severity: Medium   Confidence: Medium
   Location: src/db.py:42

Exemplo com Semgrep

# Instalar
pip install semgrep

# Rodar com ruleset de segurança
semgrep --config=p/owasp-top-ten ./src

# Saída
src/auth.py:87: ERROR: Use of MD5 for password hashing detected.

Falsos Positivos — Como Lidar

SAST tem taxa de falso positivo. Uma regra genérica pode acusar código seguro. Estratégias:

1. Triagem por severidade — foque em HIGH/CRITICAL primeiro.
2. Supressão comentada — marca o achado como aceito com justificativa no código:

result = hashlib.md5(data).hexdigest()  # nosec B324 — hash não criptográfico para cache

3. Ajuste de regras — desabilite regras que geram ruído no contexto do projeto.
4. Revisão humana — SAST aponta candidatos; dev confirma se é vulnerabilidade real.

Não suprima achados sem ler. Falso positivo mascarado pode esconder vulnerabilidade real.

Integração no CI/CD

O SAST deve rodar em todo pull request, bloqueando merge se encontrar achados críticos.

# .github/workflows/sast.yml
name: SAST

on: [pull_request]

jobs:
  bandit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Bandit
        run: |
          pip install bandit
          bandit -r ./src -ll --exit-zero-on-skipped -f json -o bandit-report.json
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: bandit-report
          path: bandit-report.json

Para bloquear o merge em achados críticos, use --severity-level high e deixe o comando retornar código de saída não-zero.

Limites do SAST

• Não detecta vulnerabilidades de runtime (race conditions, configuração de servidor).
• Não testa fluxo de dados entre serviços (requer DAST ou análise manual).
• Qualidade depende das regras: regras ruins = muito ruído ou muitas brechas.

SAST é complementar, não substitui revisão de código humana nem testes dinâmicos.