Static Analysis — Cheat Sheet

Tag: static-analysis, sast, ast, linting, code-quality, security, devops

Livello: intermedio

TL;DR: Ispezione automatizzata del codice sorgente senza esecuzione runtime per individuare bug, vulnerabilità (SAST), code smell e violazioni di standard stilistici.

Concetti chiave

Analizza il codice sorgente o bytecode a riposo, senza avviare il processo a runtime.

I linter e tool base analizzano Abstract Syntax Tree (AST) tramite pattern matching rapido.

La Control Flow Analysis (CFA) traccia i possibili percorsi di esecuzione logica.

La Data Flow Analysis mappa propagazione e mutazioni dei valori tra variabili e chiamate.

La Taint Analysis traccia dati non fidati da sorgenti (sources) a operazioni pericolose (sinks).

I sanitizers o validatori interrompono la propagazione del taint prima dei sink.

Integra i controlli a shift-left direttamente nell'IDE e tramite quality gate nella pipeline CI/CD.

Si differenzia da SCA (dipendenze esterne) e DAST (test a scatola nera su applicazione avviata).

La gestione del rumore richiede tuning continuo per ridurre i falsi positivi.

Domande tipiche e risposte pronte

Q: Qual è la differenza tra linter sintattico e strumento SAST avanzato?R: Il linter analizza pattern locali su AST per stile e bug superficiali; il SAST esegue analisi inter-procedurale di flusso dati e taint tracking per individuare vulnerabilità complesse.

Q: Come gestisci un alto numero di falsi positivi quando introduci la static analysis?R: Stabilisco una baseline iniziale senza bloccare il team, disattivo le regole con troppo rumore e applico i quality gate solo sul codice nuovo aggiunto nelle PR.

Q: In che cosa differiscono SAST, DAST ed SCA nella pipeline?R: SAST ispeziona il codice proprietario a riposo, DAST testa le vulnerabilità runtime a scatola nera su ambiente attivo, SCA scansiona le dipendenze di terze parti per CVE note.

Insidie e errori comuni

Abilitare centinaia di regole contemporaneamente causando alert fatigue e disattivazione dei gate.

Bloccare le build su tutto il debito tecnico pregresso anziché solo sul differenziale delle PR.

Dimenticare che l'analisi statica non rileva problemi di business logic o configurazioni d'ambiente runtime.

Confondere la formattazione cosmetica del codice con l'analisi semantica di sicurezza.

Snippet e comandi

# Esempio scan rapido con Semgrep usando ruleset OWASP Top 10
semgrep scan --config auto --error

# Esempio esecuzione SonarScanner CLI
sonar-scanner -Dsonar.projectKey=my-project -Dsonar.sources=src

# Esecuzione ESLint focalizzato su errori senza autofix su CI
npx eslint "src/**/*.{js,ts}" --max-warnings=0

YAML

# Esempio gate static analysis su GitHub Actions PR
name: Static Analysis Gate
on: [pull_request]
jobs:
  lint-and-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint

Da ripassare

[ ] Meccanica di Taint Analysis: identificazione precisa di source, sink e sanitizer

[ ] Regole custom di AST matching con Semgrep o CodeQL

[ ] Strategia di baseline e soppressione mirata del debito pregresso in CI/CD

[x] Differenza architetturale tra AST, Control Flow Graph e Call Graph