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. Per chi deve dimostrare conformità al CRA, un pipeline CI/CD documentato e auditabile è anche la prova operativa dell'Art. 13(2) — security by design — che non puoi ottenere in altro modo.

"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 era il rapporto segnale/rumore: troppi falsi positivi, developer che imparano a ignorare i report, strumento disabilitato silenziosamente entro un mese dall'installazione.

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. 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 nel CI/CD perché richiede un'applicazione in esecuzione. Il pattern corretto: spin up in Docker Compose (app + database + dipendenze), health check, scan DAST, tear down. L'intero ciclo dovrebbe stare in 5-10 minuti. Se ci vuole di più, il DAST appartiene a un job separato su schedule.

SCA: Dove Vivono le Tue CVE Reali

Se dovessi indicare la singola categoria di scan con il più alto ROI, sarebbe la Software Composition Analysis. Più dell'80% delle CVE che trovo durante security review provengono da dipendenze di terze parti. Log4Shell, Spring4Shell, innumerevoli CVE critical di componenti npm: vulnerability esistite nelle codebase per mesi senza che nessuno lo sapesse. L'SCA risolve questo strutturalmente — ed è anche il prerequisito tecnico per soddisfare Annex I, Part I, §2 del CRA in modo continuativo.

Container e IaC Security

Container image scanning con Trivy (trivy image <name>) va eseguito sul layer finale dell'immagine built nel pipeline CI. Le vulnerability possono essere introdotte nei layer superiori. Il pattern corretto: docker build → trivy image → push al registry solo se clean.

Hadolint per i Dockerfile verifica best practice: no apt-get update senza apt-get install nella stessa RUN, no tag latest per le immagini base, no processi running come root. Integrazione in 3 righe di GitHub Actions.

Checkov o trivy config . per l'IaC (Terraform, Kubernetes, Helm, CloudFormation): security groups troppo permissivi, S3 bucket pubblici, volumi non cifrati. Per la CRA, le misconfiguration IaC che espongono la superficie di attacco dell'infrastruttura sono direttamente rilevanti per i requisiti di protezione delle interfacce (Annex I, §3).

Integrare Tutto: Pattern GitHub Actions

Pattern pratici e production-ready. Ogni job produce output SARIF caricato nel GitHub Security tab — il tuo unified security dashboard senza strumenti aggiuntivi. Per la CRA, l'audit trail dei run di questi workflow è anche evidenza documentale dei processi di vulnerability testing.

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
    - 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

    - name: Trivy — filesystem scan (SCA)
      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

    - 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

    # CRA Art. 13(8) — SBOM generation
    - 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-${{ github.sha }}
        path: sbom.cdx.json

DAST con OWASP ZAP (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
        artifact_name: zap-report
        rules_file_name: .zap/rules.tsv

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

DAST con Nuclei (staging dedicato)

nuclei:
  runs-on: ubuntu-latest
  if: github.ref == 'refs/heads/main'
  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 è lo standard che unifica tutto. Caricato in GitHub tramite codeql-action/upload-sarif, appare nel tab "Security → Code scanning alerts" — un dashboard unificato senza strumenti aggiuntivi. Per la CRA, questo dashboard è anche l'audit trail delle vulnerabilità rilevate e della loro remediation.

• Semgrep: # nosemgrep: rule-id inline nel codice. Ogni soppressione deve avere un commento che spiega il perché — per la CRA, le soppressioni non giustificate sono un rischio di audit.
• Trivy: file .trivyignore nella root del repository con CVE ID e commento.
• ZAP: file .zap/rules.tsv per la baseline scan — mappa alert ID a IGNORE/WARN con nota.
• Ratchet progressivo: inizia con CRITICAL, risolvi tutto, poi aggiungi HIGH, poi MEDIUM. Non partire con tutto abilitato su una codebase legacy.

Anti-Pattern che Uccidono i Programmi di Security Automation

Misurare Quello che Conta

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: un pipeline CI/CD con security gates documentati e audit trail è la prova operativa che la sicurezza è integrata nel processo di sviluppo. Non esiste altra modalità di dimostrazione scalabile per prodotti software in sviluppo continuo.
• 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, ma a ogni aggiornamento.
• Art. 13(8) — SBOM: la generazione automatica di SBOM (Trivy/Syft) integrata nel build pipeline è la delivery mechanism. Ogni release deve produrre un SBOM CycloneDX firmato come artefatto — non un documento creato manualmente prima dell'audit.
• Art. 14 — Notifica delle vulnerabilità (24h per actively exploited): il monitoraggio continuo tramite Trivy con DB refresh schedulato è ciò che permette di rilevare nuove CVE che impattano dipendenze già in produzione — prerequisito per rispettare le timeline di notifica ENISA.

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. 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 decadere nel giro di sei mesi quando il team che li ha implementati si è spostato ad altro. La sostenibilità non è tecnologia — è ownership e cultura.

Tre cose imparate nel modo difficile: primo, ogni scanner deve avere un owner nominato — "il team di sicurezza" non è un owner. Secondo, le regole custom e i file di soppressione devono essere in version control con review process, non gestiti da una singola persona. Terzo, la velocità degli strumenti non è un'opzione: se un developer deve aspettare 20 minuti per il feedback, smette di aspettare. I tool lenti vengono bypassati.

Il team di CRA.tips ha progettato e implementato security automation nei pipeline CI/CD per organizzazioni che producono SaaS enterprise, prodotti IoT embedded e sistemi critici soggetti alla CRA. Se vuoi costruire un programma reale — non un set di tool installati e ignorati — inizia valutando il tuo gap di conformità.