02 - SAST - Analisi Statica del Codice e Rilevamento Vulnerabilità

SAST: Cos'è l'Analisi Statica del Codice

SAST (Static Application Security Testing) e una tecnica di analisi che esamina il codice sorgente senza eseguirlo, alla ricerca di pattern che indicano vulnerabilità di sicurezza. A differenza del testing dinamico che richiede un'applicazione in esecuzione, SAST opera direttamente sul codice, permettendo di individuare problemi nelle primissime fasi di sviluppo.

SAST analizza il codice alla ricerca di vulnerabilità come SQL injection, cross-site scripting (XSS), buffer overflow, hardcoded credentials, insecure deserialization e molte altre. Gli strumenti SAST costruiscono un modello del codice (AST - Abstract Syntax Tree) e applicano regole di sicurezza per identificare pattern problematici.

In questo articolo esploreremo i principali strumenti SAST, la loro integrazione nella pipeline CI/CD e le strategie per gestire uno dei problemi più comuni: i false positives.

SAST vs DAST vs IAST: Le Differenze

Per scegliere gli strumenti giusti, e fondamentale capire le differenze tra i tre approcci principali di security testing:

L'approccio ottimale e utilizzare tutti e tre in modo complementare: SAST per il feedback rapido durante lo sviluppo, DAST per validare la sicurezza runtime e IAST per correlazione precisa durante i test.

SonarQube: Analisi Completa della qualità del Codice

SonarQube e la piattaforma SAST più diffusa, utilizzata da oltre 400.000 organizzazioni. Oltre alla sicurezza, analizza qualità del codice, code smells, duplicazioni e copertura dei test. La versione Community e open source e copre 30+ linguaggi di programmazione.

Setup con Docker Compose

Il modo più rapido per avviare SonarQube in locale o in un ambiente di staging e tramite Docker Compose:

# docker-compose.sonarqube.yml
version: "3.8"
services:
  sonarqube:
    image: sonarqube:lts-community
    container_name: sonarqube
    ports:
      - "9000:9000"
    environment:
      - SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonarqube
      - SONAR_JDBC_USERNAME=sonar
      - SONAR_JDBC_PASSWORD=sonar_password
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_logs:/opt/sonarqube/logs
      - sonarqube_extensions:/opt/sonarqube/extensions
    depends_on:
      - db

  db:
    image: postgres:15
    container_name: sonarqube-db
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar_password
      - POSTGRES_DB=sonarqube
    volumes:
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_data:
  sonarqube_logs:
  sonarqube_extensions:
  postgresql_data:
      

Integrazione in GitHub Actions

L'integrazione di SonarQube nella pipeline CI/CD con GitHub Actions permette di eseguire l'analisi automaticamente ad ogni push o pull request:

# .github/workflows/sonarqube.yml
name: SonarQube Analysis
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v3
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

      - name: SonarQube Quality Gate
        uses: SonarSource/sonarqube-quality-gate-action@v1
        timeout-minutes: 5
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      

Semgrep: Analisi Statica Leggera e Personalizzabile

Semgrep e uno strumento SAST open source creato da Return Security (ora Semgrep Inc.) che si distingue per la semplicità nella creazione di regole custom. A differenza di SonarQube che richiede un server, Semgrep può essere eseguito come semplice tool da linea di comando.

La potenza di Semgrep sta nel suo linguaggio di pattern matching che permette di scrivere regole di sicurezza in modo intuitivo, quasi come scrivere il codice che si vuole trovare.

Scrivere Regole Custom Semgrep

Ecco un esempio di regola Semgrep per individuare SQL injection in applicazioni Python:

# .semgrep/sql-injection.yml
rules:
  - id: python-sql-injection
    patterns:
      - pattern: |
          cursor.execute($QUERY)
      - pattern-not: |
          cursor.execute($QUERY, $PARAMS)
      - metavariable-pattern:
          metavariable: $QUERY
          patterns:
            - pattern: |
                f"..."
    message: >
      Possibile SQL injection: la query SQL utilizza f-string
      invece di parametri preparati. Usa cursor.execute(query, params)
      con placeholder %s per prevenire injection.
    severity: ERROR
    languages: [python]
    metadata:
      cwe:
        - "CWE-89: Improper Neutralization of Special Elements"
      owasp:
        - "A03:2021 - Injection"
      confidence: HIGH
      

Integrazione in CI/CD

Semgrep si integra facilmente in qualsiasi pipeline CI/CD. Ecco la configurazione per GitHub Actions:

# .github/workflows/semgrep.yml
name: Semgrep Security Scan
on:
  push:
    branches: [main]
  pull_request:

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        run: |
          semgrep scan \
            --config auto \
            --config .semgrep/ \
            --sarif --output semgrep-results.sarif \
            --error \
            --severity ERROR

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep-results.sarif
      

CodeQL: L'Analisi Semantica di GitHub

CodeQL e il motore di analisi sviluppato da GitHub che tratta il codice come dati interrogabili. A differenza di Semgrep che usa pattern matching, CodeQL costruisce un database relazionale del codice e permette di scrivere query complesse per trovare vulnerabilità.

CodeQL eccelle nell'analisi taint tracking: la capacità di seguire il flusso dei dati dall'input utente (source) fino a operazioni sensibili (sink), verificando se i dati vengono sanitizzati lungo il percorso.

Gestione dei False Positives

Uno dei problemi maggiori con gli strumenti SAST e il tasso di false positives: alert che segnalano vulnerabilità che in realta non esistono. Un tasso di false positives troppo alto erode la fiducia del team negli strumenti e porta all'alert fatigue, dove i developer iniziano a ignorare tutti gli alert.

Strategie per Ridurre i False Positives

• Tuning delle regole: disabilitare regole non rilevanti per il contesto dell'applicazione
• Esclusioni mirate: escludere file generati, test, vendor code
• Baseline: stabilire una baseline e concentrarsi solo sui nuovi finding
• Prioritizzazione: focalizzarsi prima su CRITICAL e HIGH severity
• Suppression comments: marcare i false positives con commenti documentati

# Esempio di suppression in codice Python
import hashlib

# Questo uso di MD5 e per checksum, non per sicurezza
# nosemgrep: python-weak-hashing
file_hash = hashlib.md5(file_content).hexdigest()  # noqa: S303

# Esempio di suppression per SonarQube
password = get_env("DB_PASSWORD")  # NOSONAR - password da env var, non hardcoded
      

Quality Gates: Quando Bloccare il Deploy

Un Quality Gate definisce le soglie minime di qualità e sicurezza che il codice deve rispettare per poter essere rilasciato. E il meccanismo che trasforma SAST da tool informativo a gate bloccante nella pipeline.

SAST nell'IDE: Feedback Immediato

Lo shift-left più efficace e portare l'analisi SAST direttamente nell'IDE del developer. Questo permette di individuare e correggere vulnerabilità mentre si scrive il codice, prima ancora del commit.

• SonarLint: plugin per IntelliJ, VS Code, Eclipse. Connesso a SonarQube per sincronizzare le regole
• Semgrep VS Code Extension: evidenzia i finding direttamente nell'editor
• GitHub Copilot: suggerisce fix di sicurezza contestuali

L'integrazione nell'IDE riduce il feedback loop da minuti (CI/CD) a secondi, aumentando drasticamente la probabilità che il developer corregga il problema immediatamente.

Best Practice per SAST

Dopo aver implementato SAST in diversi progetti enterprise, ecco le best practice che raccomandiamo:

1. Iniziare in modalità non bloccante: i primi 2-4 sprint, SAST genera solo report senza bloccare il deploy. Questo permette al team di familiarizzare con gli strumenti
2. Stabilire una baseline: registrare il numero di finding esistenti e focalizzarsi sulla riduzione progressiva
3. Focus sul nuovo codice: applicare soglie stringenti solo al codice nuovo, per evitare di bloccare il team su debito tecnico legacy
4. Regole custom per il contesto: creare regole Semgrep/CodeQL specifiche per i pattern dell'applicazione
5. Review settimanale dei finding: dedicare 1-2 ore settimanali al triage dei finding SAST con il Security Champion
6. Metriche e trend: tracciare MTTR, false positive rate e vulnerability density nel tempo

Conclusioni

SAST e il primo livello di difesa nel paradigma DevSecOps. Individuare vulnerabilità nel codice sorgente prima che venga eseguito permette di risparmiare tempo, denaro e rischi. La chiave del successo e l'equilibrio tra copertura e usabilita: troppe regole generano alert fatigue, troppo poche lasciano passare vulnerabilità critiche.

Nel prossimo articolo esploreremo DAST (Dynamic Application Security Testing), il complemento naturale di SAST che analizza le applicazioni in esecuzione per trovare vulnerabilità runtime come XSS, CSRF e misconfiguration.