SAST e DAST nel Pipeline — Integrare Analisi Statica e Dinamica nella CI/CD Senza Bloccare il Team

Il codice parte e dopo tre minuti la build fallisce per un falso positivo. Il dev si arrabbia, disabilita lo step e la sicurezza torna a essere carta straccia. Lo vediamo in quasi tutti i progetti che ci arrivano: SAST e DAST vengono attivati, ma nessuno li ha configurati per lavorare con il team, non contro di lui.

Noi, di Meteora Web, lavoriamo su pipeline DevSecOps da anni. Veniamo dalla contabilità, dai bilanci, dal retail: sappiamo che un blocco alla produzione costa più di una vulnerabilità rimandata. Per questo, quando parliamo di SAST (Static Application Security Testing) e DAST (Dynamic Application Security Testing) nel pipeline, ragioniamo in termini di qualità del codice, velocità di delivery e costo del falso positivo. Non di certificazioni a checklist.

Questa guida è per chi ha già una pipeline (GitHub Actions, GitLab CI, Jenkins) e vuole integrare la sicurezza senza trasformare il CI in un collo di bottiglia. Entriamo nel concreto: strumenti, configurazioni, gestione dei risultati e automazione dei test.

Perché integrare SAST e DAST nella pipeline di sviluppo?

Perché una vulnerabilità scoperta in produzione costa in media 6-7 volte di più di una trovata in fase di commit. E non parliamo solo di soldi: parliamo di dati esposti, clienti persi, reputazione. Con SAST analizzi il codice sorgente senza eseguirlo: trovi SQL Injection, XSS, hardcoded secret, dependency vulnerabili. Con DAST simuli attacchi dall'esterno sull'applicazione in esecuzione: trovi misconfigurazioni, errori di autenticazione, logiche esposte.

Noi li mettiamo entrambi nel pipeline perché si completano. SAST da solo non vede errori di runtime. DAST da solo non vede codice morto o librerie vecchie. Insieme coprono l'80% delle vulnerabilità comuni. Il resto lo lasciamo ai penetration test periodici, ma quelli non li automatizzi in CI.

Cosa rischi senza analisi statica e dinamica nel pipeline

• Codice con vulnerabilità che arriva in produzione senza che nessuno le abbia mai viste.
• Dipendenze con CVE note che restano mesi senza aggiornamento.
• Credenziali hardcoded che finiscono su GitHub e vengono scansionate da bot malevoli.
• Errori di configurazione (CORS aperto, mancanza di HTTPS redirect, header di sicurezza assenti).

Quali strumenti SAST scegliere per il tuo stack?

La scelta dipende dal linguaggio e dal budget. Noi usiamo Semgrep per progetti multi-linguaggio (Python, PHP, JavaScript, TypeScript, Java) perché è veloce, ha regole personalizzabili e si integra in 5 minuti con GitHub Actions. Per ambienti PHP/Laravel, PHPStan con estensioni di sicurezza o Psalm funzionano bene. Per Java/Kotlin, SpotBugs con Find Security Bugs. E per i container, Trivy scansiona le immagini Docker per CVE.

Un consiglio pratico: non usare solo uno strumento commerciale “all-in-one” se il tuo stack è eterogeneo. A volte combinare 2-3 tool open source dà copertura migliore e costi zero di licenza.

Esempio concreto: SAST con Semgrep in GitHub Actions

name: SAST

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: returntocorp/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep --config=auto --error --output=semgrep-results.sarif .
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep-results.sarif
          category: semgrep

Questa configurazione esegue Semgrep con regole automatiche su ogni push e PR. Se trova vulnerabilità critiche (error-level), blocca la build. I risultati vengono caricati su GitHub Security Tab. Zero costi di licenza, zero complessità.

Come automatizzare DAST nelle build senza bloccare la produzione?

DAST ha bisogno di un'applicazione in esecuzione. Nel pipeline puoi avere due approcci: DAST su ambiente di staging (più sicuro, ma richiede deploy preliminare) oppure DAST su container temporaneo (più veloce, ma meno rappresentativo). Noi preferiamo il primo: deploy su staging, poi scan con OWASP ZAP in modalità “baseline” o “full”.

Il punto critico: i tempi. Uno scan DAST full può durare 20-30 minuti. Non ha senso metterlo in ogni commit. Noi lo scheduliamo: scan completo su merge in main, scan veloce (baseline) su ogni PR. Il baseline controlla solo gli header di sicurezza, la presenza di HTTPS e le vulnerabilità più ovvie.

Esempio: DAST con OWASP ZAP in GitHub Actions

name: DAST Baseline

on:
  pull_request:
    branches: [main]

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Deploy staging (se non già attivo)
        run: |
          docker compose -f docker-compose.staging.yml up -d
      - name: ZAP Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: 'http://localhost:8080'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-I -c config/zap.conf'
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report.html

Nota: il file .zap/rules.tsv permette di ignorare falsi positivi noti. Lo manteniamo in repo, aggiornato dal team ogni settimana. Senza questo filtro, ZAP blocca la build per warning banali e i dev disabilitano tutto.

SAST vs DAST: dove si trovano i falsi positivi e come gestirli?

I falsi positivi sono il nemico numero uno dell'adozione della sicurezza nel pipeline. Un team che riceve 50 alert falsi al giorno impara a ignorarli. Noi abbiamo visto progetti dove il SAST segnalava “SQL Injection” su query costruite con ORM — falsi positivi al 100%. La soluzione? Tuning delle regole.

Per Semgrep, creiamo regole personalizzate per stack specifici. Per ZAP, manteniamo una lista di esclusioni (regole disabilitate per pagine di admin, o per endpoint che richiedono autenticazione). E soprattutto: non blocchiamo mai la build su un warning. Solo su errori confermati. Il warning va in report, lo si analizza nel backlog tecnico.

Strategia pratica per gestire falsi positivi

1. Ogni tool SAST/DAST va calibrato per 2 settimane prima di attivare il blocco.
2. Usa un file di configurazione versionato (es. .semgrepignore, .zap/rules.tsv).
3. Assegna un responsabile per ogni alert: chi lo tria, con che priorità.
4. Automatizza il triage con label GitHub/GitLab: se lo stesso alert appare 3 volte e viene chiuso come falso positivo, silenzialo.

Come misurare l'efficacia di SAST e DAST nel pipeline?

Non serve un cruscotto complesso. Noi misuriamo tre metriche:

• Tasso di rilevamento pre-production: quante vulnerabilità vengono trovate prima del merge su main.
• Tempo medio di remediation: da quando l'alert viene aperto a quando viene risolto (o silenziato).
• Percentuale di falsi positivi: se supera il 30%, lo strumento è mal configurato.

Se il tasso di rilevamento pre-production è sotto il 70% o il tempo medio di remediation supera i 7 giorni, significa che la sicurezza non fa parte del flusso di lavoro. Serve una revisione delle policy e più formazione per il team.

Cosa fare adesso

1. Installa Semgrep (o il tool SAST per il tuo linguaggio principale) e integralo in GitHub Actions o GitLab CI. Parte con regole di default, non bloccare ancora la build.
2. Configura OWASP ZAP Baseline su un ambiente di staging. Lascialo in modalità “report-only” per una settimana, raccogli i falsi positivi e crea il file di regole di esclusione.
3. Imposta un processo di triage: ogni alert va assegnato a un developer, con scadenza massima di 3 giorni lavorativi per analisi.
4. Dopo due settimane di calibrazione, attiva il blocco solo per gli errori critici (es. RCE, SQL Injection confermata, secret leak).
5. Se non hai ancora una pipeline DevSecOps, leggi la nostra guida pillar sulla sicurezza Cloud e DevSecOps.

Noi di Meteora Web lo facciamo ogni giorno. Integrare SAST e DAST non è un progetto IT: è un cambiamento culturale. Ma se configurato bene, diventa invisibile — e il team non si accorge nemmeno di fare sicurezza.