Codex Technomanticus

SAST e SCA para código AI

Leitura de 11 min

SAST e SCA para código AI

Um agente de codificação abre um PR às 2h da manhã, gerado a partir de um prompt “adicione um endpoint de upload de arquivo”. O código funciona, os testes passam, o reviewer humano dá uma olhada rápida e aprova — está sob pressão de prazo e o diff parece razoável. Três semanas depois, um pentest externo encontra path traversal no endpoint: open(f"./uploads/{filename}") sem sanitização, porque o modelo “esqueceu” de validar o input do jeito que times experientes fariam por reflexo. O time nem estranha o CWE-22 — é exatamente a classe de erro que LLMs cometem com mais frequência, e que passou batido porque não havia SAST bloqueando o merge. Esse é o cenário que motiva esta nota: código gerado por IA precisa de detecção automatizada, em CI, porque o volume e a velocidade de geração tornam review humano insuficiente como única camada de defesa.

TL;DR

Static Application Security Testing (SAST) analisa código em busca de vulnerabilidades; Software Composition Analysis (SCA) analisa dependências em busca de vulns conhecidas e pacotes maliciosos. Para código IA, rode os dois, em CI, em todo commit. Semgrep + Snyk Code (ou CodeQL) é a combinação dominante em 2026. Use 2+ ferramentas SAST simultaneamente — pesquisa mostra que 78% dos issues confirmados são pegos por só uma ferramenta. Foque rules em CWE-918 (SSRF), CWE-78 (command injection), CWE-89 (SQLi), CWE-798 (hardcoded creds) — os mais comuns em código LLM.

SAST vs SCA — quem pega o quê

SASTSCA
O que analisaSeu códigoDependências
PegaXSS, SQLi, command injection, race conditionsCVEs em libs, slopsquat, licenças
QuandoCada commitCada commit + alerta contínuo
Falsos positivosMédioBaixo
CustoTempo de scanTempo de scan + manutenção de allowlist

Os dois são complementares. Times pulam SCA pensando “uso só libs famosas” — exatamente onde slopsquat e CVEs aparecem.

Top SAST tools 2026

ToolForte emModelo
SemgrepRules customizáveis, rapidíssimo (~10s scan), zero FP em OWASP benchmarkOpen source + cloud
Snyk CodeDeepCode AI, IDE integration real-time, fix suggestionsSaaS
CodeQL (GitHub)Semantic analysis, queries declarativas, indirect data flowFree para repos públicos
SonarQube/CloudQuality + security, dashboards corporativosSelf-hosted ou SaaS
CheckmarxEnterprise SAST, compliance focusSaaS
VeracodeCompliance + binary analysisSaaS
DryRun SecurityPR-native scanningSaaS

Rule prioritization para AI code

Veracode e DryRun mostram que LLMs falham consistentemente em algumas classes:

CWEVulnerabilidadePor que LLMs falham
CWE-80XSSTemplates sem auto-escape; modelo não detecta context
CWE-89SQL InjectionString concat em queries; modelo “esquece” parametrização
CWE-918SSRFURLs construídas com input; modelo não valida hosts
CWE-78Command Injectionsubprocess.run(f"cmd {user_input}")
CWE-22Path Traversalopen(f"./{user_input}")
CWE-502Insecure Deserializationpickle.loads(network_data)
CWE-798Hardcoded CredentialsAPI keys em código
CWE-117Log Injectionlog.info(f"User: {user}") sem sanitização
CWE-943NoSQL InjectionMongoDB com $where sem validação

Configure suas SAST rules para alta sensibilidade nestes. Aceite alguns false positives — eles são de longe menos custosos que false negatives.

Configuração mínima — Semgrep

# .semgrepignore — coisas a pular
node_modules/
build/
*.test.ts
 
# .github/workflows/semgrep.yml
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          docker run --rm -v $(pwd):/src \
            returntocorp/semgrep \
            --config=auto \
            --error \
            --severity=ERROR \
            --severity=WARNING

--config=auto carrega Semgrep Registry com regras para a stack detectada. --error faz CI falhar se vulnerabilidade for achada.

Para código IA, considere também:

- run: semgrep --config=p/owasp-top-ten --config=p/secrets --config=p/python-correctness

Configuração mínima — Snyk Code

# CLI
snyk auth
snyk code test
 
# Em CI (GitHub Actions):
- uses: snyk/actions/setup@master
- run: snyk code test --severity-threshold=medium

Snyk Code adiciona fix suggestions automatizadas. Útil em PR comments — dev vê o problema E a correção.

Configuração mínima — CodeQL

# .github/workflows/codeql.yml
on:
  pull_request:
  schedule:
    - cron: '0 0 * * 1'  # weekly
 
jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript,python
          queries: security-extended
      - uses: github/codeql-action/analyze@v3

security-extended query suite cobre os CWEs principais com semantic analysis (segue data flow através de chamadas).

A regra dos 78%

Pesquisa essencial

“In testing, 78% of confirmed vulnerabilities were caught by only a single tool.” — DryRun Security, 2026

Significa: rodar só uma ferramenta deixa passar 78% dos issues que outra ferramenta acharia. Combine: Semgrep + Snyk, ou CodeQL + Snyk, ou Semgrep + CodeQL.

Combo recomendado para 2026:

  • Semgrep (velocidade, customização, OSS)
  • + Snyk Code OU CodeQL (semantic analysis, dataflow)
  • + Snyk Open Source ou Socket.dev (SCA)

Fluxo de decisão — onde cada ferramenta entra

O diagrama abaixo resume a decisão que este documento defende: nunca uma ferramenta só, sempre pelo menos uma de cada categoria (SAST semântico + SAST rápido + SCA de CVE + SCA comportamental), com gate bloqueante no merge.

flowchart TD
    A[PR aberto com código gerado por IA] --> B{Passa por CI}
    B --> C[SAST rápido: Semgrep<br/>config auto + owasp-top-ten + secrets]
    B --> D[SAST semântico: CodeQL ou Snyk Code<br/>data flow, indirect calls]
    B --> E[SCA de CVE: Snyk Open Source<br/>ou GitHub Dependabot]
    B --> F[SCA comportamental: Socket.dev<br/>ou Aikido - detecta slopsquat pré-CVE]

    C --> G{Algum finding crítico?}
    D --> G
    E --> G
    F --> G

    G -->|Sim| H[CI falha - flag --error<br/>PR bloqueado até remediar]
    G -->|Não| I[Merge liberado]

    H --> J[Fix aplicado - manual ou AI-assisted]
    J --> K[Re-scan obrigatório<br/>fix de IA carrega o mesmo risco do código original]
    K --> B

SCA — focando em slopsquat

Para slopsquat e supply chain:

ToolForte em
Snyk Open SourceCVE database grande, fix suggestions
Socket.devDetecção de pacote malicioso (não só CVE)
Endor LabsReachability analysis (vuln só conta se chega em runtime)
Aikido SecuritySlopsquat detection nativo
GitHub DependabotFree, integrado

Socket.dev — destaque

Socket detecta comportamento suspeito em pacotes (post-install scripts, network exfil, obfuscation) — não depende de CVE estar publicada. Crítica em 2026 para detectar slopsquat antes da CVE ser conhecida.

Pipeline integrado — exemplo completo

name: Security Pipeline
 
on: [push, pull_request]
 
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      # SAST tool 1
      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >
            p/owasp-top-ten
            p/secrets
            p/python-correctness
 
      # SAST tool 2 (different engine)
      - name: CodeQL
        uses: github/codeql-action/analyze@v3
 
      # SCA — code dependencies
      - name: Snyk Open Source
        uses: snyk/actions/python@master
        with:
          args: --severity-threshold=high
 
      # SCA — slopsquat / behavioral
      - name: Socket Security
        uses: socketsecurity/action@v1

Tempo total target: <8min. Custo de NÃO ter: incidente em prod.

AI-assisted remediation

Padrão emergente em 2026

Ferramentas começam a oferecer auto-fix por LLM para findings. Snyk Code, Semgrep Assistant, GitHub Copilot autofix.

Cuidado: AI-fix carrega mesmo risco de 45% inseguro. Trate fix gerado como código novo: passa pelo mesmo SAST de novo.

Métricas que importam

MétricaAlvo
% PRs com finding crítico bloqueadoVariável, mas existir
Mean time to remediate (MTTR)<1 dia para críticos, <1 semana para médios
% findings com false positive<15% (acima → calibre rules)
Cobertura de SAST (% LOC scaneadas)>90%
Tempo CI total para SAST + SCA<10 min

Anti-patterns

  • Rodar SAST como warning, não erro — todo mundo ignora warnings
  • Single-vendor SAST — perde 78% (regra de DryRun)
  • SCA só em PRs grandes — slopsquat entra via PR pequeno
  • Sem allowlist de licenças — copyleft em proprietário causa pesadelo legal
  • Ignorar SCA “porque uso só libs famosas” — slopsquat ataca exatamente assim
  • AI auto-fix sem re-scan — fix pode introduzir issue diferente

Armadilhas comuns

SAST como warning não para nada

A configuração mais perigosa é ter Semgrep ou CodeQL rodando em CI mas sem flag --error — os findings aparecem nos logs, o CI passa, e ninguém olha. A diferença entre SAST como gate e SAST como decoração é uma flag de configuração. Times que “têm SAST configurado” mas não bloqueiam PR em findings críticos têm o custo sem o benefício.

Aceitar "AI auto-fix" sem re-scan cria loop de vulnerabilidades

Ferramentas como Snyk Code e Semgrep Assistant oferecem correções automáticas geradas por LLM para os findings. O problema é que a correção AI carrega exatamente o mesmo risco que o código original: pode conter vulnerabilidade diferente, pode reintroduzir a mesma vuln com outra forma, pode quebrar a correção semanticamente. AI-fix deve passar pelo mesmo pipeline SAST que qualquer outro código gerado.

Não fazer SCA "porque uso só libs famosas"

Slopsquatting não atinge só libs obscuras — atinge exatamente o espaço adjacente às libs mais comuns, onde o modelo confla nomes (axios-fetch, react-codeshift). E CVEs em libs famosas existem — o npm advisory database tem entradas em Express, lodash, moment. SCA não é opcional para times que usam geração por IA.

Como explicar em inglês

SAST and SCA are complementary tools that address different layers of security risk in AI-generated code. SAST analyzes the code itself — finding SQL injection patterns, hardcoded credentials, XSS vulnerabilities, and command injection. SCA analyzes the dependency graph — catching known CVEs in libraries and detecting behavioral signals of malicious packages like slopsquat targets.

For AI-generated code specifically, both need calibration. LLMs fail consistently on a predictable set of CWEs: XSS in 86% of samples, SQL injection in ~50%, SSRF increasingly common. Tuning SAST rules to high sensitivity on those specific classes, and accepting some false positives in exchange for lower false negative rate, is the right trade-off when the alternative is a vulnerability in production.

The most important finding from DryRun Security research is the 78% single-tool rule: 78% of confirmed vulnerabilities were found by only one of the tools tested. This means running a single SAST tool gives a false sense of coverage. The minimum viable configuration is two complementary scanners — Semgrep for speed and customizability, CodeQL or Snyk Code for semantic data flow analysis.

In a technical interview, you might say:

“We run two SAST tools in combination — Semgrep with OWASP and secrets rulesets, plus CodeQL for semantic data flow analysis — because research shows 78% of confirmed vulnerabilities are caught by only a single tool. For SCA we use both Snyk Open Source for CVE detection and Socket.dev for behavioral analysis of packages, which is critical for catching slopsquat targets before a CVE is even published. All of these are hard blocks in CI, not warnings. The LLM-specific tuning is high sensitivity on CWE-80, 89, 918, and 798 — the classes where LLMs fail most consistently.”

PTEN
análise estática de segurançastatic application security testing (SAST)
análise de composição de softwaresoftware composition analysis (SCA)
vulnerabilidade confirmadaconfirmed vulnerability
falso positivofalse positive
falso negativofalse negative
injeção SQLSQL injection
requisição forjada do lado do servidorserver-side request forgery (SSRF)
injeção de comandocommand injection
credenciais fixas no códigohardcoded credentials
análise de fluxo de dadosdata flow analysis

O que vem a seguir

Com SAST e SCA cobrindo análise estática e dependências, a próxima camada de defesa é o ambiente de execução. Mas sandboxing vai além de “rodar em container” — é sobre definir o que o agente pode e não pode fazer: quais sistemas de arquivo pode tocar, quais chamadas de rede pode fazer, quais operações privilegiadas estão fora do alcance. A próxima nota explora permissões e sandboxing como fronteira de contenção para workflows agênticos.

  • 06 - Permissões e sandboxing — como configurar o ambiente de execução para que código AI não possa causar dano além do escopo permitido

Veja também

Referências

Visão de gráfico

Backlinks