Il Mito dello "Shift Left" — e Perché il Tuo Pipeline è Ancora Rotto

Lo "shift left" come venduto dai vendor di sicurezza significa: sposta la sicurezza prima nel ciclo di sviluppo. Come implementato dalla maggior parte delle organizzazioni significa: aggiungi uno scanner al pipeline di CI, ignora i risultati, dichiara vittoria.

Il problema non è lo strumento. Il problema è il modello mentale. Aggiungere Semgrep a un GitHub Actions workflow non ti rende una DevSecOps organization — te ne rende una solo se hai un processo per triaggiare i findings, una policy di severità che fa senso, e developer che capiscono perché la security automation esiste.

La buona notizia: l'automazione della sicurezza nel CI/CD cambia l'economia della sicurezza in modo radicale. Quello che richiede 3 giorni di penetration test manuale può girare in 90 secondi su ogni commit. Ogni PR può ricevere feedback di sicurezza contestuale prima di toccare main. Le vulnerability class sistemate una volta possono essere prevenute per sempre con una custom rule. Questo è il valore reale — non la compliance checkbox.

"Security automation in CI/CD is not about running tools. It's about creating a feedback loop fast enough that security becomes part of the development habit, not a phase that happens after."

Modello Mentale: Dove Va Ogni Scanner nel Pipeline

Prima di installare qualsiasi strumento, devi rispondere a una domanda: dove nel pipeline questa analisi produce il feedback più utile con il minor overhead? Ogni tipo di scan ha requisiti diversi in termini di ambiente, tempo di esecuzione e tipo di findings prodotti.

La regola generale: scans veloci (secret detection, SAST fast rules, linting) appartengono al pre-commit e al PR gate. Scans che richiedono un'applicazione in esecuzione (DAST) appartengono all'ambiente di staging. Scans pesanti (CodeQL, full dependency audit) possono girare su schedule notturni e non bloccare ogni PR.

Secret Detection: L'Unico Caso di Zero Tolerance

I segreti nei repository git sono l'unica categoria dove la tolleranza zero è giustificata. A differenza di una vulnerabilità nel codice che richiede exploit, una API key committata è già un incident. Il motivo è banale: git non dimentica. Puoi rimuovere il file nel commit successivo, ma la chiave è nella history — e se il repository è mai stato clonato, forked, o crawlato da GitHub, quella chiave è fuori. Per sempre.

SAST: Static Analysis Fatta Bene

Il SAST analizza il codice sorgente senza eseguirlo, cercando pattern di vulnerabilità noti. Il problema storico del SAST era il rapporto segnale/rumore: troppi falsi positivi, developer che imparano a ignorare i report, strumento che viene disabilitato silenziosamente entro un mese dall'installazione.

Gli strumenti moderni hanno risolto parzialmente questo problema. La chiave è la calibrazione progressiva: non partire con zero tolerance su tutti i severity level il primo giorno. Parti con solo CRITICAL/HIGH, stabilisci una baseline, risolvi quello che c'è, poi espandi gradualmente la copertura. Questo approccio a ratchet è l'unico che sopravvive all'impatto con una codebase reale.

DAST: Il Problema Difficile

Il DAST è la categoria che la maggior parte dei team implementa male — o non implementa affatto nel CI/CD — perché richiede un'applicazione in esecuzione. Non puoi fare DAST su codice sorgente. Hai bisogno di un endpoint HTTP raggiungibile, il che significa ambiente di deploy, il che significa Docker Compose o Kubernetes, il che significa pipeline più complessi.

Il pattern corretto per il DAST in CI: spin up dell'applicazione in Docker Compose (app + database + dipendenze), health check, scan DAST, tear down. L'intero ciclo dovrebbe stare in 5-10 minuti per essere sostenibile. Se ci vuole di più, il DAST appartiene a un job separato su schedule, non al PR gate.

SCA: Dove Vivono le Tue CVE Reali

Se dovessi indicare la singola categoria di scan con il più alto ROI per la maggior parte delle organizzazioni, sarebbe la Software Composition Analysis. Più dell'80% delle CVE che trovo durante security review provengono da dipendenze di terze parti, non dal codice custom. Log4Shell, Spring4Shell, les innumerevoli CVE critical di componenti npm: queste vulnerability existevano nella codebase da mesi o anni senza che nessuno lo sapesse. L'SCA risolve questo problema in modo strutturale.

Container e IaC Security

Due categorie spesso dimenticate che meritano integrazione nel pipeline:

Container image scanning con Trivy (trivy image <name>) va eseguito sul layer finale dell'immagine built nel pipeline CI — non sulla base image in isolamento. Le vulnerability possono essere introdotte nei layer superiori (pacchetti installati nel Dockerfile, dipendenze copiate dentro). Il pattern corretto: docker build → trivy image → push al registry solo se clean.

Hadolint per i Dockerfile è il linter che ogni team dovrebbe usare. Verifica best practice: no apt-get update senza apt-get install nella stessa RUN, no latest tags per le immagini base, no ADD quando COPY è sufficiente, no processi running come root. Integrazione in 3 righe di GitHub Actions.

Checkov o trivy config . per l'IaC (Terraform, Kubernetes manifests, Helm charts, CloudFormation): security groups too permissive, public S3 buckets, unencrypted EBS volumes, Kubernetes pods senza security context. Questi findings sono spesso i più critici — una misconfiguration IaC può esporre tutta l'infrastruttura, non solo un singolo endpoint.

Integrare Tutto: Pattern GitHub Actions

Ecco pattern pratici e production-ready per le categorie principali. Adattali al tuo workflow — l'importante è che ogni job produca output SARIF caricato nel GitHub Security tab, che diventa il tuo unified security dashboard.

Secrets Detection con Gitleaks

gitleaks:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0          # full history required
    - uses: gitleaks/gitleaks-action@v2
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

SAST con Semgrep

semgrep:
  runs-on: ubuntu-latest
  container:
    image: semgrep/semgrep
  steps:
    - uses: actions/checkout@v4
    - run: |
        semgrep scan \
          --config=auto \
          --sarif \
          --output=semgrep.sarif \
          --severity=ERROR \
          --error            # exit 1 on findings
    - uses: github/codeql-action/upload-sarif@v3
      if: always()
      with:
        sarif_file: semgrep.sarif

SCA + Container + SBOM con Trivy

trivy:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    # SCA on source code
    - name: Trivy — filesystem scan
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: fs
        scan-ref: .
        format: sarif
        output: trivy-fs.sarif
        severity: CRITICAL,HIGH
        ignore-unfixed: true
        exit-code: 1

    # Container image scan + SBOM
    - name: Build image
      run: docker build -t app:${{ github.sha }} .

    - name: Trivy — image scan
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: image
        image-ref: app:${{ github.sha }}
        format: sarif
        output: trivy-image.sarif
        severity: CRITICAL,HIGH
        ignore-unfixed: true
        exit-code: 1

    - name: Trivy — generate SBOM (CycloneDX)
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: image
        image-ref: app:${{ github.sha }}
        format: cyclonedx
        output: sbom.cdx.json

    - uses: github/codeql-action/upload-sarif@v3
      if: always()
      with:
        sarif_file: trivy-fs.sarif

    - uses: actions/upload-artifact@v4
      with:
        name: sbom
        path: sbom.cdx.json

DAST con OWASP ZAP (su ambiente effimero)

zap-baseline:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Start application stack
      run: docker compose -f docker-compose.test.yml up -d

    - name: Wait for health
      run: |
        timeout 60 sh -c \
          'until curl -sf http://localhost:8080/health; do sleep 2; done'

    - name: ZAP Baseline Scan
      uses: zaproxy/action-baseline@v0.12.0
      with:
        target: http://localhost:8080
        fail_action: false       # warn, don't block — adjust after baseline
        artifact_name: zap-report
        rules_file_name: .zap/rules.tsv   # suppress known-acceptable alerts

    - name: Tear down
      if: always()
      run: docker compose -f docker-compose.test.yml down -v

DAST con Nuclei (su staging dedicato)

nuclei:
  runs-on: ubuntu-latest
  if: github.ref == 'refs/heads/main'    # only on main branch
  steps:
    - uses: actions/checkout@v4
    - uses: projectdiscovery/nuclei-action@main
      with:
        target: ${{ vars.STAGING_URL }}
        flags: >-
          -t exposures
          -t misconfiguration
          -t default-logins
          -severity medium,high,critical
          -rate-limit 50
          -sarif-export nuclei.sarif
    - uses: github/codeql-action/upload-sarif@v3
      if: always()
      with:
        sarif_file: nuclei.sarif

Gestione delle Soglie e dei Falsi Positivi

Il formato SARIF (Static Analysis Results Interchange Format) è lo standard che unifica tutto: Semgrep, Trivy, ZAP, Nuclei, CodeQL producono tutti SARIF. Caricato in GitHub tramite codeql-action/upload-sarif, appare nel tab "Security → Code scanning alerts" del repository — un dashboard unificato senza bisogno di strumenti aggiuntivi.

Per gestire i falsi positivi senza degradare la qualità del programma:

• Semgrep: # nosemgrep: rule-id inline nel codice. Ogni soppressione deve avere un commento su una riga separata che spiega il perché. Se non riesci a giustificare la soppressione per iscritto, probabilmente non dovresti sopprimerla.
• Trivy: file .trivyignore nella root del repository, con CVE ID e commento. Esempio: CVE-2023-XXXXX # no fix available, not exploitable in our deployment model.
• ZAP: file .zap/rules.tsv per la baseline scan — mappa alert ID a IGNORE/WARN con una nota.
• Ratchet progressivo: inizia con solo CRITICAL, risolvi tutto, poi aggiungi HIGH, poi MEDIUM. Non provare a partire da zero con tutto abilitato su una codebase legacy — è un percorso sicuro verso la disabilitazione dello strumento.

Anti-Pattern che Uccidono i Programmi di Security Automation

Misurare Quello che Conta

La metrica sbagliata: "numero di scan eseguiti". Non misura nulla di utile. Ecco le metriche che indicano se il tuo programma sta funzionando:

SecDevOps e il Cyber Resilience Act

Il CRA non nomina "CI/CD security automation" nei suoi articoli, ma i suoi obblighi tecnici sono praticamente impossibili da soddisfare senza di essa:

• Art. 13(2) — Security by design: dimostrare che la sicurezza è integrata nel processo di sviluppo, non aggiunta post-hoc. Un pipeline CI/CD con security gates documentati e audit trail è la prova operativa di questo requisito.
• Annex I, Part I, §2 — Nessuna vulnerability nota e sfruttabile: SAST + SCA nel CI è il meccanismo operativo per soddisfare questo requisito in modo continuativo, non solo al momento del rilascio iniziale.
• Art. 13(8) — SBOM: la generazione automatica di SBOM (Trivy/Syft) integrata nel build pipeline è la delivery mechanism. Ogni release dovrebbe produrre un SBOM CycloneDX firmato come artefatto.
• Art. 14 — Notifica delle vulnerabilità (24h per actively exploited): il monitoraggio continuo tramite Trivy con DB refresh schedulate è ciò che ti permette di rilevare nuove CVE che impattano le dipendenze già in produzione — un prerequisito per rispettare le timeline di notifica.

Per i prodotti Class II e Critical, l'assessment da parte di un organismo notificato includerà quasi certamente la verifica di processi documentati di vulnerability testing automatizzato. Avere un pipeline CI/CD con security scans configurati, log degli esiti, e tracciabilità delle remediation non è solo best practice — è come si supera la due diligence di certificazione.

Costruire un Programma che Sopravvive nel Tempo

Ho visto programmi di security automation costruiti con attenzione e budget decadere nel giro di sei mesi quando il team che li ha implementati si è spostato ad altro. La sostenibilità non è una questione di tecnologia — è una questione di ownership e cultura.

Tre cose che ho imparato nel modo difficile: primo, ogni scanner deve avere un owner nominato responsabile della calibrazione e della triage — "il team di sicurezza" non è un owner. Secondo, le regole custom Semgrep e i file .trivyignore devono essere in version control con review process, non gestiti da una singola persona. Terzo, il feedback loop deve essere abbastanza veloce da sembrare utile: se un developer deve aspettare 20 minuti per sapere se la sua PR ha un security finding, smette di aspettare. La velocità degli strumenti non è un'opzione — è un requisito di adozione.

Il team di ProductSecurity.it ha progettato e implementato security automation nei pipeline CI/CD per organizzazioni che producono SaaS enterprise, prodotti IoT embedded e sistemi critici. Se vuoi costruire un programma reale — non un set di tool installati e ignorati, ma un meccanismo che effettivamente riduce la superficie di rischio — inizia valutando la tua postura attuale.