Static Analysis — Cheat Sheet

Tags: static-analysis, ast, eslint, sonarqube, linter, sast, code-quality

Level: intermediate

TL;DR: Analisi del codice sorgente a riposo senza esecuzione, essenziale per intercettare bug sintattici, vulnerabilità di sicurezza e deviazioni da standard architetturali prima del runtime.

Key concepts

Analisi eseguita direttamente sul codice sorgente o bytecode senza avviare l'applicazione.

Parsing del codice in un Abstract Syntax Tree (AST) per analizzare nodi, pattern e flussi di controllo.

Shift-left security: rilevamento precoce delle vulnerabilità SAST direttamente nelle fasi di scrittura o commit.

Control Flow Analysis (CFA) per identificare percorsi non raggiungibili e race condition logiche.

Data Flow Analysis e Taint Analysis per tracciare input utente non sanificati verso sink vulnerabili.

Regole deterministiche per enforce di convenzioni stilistiche, modular boundaries e vincoli di complessità ciclomatica.

Integrazione su pipeline CI/CD come quality gate bloccante prima del merge.

Typical questions and ready answers

Q: Qual è la differenza sostanziale tra Static Analysis (SAST) e Dynamic Analysis (DAST)?R: La static analysis analizza il codice a riposo senza runtime e copre il 100% dei branch sintattici; la dynamic analysis testa l'applicazione attiva dall'esterno, rilevando problemi di configurazione o ambiente ma richiedendo percorsi eseguibili.

Q: Come gestisci gli eccessi di falsi positivi nei report di analisi statica?R: Calibro le severity disattivando le regole a basso valore aggiunto, introduco baseline per il debito tecnico pregresso e impongo verifiche automatiche solo sul codice differenziale delle Pull Request.

Q: In che modo un linter differisce da uno scanner di sicurezza statico avanzato?R: Un linter analizza principalmente AST locali per stile e costrutti rischiosi immediati; uno scanner avanzato esegue Taint Analysis inter-procedurale su grafi complessi per scovare exploit.

Pitfalls and common mistakes

Trattare l'analisi statica come sostituto dei test funzionali unitari o di integrazione.

Bloccare le pipeline su centinaia di segnalazioni storiche invece di applicare la policy del Clean as You Code.

Disattivare le regole tramite commenti inline non documentati (es. eslint-disable) senza tracciamento.

Trascurare i tempi di esecuzione in CI: mancato caching dell'AST su progetti di grandi dimensioni.

Snippets and commands

# Esecuzione linting TypeScript con emissione report SARIF per GitHub Security
npx eslint src/ --ext .ts,.tsx --format @microsoft/eslint-formatter-sarif --output-file results.sarif

JSON

// eslint.config.js - Configurazione rule deterministica
export default [
  {
    rules: {
      "no-unused-vars": ["error", { "argsIgnorePattern": "^_" }],
      "no-eval": "error"
    }
  }
];

To review

[ ] Configurazione della Taint Analysis per endpoint esposti

[ ] Integrazione di report SARIF nei Security Gate di GitHub Actions

[x] Differenza architetturale tra Linter, SAST e DAST

Jarvis Interviews
Jarvis