SAST: análise estática de segurança no código

1. O que é SAST e por que desenvolvedores devem se importar

SAST (Static Application Security Testing) é uma técnica de teste de segurança que analisa o código-fonte, bytecode ou binários de uma aplicação sem executá-la. Diferentemente do DAST (Dynamic Application Security Testing), que testa a aplicação em execução, e do IAST (Interactive Application Security Testing), que combina elementos de ambos, o SAST examina o código estaticamente, identificando padrões inseguros antes mesmo da compilação.

O SAST é peça fundamental na estratégia "Shift Left" — mover a segurança para as fases iniciais do desenvolvimento. Quando um desenvolvedor descobre uma vulnerabilidade durante a codificação, o custo de correção é drasticamente menor do que se ela fosse encontrada em produção. Estudos indicam que corrigir um problema de segurança durante a implementação custa até 30 vezes menos do que corrigi-lo após o lançamento.

Para desenvolvedores, os benefícios são diretos:
- Detecção precoce: vulnerabilidades são encontradas enquanto o código ainda está sendo escrito
- Redução de custos: menos retrabalho e correções emergenciais
- Conformidade: ajuda a atender requisitos de padrões como OWASP Top 10, PCI-DSS e ISO 27001

2. Tipos de vulnerabilidades detectadas por ferramentas SAST

Ferramentas SAST são capazes de identificar uma ampla gama de vulnerabilidades. Vejamos as categorias mais comuns:

Injeção de código

// Exemplo de SQL Injection detectado por SAST
String query = "SELECT * FROM usuarios WHERE email = '" + email + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);
// SAST alerta: uso de concatenação em query SQL

// Exemplo de XSS detectado por SAST
app.get("/busca", (req, res) => {
  const termo = req.query.q;
  res.send("<h1>Resultados para: " + termo + "</h1>");
  // SAST alerta: saída não sanitizada de entrada do usuário
});

Gerenciamento de segredos

# Exemplo de hardcoded credentials detectado por SAST
API_KEY = "sk-1234567890abcdef"
DB_PASSWORD = "senha_super_secreta"
# SAST alerta: credenciais hardcoded no código-fonte

Configurações inseguras

// Exemplo de criptografia fraca detectado por SAST
MessageDigest md = MessageDigest.getInstance("MD5");
// SAST alerta: MD5 é considerado inseguro para hash de senhas

# Exemplo de permissões inseguras
app.use(express.static('public'));
app.disable('x-powered-by');
# SAST alerta: falta de headers de segurança como Content-Security-Policy

3. Integração do SAST no fluxo de desenvolvimento

A integração do SAST em pipelines de CI/CD é essencial para automatizar a segurança. Aqui estão exemplos práticos:

GitHub Actions

name: SAST Scan
on:
  pull_request:
    branches: [main]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten
          audit_on: push

GitLab CI

sast:
  stage: test
  script:
    - semgrep --config=auto --error .
  only:
    - merge_requests
  allow_failure: false  # Bloqueia merge se encontrar vulnerabilidades críticas

Estratégias de fail/pass: para pull requests, configure o bloqueio apenas para vulnerabilidades de severidade alta ou crítica. Vulnerabilidades médias podem gerar alertas sem bloquear, permitindo que a equipe priorize sem paralisar o desenvolvimento.

4. Escolhendo e configurando ferramentas SAST

Critérios de seleção

  • Linguagens suportadas: verifique se a ferramenta cobre as linguagens do seu stack
  • Taxa de falsos positivos: ferramentas com muitas regras genéricas podem gerar ruído
  • Licenciamento: open-source (Semgrep, SonarQube Community) vs. comercial (Checkmarx, Snyk Code)
  • Customização: capacidade de criar regras específicas para seu domínio

Exemplos práticos

Semgrep: ferramenta open-source com regras customizáveis

# Regra customizada para detectar debug em produção
rules:
  - id: no-debug-production
    patterns:
      - pattern: console.log(...)
      - pattern: print(...)
    message: "Remova logs de debug antes do deploy"
    languages: [javascript, python]
    severity: WARNING

SonarQube: análise contínua com qualidade de código e segurança

# Configuração de quality gates no SonarQube
sonar.exclusions=**/generated/**
sonar.security.sources=java,js,ts
sonar.security.auditors=owasp

5. Interpretando e tratando resultados do SAST

Como ler relatórios

Um relatório SAST típico contém:

Vulnerabilidade: SQL Injection
Severidade: CRÍTICA (CVSS 9.8)
CWE: CWE-89
Arquivo: src/dao/UsuarioDAO.java
Linha: 45
Código: String query = "SELECT * FROM usuarios WHERE id = " + id;
Sugestão: Use prepared statements ou consultas parametrizadas

Priorização de vulnerabilidades

Use a matriz de priorização:
- CVSS 9.0-10.0: Corrigir imediatamente (bloqueia merge)
- CVSS 7.0-8.9: Corrigir no mesmo sprint
- CVSS 4.0-6.9: Agendar para próximo sprint
- CVSS 0-3.9: Aceitar risco ou marcar como falso positivo

Estratégias de remediação

// Antes - vulnerável
String query = "SELECT * FROM usuarios WHERE id = " + id;

// Depois - corrigido
String query = "SELECT * FROM usuarios WHERE id = ?";
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setInt(1, id);

6. Limitações e armadilhas comuns do SAST

Falsos positivos e negativos

Ferramentas SAST podem gerar falsos positivos quando não compreendem o contexto completo da aplicação. Por exemplo:

// Falso positivo comum: sanitização indireta
function getUser(id) {
  // SAST alerta: possível SQL Injection
  // Mas id já foi sanitizado pelo framework ORM
  return db.query("SELECT * FROM users WHERE id = ?", [id]);
}

Limitações em linguagens dinâmicas

JavaScript e Python, por serem dinamicamente tipados, apresentam desafios:

# Python: SAST pode não detectar injeção via eval()
user_input = request.form['code']
result = eval(user_input)  # SAST pode perder se eval estiver encapsulado

Cobertura incompleta

SAST não cobre:
- Vulnerabilidades em dependências de terceiros (use SCA - Software Composition Analysis)
- Configurações de runtime (use DAST)
- Lógica de negócio complexa (use code review manual)

7. SAST como parte de uma estratégia de segurança holística

Combinação com outras práticas

Uma estratégia completa de segurança para devs inclui:

Pipeline de Segurança Integrado:

1. SAST (análise estática) → durante commits e PRs
2. SCA (análise de dependências) → verificação de bibliotecas
3. DAST (testes dinâmicos) → em ambientes de staging
4. Code Review Manual → para lógica crítica
5. Pentest → antes de releases importantes

Criando uma cultura de segurança

  • Treinamento: workshops semanais sobre vulnerabilidades comuns
  • Automação de feedback: notificações no Slack/Discord quando SAST encontra issues
  • Métricas: acompanhe redução de vulnerabilidades ao longo do tempo
Métricas de sucesso:
- Vulnerabilidades críticas encontradas antes do merge: +40% no primeiro trimestre
- Tempo médio de correção (MTTR): de 7 dias para 2 dias
- Falsos positivos reportados: redução de 60% após customização de regras

Referências

  • Semgrep Documentation — Documentação oficial da ferramenta SAST open-source Semgrep, com guias de regras, integrações e exemplos práticos
  • SonarQube Security Analysis — Guia oficial sobre análise de segurança no SonarQube, incluindo regras OWASP e CWE
  • OWASP Static Analysis — Recurso da OWASP sobre análise estática, com boas práticas e ferramentas recomendadas
  • Snyk Code Documentation — Documentação oficial do Snyk Code para análise SAST, com exemplos de integração em CI/CD
  • GitLab SAST Documentation — Guia completo de implementação de SAST no GitLab CI, incluindo configuração de regras e análise de resultados
  • Checkmarx Documentation — Documentação técnica da ferramenta Checkmarx SAST, com guias de customização e integração
  • CWE - Common Weakness Enumeration — Catálogo oficial de fraquezas de software usado como base por ferramentas SAST para classificação de vulnerabilidades