# Sicurezza delle Pipeline DevOps nel 2026: SAST, DAST, Supply Chain e Domande per Colloqui > Guida completa alla protezione delle pipeline CI/CD nel 2026. Copre SAST, DAST, SCA, SBOM, SLSA provenance e domande pratiche per colloqui DevSecOps. - Published: 2026-09-15 - Updated: 2026-09-15 - Author: Anthony Fillion-Maillet - Tags: devops, security, cicd, devsecops, sast, dast - Reading time: 9 min --- La sicurezza delle pipeline DevOps richiede l'integrazione di controlli di sicurezza in ogni fase del workflow CI/CD, dagli hook pre-commit al monitoraggio in produzione. Il [Datadog State of DevSecOps Report 2026](https://www.datadoghq.com/state-of-devsecops/) rivela che l'87% delle organizzazioni esegue servizi con almeno una vulnerabilità sfruttabile nota, mentre gli attacchi alla supply chain software costano ora all'economia globale oltre 80 miliardi di dollari all'anno. > **L'ordine di priorità per gli strumenti di sicurezza** > > Si consiglia di iniziare con il rilevamento dei secrets (impatto più alto, tasso di falsi positivi più basso), poi aggiungere SCA per CVE note, SAST con tuning, scansione IaC e infine DAST. Ogni strumento deve dimostrare il suo valore prima di aggiungere il successivo. ## SAST: Analisi Statica che Rileva le Vulnerabilità Prima del Merge Static Application Security Testing (SAST) analizza il codice sorgente senza eseguirlo. Lo strumento effettua il parsing del codebase, costruisce un albero sintattico astratto e confronta pattern con firme di vulnerabilità note. L'esecuzione di SAST su ogni pull request rileva SQL injection, XSS e credenziali hardcoded prima che il codice raggiunga il branch principale. Semgrep è diventato lo strumento SAST open-source de facto nel 2026. A differenza degli scanner basati su regex, Semgrep comprende la struttura del codice e supporta regole personalizzate in YAML. ```yaml # .github/workflows/sast.yml name: SAST Scan on: pull_request: branches: [main, develop] jobs: semgrep: runs-on: ubuntu-latest container: image: semgrep/semgrep:latest steps: - uses: actions/checkout@v4 - name: Run Semgrep run: semgrep scan --config=auto --sarif --output=semgrep.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: semgrep.sarif ``` Il flag `--config=auto` carica le regole della community corrispondenti ai linguaggi rilevati. L'output SARIF si integra con la scheda GitHub Security per il tracciamento dei finding nel tempo. ## DAST: Test a Runtime che Trovano Ciò che l'Analisi Statica Non Vede Dynamic Application Security Testing (DAST) attacca un'applicazione in esecuzione per trovare vulnerabilità che si manifestano solo a runtime. Autenticazione non funzionante, falle di autorizzazione e bug nella logica di business richiedono richieste HTTP reali per essere rilevati. SAST non può trovare che un endpoint admin manca di un adeguato controllo degli accessi, ma DAST tenterà di accedervi senza credenziali e segnalerà l'esposizione. [OWASP ZAP](https://www.zaproxy.org/) rimane lo strumento DAST open-source più diffuso. ZAP 3.0, rilasciato all'inizio del 2026, ha aggiunto supporto nativo per la scansione GraphQL e gRPC. ```yaml # .github/workflows/dast.yml name: DAST Scan on: deployment: types: [created] jobs: zap-scan: runs-on: ubuntu-latest steps: - name: ZAP Full Scan uses: zaproxy/action-full-scan@v0.12.0 with: target: ${{ secrets.STAGING_URL }} rules_file_name: '.zap/rules.tsv' cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"' - name: Upload Report uses: actions/upload-artifact@v4 with: name: zap-report path: report_html.html ``` DAST viene eseguito post-deployment perché necessita di un target live. L'ambiente di staging serve come superficie di test, mantenendo la produzione isolata dal traffico di scansione. > **DAST in Produzione** > > L'esecuzione di scansioni DAST attive contro la produzione rischia di attivare rate limit, corrompere dati o allertare il monitoraggio di sicurezza. Si raccomanda di utilizzare un ambiente di staging che rispecchi la configurazione di produzione. ## SCA: Scansione delle Dipendenze per Vulnerabilità Note Software Composition Analysis (SCA) scansiona le dipendenze contro database di vulnerabilità come il [National Vulnerability Database](https://nvd.nist.gov/) e GitHub Advisory Database. Una singola dipendenza transitiva vulnerabile può esporre l'intera applicazione. Il report Datadog 2026 ha rilevato che il 42% dei servizi dipende da librerie non più mantenute attivamente. Trivy scansiona container, filesystem e repository git per vulnerabilità in un singolo binary. Genera output SBOM nei formati CycloneDX e SPDX. ```yaml # .github/workflows/sca.yml name: Dependency Scan on: push: branches: [main] schedule: - cron: '0 6 * * *' # Ogni giorno alle 6:00 jobs: trivy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@0.28.0 with: scan-type: 'fs' scan-ref: '.' format: 'sarif' output: 'trivy-results.sarif' severity: 'CRITICAL,HIGH' - name: Upload Trivy scan results uses: github/codeql-action/upload-sarif@v3 with: sarif_file: 'trivy-results.sarif' ``` La scansione giornaliera programmata rileva CVE appena divulgate anche senza modifiche al codice. Il filtraggio per severità CRITICAL e HIGH previene l'affaticamento da alert causato da finding a basso rischio. ## Sicurezza della Supply Chain: SBOM e SLSA Provenance Il [Cyber Resilience Act dell'UE](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), con obblighi di reporting che entrano in vigore a settembre 2026, impone la generazione di Software Bill of Materials (SBOM) per i prodotti venduti nell'UE. Una SBOM elenca ogni componente nel software, incluse dipendenze dirette, dipendenze transitive e relative versioni. [SLSA](https://slsa.dev/) (Supply-chain Levels for Software Artifacts) integra SBOM verificando come il software è stato costruito. SBOM risponde alla domanda "quali componenti sono in questo software?" mentre SLSA risponde alla domanda "ci si può fidare del processo di build?" ```yaml # .github/workflows/supply-chain.yml name: Supply Chain Security on: push: tags: - 'v*' jobs: build-with-provenance: runs-on: ubuntu-latest permissions: contents: read id-token: write attestations: write steps: - uses: actions/checkout@v4 - name: Build container image run: docker build -t myapp:${{ github.ref_name }} . - name: Generate SBOM uses: anchore/sbom-action@v0.17.0 with: image: myapp:${{ github.ref_name }} format: cyclonedx-json output-file: sbom.json - name: Sign with Cosign uses: sigstore/cosign-installer@v3.7.0 - name: Sign image and attach SBOM run: | cosign sign --yes myapp:${{ github.ref_name }} cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }} cosign sign --yes --attachment sbom myapp:${{ github.ref_name }} ``` Cosign di Sigstore firma gli artefatti usando la firma keyless supportata dall'autorità di certificazione Fulcio. La firma lega l'artefatto al workflow CI che lo ha prodotto, permettendo la verifica che l'immagine provenga da una pipeline affidabile. ## Rilevamento Secrets: La Prima Linea di Difesa I secrets hardcoded rimangono il finding di sicurezza più comune nei codebase. Chiavi di accesso AWS, password di database e token API committati nel version control hanno causato violazioni di ogni dimensione. Il rilevamento dei secrets viene eseguito pre-commit per bloccare le credenziali prima che entrino nel repository. [Gitleaks](https://github.com/gitleaks/gitleaks) rileva secrets usando pattern regex e analisi dell'entropia. Un hook pre-commit impedisce che i secrets vengano mai committati. ```yaml # .pre-commit-config.yaml repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.21.2 hooks: - id: gitleaks args: ['--verbose'] ``` ```yaml # .github/workflows/secrets.yml name: Secrets Detection on: pull_request: jobs: gitleaks: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Gitleaks scan uses: gitleaks/gitleaks-action@v2 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` L'opzione `fetch-depth: 0` clona la cronologia completa, permettendo a Gitleaks di scansionare tutti i commit nel PR, non solo l'ultimo. ## Domande per Colloqui DevSecOps: Cosa Chiedono i Recruiter I colloqui DevSecOps valutano sia la conoscenza della sicurezza che l'esperienza pratica CI/CD. Le domande seguenti compaiono frequentemente nei colloqui 2026 per ruoli senior DevOps e platform engineering. Ulteriori domande sulla sicurezza delle pipeline si trovano nel [modulo di colloquio CI/CD Pipeline Security](/technologies/devops/interview-questions/cicd-pipeline-security). ### "Come implementeresti la sicurezza shift-left in una pipeline esistente?" La sicurezza shift-left sposta i test più avanti nel ciclo di sviluppo. L'implementazione pratica prevede l'aggiunta di hook pre-commit per il rilevamento dei secrets, scansioni SAST sulle pull request e controlli SCA nella fase di build. La chiave è l'adozione incrementale: iniziare con il rilevamento dei secrets perché ha il tasso di falsi positivi più basso e il segnale più alto, poi aggiungere SCA per CVE note, poi affinare le regole SAST per ridurre il rumore prima di abilitarle come controllo bloccante. ### "Spiega la differenza tra SAST e DAST. Quando useresti ciascuno?" SAST analizza il codice sorgente senza esecuzione. Trova SQL injection, XSS e crittografia insicura attraverso il pattern matching contro la struttura del codice. SAST viene eseguito presto, su ogni PR, perché ha bisogno solo del codice. DAST attacca un'applicazione in esecuzione. Trova bypass dell'autenticazione, controllo degli accessi non funzionante e vulnerabilità di injection che si manifestano solo a runtime. DAST viene eseguito post-deployment contro un ambiente di staging. I due si completano a vicenda. SAST rileva errori di codifica prima del merge; DAST verifica che l'applicazione deployata si comporti in modo sicuro. Una pipeline matura esegue entrambi. ### "Cos'è una SBOM e perché è richiesta?" Una Software Bill of Materials elenca ogni componente nel software, incluse dipendenze dirette e transitive con versioni esatte. Requisiti normativi come il Cyber Resilience Act dell'UE impongono la generazione di SBOM per i prodotti che entrano nel mercato UE a partire da settembre 2026. In pratica, SBOM permette una risposta rapida agli incidenti. Quando viene rilasciata una nuova CVE, il team di sicurezza può interrogare il database SBOM per identificare ogni servizio che esegue il componente vulnerabile invece di scansionare manualmente tutti i repository. ### "Come previeni l'affaticamento da alert negli strumenti di sicurezza?" L'affaticamento da alert si verifica quando gli sviluppatori ignorano i finding di sicurezza perché il rapporto segnale-rumore è troppo basso. La prevenzione richiede il tuning di ogni strumento prima di abilitare i gate bloccanti. Per SAST, si disabilitano le regole che producono falsi positivi nel codebase e si abilitano gradualmente dopo la pulizia. Per SCA, ci si concentra sui finding di severità CRITICAL e HIGH con exploit noti. Per DAST, si configurano scansioni baseline per escludere i falsi positivi dalle esecuzioni future. La metrica da tracciare è il tempo per correggere le vulnerabilità reali. Se questo numero aumenta, gli sviluppatori stanno ignorando gli alert. > **Preparazione al Colloquio** > > Queste domande testano l'esperienza pratica. Si consiglia di preparare esempi da pipeline reali, inclusi strumenti specifici, decisioni di configurazione e metriche prima e dopo l'implementazione. ## Sicurezza dei Container e Runtime La scansione delle immagini container rileva vulnerabilità prima del deployment. La sicurezza runtime monitora i container in produzione per comportamenti anomali. La combinazione affronta sia vulnerabilità note (CVE nelle immagini base) che minacce sconosciute (container compromessi, cryptominer). Trivy scansiona le immagini come parte della pipeline di build. [Falco](https://falco.org/) monitora il comportamento runtime usando eBPF. ```yaml # .github/workflows/container-security.yml name: Container Security on: push: branches: [main] jobs: scan-image: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build image run: docker build -t myapp:${{ github.sha }} . - name: Scan image uses: aquasecurity/trivy-action@0.28.0 with: image-ref: myapp:${{ github.sha }} format: 'table' exit-code: '1' severity: 'CRITICAL' ignore-unfixed: true ``` Il flag `ignore-unfixed: true` salta le vulnerabilità senza patch disponibili. Questo previene il blocco dei deployment per CVE che attualmente non possono essere rimediate. Per la sicurezza runtime, le regole Falco rilevano attività sospette nei container in esecuzione. Il [modulo Container Supply Chain Security](/technologies/devops/interview-questions/container-supply-chain) copre in dettaglio la firma delle immagini e l'admission control. ## Sicurezza IaC: Scansione di Terraform e Manifest Kubernetes Infrastructure as Code introduce rischi di sicurezza a livello di configurazione. Policy IAM troppo permissive, bucket S3 accessibili pubblicamente e database non crittografati risultano da default insicuri nei template IaC. [Checkov](https://www.checkov.io/) scansiona Terraform, CloudFormation, Kubernetes, Helm e Dockerfile per misconfigurazioni. ```yaml # .github/workflows/iac-scan.yml name: IaC Security Scan on: pull_request: paths: - 'terraform/**' - 'k8s/**' - 'helm/**' jobs: checkov: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Checkov uses: bridgecrewio/checkov-action@v12 with: directory: . framework: terraform,kubernetes,helm output_format: sarif output_file_path: checkov.sarif soft_fail: false - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: checkov.sarif ``` Il filtro per path assicura che le scansioni IaC vengano eseguite solo quando cambiano i file infrastrutturali, riducendo il tempo CI per modifiche solo applicative. ## La Pipeline DevSecOps Completa per il 2026 Una pipeline DevSecOps pronta per la produzione nel 2026 integra questi strumenti in ogni fase: - **Pre-commit**: Gitleaks (secrets), SAST locale opzionale - **Pull request**: Semgrep (SAST), Trivy (SCA), Checkov (IaC) - **Build**: Scansione immagini container, generazione SBOM - **Pre-deploy**: Firma immagini con Cosign, admission control con Kyverno - **Post-deploy**: DAST con ZAP contro staging - **Runtime**: Falco per il monitoraggio container, cloud security posture management Lo stack gratuito (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) copre ogni categoria. Gli strumenti commerciali aggiungono dashboard centralizzate, gestione delle policy e sforzo di tuning ridotto, ma la copertura di sicurezza è raggiungibile senza costi di licenza. Le organizzazioni che si preparano per ruoli DevSecOps dovrebbero esercitarsi a costruire queste pipeline in progetti personali. Il [modulo Cloud Identity and Secrets Management](/technologies/devops/interview-questions/cloud-identity-secrets) copre il lato gestione secrets dell'equazione. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/devops/devops-pipeline-security-sast-dast-2026