Supply Chain on My personal blog

DevSecOps in pratica: la serie

Tue, 10 Mar 2026 09:00:00 +0200

Perché questa serie

Per anni la sicurezza è arrivata alla fine: un audit a ridosso del rilascio, una lista di vulnerabilità da sistemare dopo che il codice era già scritto, un cancello che rallentava la consegna senza renderla più sicura. DevSecOps ribalta questo ordine: la sicurezza entra in ogni fase del ciclo di vita, automatizzata, misurata e trattata come responsabilità di tutti — non come il compito di un team separato alla fine della catena.

Questa serie è un percorso pratico in 30 capitoli. Non un elenco di strumenti, ma un modo di pensare: ogni controllo il più presto possibile (shift left), ogni artefatto verificabile, ogni decisione di rischio esplicita. Gli strumenti cambiano ogni due anni; i principi no.

Come è organizzata

  flowchart LR
    C[Cultura<br/>shift-left] --> D[Design<br/>threat model]
    D --> B[Build<br/>SAST/SCA/segreti]
    B --> A[Artefatti<br/>SBOM/firma/SLSA]
    A --> P[Deploy<br/>pipeline/IaC/policy]
    P --> R[Runtime<br/>K8s/admission/Falco]
    R --> O[Operate<br/>vuln mgmt/IR/metriche]
    O --> C
    style C fill:#fde2e4,stroke:#e63946
    style R fill:#e8f0fe,stroke:#4361ee

Il filo conduttore segue il viaggio del codice: nasce da una cultura e da un design sicuri, viene costruito con controlli automatici, impacchettato in artefatti verificabili, portato in produzione da una pipeline governata, difeso a runtime e operato con misure e risposta agli incidenti. Poi si ricomincia: DevSecOps è un ciclo, non una linea.

I capitoli

Fondamenta — Cos’è DevSecOps, il Secure SDLC, il threat modeling nel ciclo, la gestione dei segreti.
Build — SAST, SCA e dipendenze, DAST, IAST/RASP, fuzzing: trovare i difetti mentre si scrive.
Supply chain — SBOM, SLSA, firma degli artefatti: fidarsi solo di ciò che si può verificare.
Pipeline e deploy — Sicurezza della CI/CD, IaC security, policy as code nella pipeline.
Runtime — Sicurezza delle immagini, hardening di Kubernetes, admission control, runtime security, segreti e identità dei workload.
Operate — Patch management, security gates, vulnerability management, logging e detection, incident response, compliance as code, metriche e cultura.

A chi si rivolge

A chi scrive codice e vuole capire dove la sicurezza tocca il suo lavoro; a chi gestisce pipeline e cluster e deve renderli difendibili; a chi guida team e vuole misurare il rischio invece di subirlo. Diamo per note le basi di Git, container e CI/CD; tutto il resto lo costruiamo insieme.

DevSecOps non rallenta la consegna: la rende ripetibile. Un rilascio sicuro e automatizzato è più veloce di un audit manuale fatto nel panico la sera prima. Partiamo dal perché, nel primo capitolo.

Firmare gli artefatti con Sigstore

Tue, 02 Jun 2026 09:00:00 +0200

Perché conta

SLSA richiede provenienza firmata, e la SBOM vale di più se firmata e legata all’artefatto. Ma la firma crittografica aveva un problema pratico che l’ha resa rara: per firmare serve una chiave privata, e custodire chiavi a lungo termine (rotazione, revoca, HSM, il rischio che trapelino) è un onere che quasi nessun team si assumeva. Sigstore elimina proprio quell’onere.

L’idea: firma keyless

Sigstore permette di firmare senza gestire una chiave privata a lungo termine. Il meccanismo:

  flowchart TD
    CI[Pipeline CI<br/>identità OIDC] -->|provami chi sei| F[Fulcio<br/>CA]
    F -->|certificato a vita<br/>brevissima ~minuti| CI
    CI -->|firma l'artefatto<br/>con quel cert| SIG[Firma]
    SIG -->|registra firma+cert| R[Rekor<br/>log pubblico<br/>a prova di manomissione]
    R --> V[Chiunque può<br/>verificare dopo]
    style R fill:#fde2e4,stroke:#e63946

La pipeline prova la propria identità via OIDC (es. “sono la GitHub Action del repo X”).
Fulcio, una CA, emette un certificato a vita brevissima (minuti) legato a quell’identità.
Si firma l’artefatto con quel certificato effimero; la chiave privata sparisce subito dopo.
La firma e il certificato vengono registrati in Rekor, un log pubblico, append-only, a prova di manomissione (lo stesso principio del transparency log).

Nessuna chiave da custodire: l’identità sostituisce la chiave a lungo termine, e il certificato vive troppo poco per valere la pena di rubarlo.

Firmare e verificare con cosign

In pratica, dalla pipeline:

# firma keyless: l'identità OIDC della CI diventa il firmatario
cosign sign --yes registry.io/app@sha256:abc...

# verifica: accetta solo artefatti firmati dall'identità attesa
cosign verify registry.io/app@sha256:abc... \
  --certificate-identity "https://github.com/org/repo/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

La verifica è il punto che conta: non “è firmato?” ma “è firmato dall’identità che mi aspetto?”. Un artefatto firmato da un’identità sconosciuta va rifiutato esattamente come uno non firmato. cosign firma e verifica allo stesso modo anche le SBOM e le attestazioni di provenienza SLSA, allegandole all’immagine nel registry.

Dove si applica nel ciclo

Al rilascio: la pipeline firma l’immagine, la SBOM e la provenienza subito dopo la build.
All’ingresso: l’admission control del cluster verifica la firma e rifiuta ciò che non proviene dall’identità attesa. È qui che la firma smette di essere decorativa e diventa un controllo di accesso.

Il limite: la firma attesta l’origine, non la bontà

Una firma valida dice “questo artefatto viene davvero da chi dice” — non “questo artefatto è privo di vulnerabilità”. Si può firmare perfettamente un’immagine piena di CVE. La firma risolve autenticità e integrità, non qualità: va combinata con SCA, SBOM e policy, non le sostituisce.

Domanda: se la firma usa l'identità OIDC della pipeline invece di una chiave che custodisco io, non sto solo spostando la fiducia su GitHub/Fulcio/Rekor? Cosa impedisce a chi li compromette di firmare qualunque cosa?

Stai spostando la fiducia, sì, ma verso componenti progettati per essere difendibili e — soprattutto — osservabili, il che cambia la natura del rischio. Primo: la fiducia nell'identità OIDC non è peggiore di prima, è migliore. Con una chiave privata a lungo termine il rischio era una stringa che poteva trapelare da un file di config, un backup, un laptop, e restare valida per mesi senza che nessuno se ne accorgesse; con la firma keyless non esiste nessun segreto persistente da rubare, e il certificato vive minuti. Un attaccante dovrebbe compromettere l'identità della pipeline nel momento della build — il che è un problema di sicurezza della CI/CD che hai comunque, firma o no. Secondo, ed è il punto di Rekor: ogni firma finisce in un log pubblico, append-only, a prova di manomissione. Se qualcuno riuscisse a firmare un artefatto malevolo con la tua identità, quella firma sarebbe pubblicamente registrata, con l'identità e l'istante, visibile a te e a chiunque monitori il log — un attacco non ripudiabile e rilevabile, non un furto silenzioso di chiave che scopri sei mesi dopo. Terzo, la verifica è vincolata: non accetti "una firma qualsiasi", accetti solo l'identità esatta (quel repo, quel workflow, quel branch), quindi compromettere "GitHub in generale" non basta, serve proprio la tua identità precisa. Resta vero che Fulcio e Rekor sono radici di fiducia: se vengono compromessi a livello di infrastruttura, il modello vacilla — ma sono gestiti come infrastruttura critica, replicati e monitorati, e puoi anche operarne istanze tue. Il confronto corretto non è "fiducia zero contro fiducia in Sigstore", è "una chiave privata fragile e silenziosa che custodisci male contro un'identità effimera registrata pubblicamente": la seconda sposta la fiducia su qualcosa di più piccolo, più breve nel tempo e, decisivo, verificabile a posteriori da tutti.

Conclusione

Sigstore rende la firma pratica eliminando le chiavi da custodire: identità effimera via Fulcio, log pubblico via Rekor, firma e verifica di immagini, SBOM e provenienza con cosign. La firma attesta l’origine, non la qualità, e diventa un controllo solo quando qualcuno la verifica all’ingresso. Con artefatti verificabili in mano, il tema si sposta su dove tutto questo si orchestra e dove un attaccante punterebbe per primo: la pipeline CI/CD stessa, prossimo capitolo.

Supply chain e SLSA: fidarsi della build

Tue, 26 May 2026 09:00:00 +0200

Perché conta

La SBOM dice cosa c’è in un artefatto. Ma un attaccante sofisticato non ha bisogno di inserire una dipendenza vulnerabile: gli basta compromettere la pipeline che costruisce l’artefatto, iniettando codice dopo il sorgente pulito e prima dell’immagine finale. SolarWinds ha funzionato così: codice benigno nel repository, backdoor inserita durante la build. SLSA (Supply-chain Levels for Software Artifacts) esiste per rendere la build stessa verificabile.

La superficie d’attacco della supply chain

Ogni anello tra il codice di uno sviluppatore e l’artefatto in produzione è un bersaglio:

  flowchart LR
    DEV[Sviluppatore] -->|1. commit<br/>compromesso| SRC[(Sorgente)]
    SRC -->|2. dipendenza<br/>malevola| BUILD[Sistema di build]
    BUILD -->|3. build<br/>compromessa| ART[Artefatto]
    ART -->|4. artefatto<br/>sostituito| REG[(Registry)]
    REG -->|5. deploy di<br/>un'immagine falsa| PROD[Produzione]
    style BUILD fill:#fde2e4,stroke:#e63946

I controlli visti finora proteggono soprattutto l’anello 1-2 (il codice e le dipendenze). SLSA si concentra sull’anello 3-4: garantire che l’artefatto in produzione sia esattamente quello prodotto dalla build attesa, a partire dal sorgente atteso, senza manomissioni intermedie.

La provenienza: il documento chiave

Il concetto centrale di SLSA è la provenance: un documento, generato dal sistema di build stesso e firmato, che attesta “io, questa build, ho prodotto questo artefatto (hash X), da questo sorgente (commit Y), con questi parametri”. Verificare la provenienza prima del deploy significa rifiutare qualsiasi artefatto che non possa dimostrare la propria origine.

Provenance (semplificata):
  artefatto:  sha256:abc...        ← cosa
  sorgente:   git@...#commit def   ← da dove
  builder:    github-actions@...   ← chi l'ha costruito
  firmata dal builder → non falsificabile da chi non controlla il builder

I livelli di SLSA

SLSA non è tutto-o-niente: è una scala che alza progressivamente le garanzie.

Livello 1 — provenienza presente: la build genera la provenienza. Non ancora a prova di manomissione, ma esiste e dà trasparenza.
Livello 2 — provenienza firmata: generata da un servizio di build ospitato e firmata, quindi verificabile e non banalmente falsificabile.
Livello 3 — build indurita: il sistema di build è isolato, le sorgenti e i parametri sono verificati, la provenienza è non falsificabile anche da chi ha accesso al progetto. È il livello che avrebbe reso molto più difficile un attacco in stile SolarWinds.

(Le revisioni del framework rinumerano e articolano i livelli, ma la direzione è costante: da “la provenienza esiste” a “la provenienza è inattaccabile”.)

Cosa significa in pratica

Salire di livello è soprattutto disciplina di pipeline: build effimere e isolate (niente runner persistenti che accumulano stato), nessuna modifica manuale all’artefatto, provenienza generata automaticamente, deploy che verifica la provenienza come gate. Molto di questo si appoggia alla firma crittografica, il tassello del prossimo capitolo.

Domanda: ho già SAST, SCA, code review e secret scanning sul mio codice; se il mio sorgente è pulito e controllato, perché dovrei preoccuparmi di SLSA e della build?

Perché tutti i controlli che hai elencato verificano il sorgente, e la lezione di SolarWinds è esattamente che il sorgente può essere immacolato mentre l'artefatto spedito è compromesso. Tra il commit che hai revisionato e l'immagine che gira in produzione c'è un intero sistema — il runner della CI, gli script di build, la cache delle dipendenze, i plugin, le credenziali che pubblicano sul registry — e nulla di ciò che fai sul sorgente lo protegge. Un attaccante che ottiene l'accesso al sistema di build non ha bisogno di toccare il tuo repository: inietta la backdoor durante la compilazione, l'artefatto finale contiene codice che non comparirà mai in nessuna code review perché non è mai stato nel sorgente, e la tua SBOM lo elencherà come se fosse legittimo. Lo stesso vale per l'anello successivo: qualcuno che compromette il registry può sostituire la tua immagine con un'altra, e senza verifica della provenienza il cluster la deploierà fiducioso. SLSA chiude proprio questo divario, ortogonale ai controlli sul codice: la provenienza firmata lega l'artefatto al commit esatto e alla build esatta, così al momento del deploy puoi rifiutare qualunque cosa non dimostri di essere nata dal tuo sorgente pulito attraverso la tua build attesa. Non sostituisce SAST o SCA — quelli garantiscono che il sorgente sia buono — ma garantisce che ciò che spedisci sia davvero quel sorgente e non qualcosa che gli somiglia. Senza, hai verificato accuratamente l'ingresso di un tubo di cui non controlli l'uscita.

Conclusione

SLSA sposta la fiducia dal solo sorgente all’intera build: la provenienza firmata attesta cosa è stato costruito, da dove e da chi, e i livelli alzano progressivamente le garanzie fino a renderla inattaccabile. Ma “firmata” presuppone un sistema di firma che non richieda a ognuno di gestire chiavi private — storicamente il motivo per cui quasi nessuno firmava. Sigstore risolve questo, prossimo capitolo.

SBOM: la distinta base del software

Tue, 19 May 2026 09:00:00 +0200

Perché conta

Quando è uscito Log4Shell, la domanda che ha paralizzato migliaia di aziende non era “come si corregge?” ma “dove ce l’ho?”. Senza un inventario, rispondere ha richiesto settimane di caccia manuale. La SCA trova i CVE nelle dipendenze, ma presuppone di sapere cosa gira in produzione. La SBOM (Software Bill of Materials) è quell’inventario: la distinta base di ogni componente di ciò che spedisci.

Cos’è, concretamente

Una SBOM è un documento strutturato e leggibile da una macchina che elenca, per ogni artefatto:

Per ogni componente:
  - nome e VERSIONE esatta        ← la chiave per matchare i CVE
  - identificatore univoco (PURL) ← pkg:npm/lodash@4.17.21
  - hash / checksum               ← integrità
  - licenza                       ← anche compliance legale
  - relazioni (chi dipende da chi)

Due standard dominano: SPDX (ISO, nato attorno alla compliance delle licenze) e CycloneDX (OWASP, nato con la sicurezza in mente). Entrambi vanno bene; l’importante è generarla in un formato standard, non in un foglio di calcolo fatto a mano.

Dove e come generarla

La SBOM si genera nella pipeline, al momento della build, quando si conosce esattamente cosa finisce nell’artefatto. Generarla dopo, a posteriori, significa indovinare.

  flowchart LR
    SRC[Sorgente + lockfile] --> BUILD[Build nella CI]
    BUILD --> ART[Artefatto<br/>container / binario]
    BUILD --> GEN[Generatore SBOM<br/>es. Syft]
    GEN --> SBOM[SBOM<br/>CycloneDX/SPDX]
    SBOM -->|firmata e allegata<br/>all'artefatto| REG[(Registry)]
    ART --> REG
    style SBOM fill:#fde2e4,stroke:#e63946

Punto chiave: la SBOM va allegata all’artefatto e firmata, così viaggia con esso ed è verificabile (lo vedremo con Sigstore). Una SBOM che vive in una cartella scollegata dall’artefatto che descrive perde metà del valore.

Usarla davvero

Una SBOM archiviata e mai consultata è teatro della conformità. Il valore sta nell’uso:

Risposta ai CVE: esce una vulnerabilità su libxyz 1.4? Una query sulle SBOM archiviate dice in minuti quali servizi la contengono. La caccia di Log4Shell diventa un filtro.
Policy di ingresso: l’admission control può rifiutare un’immagine senza SBOM o con componenti vietati (licenze incompatibili, pacchetti in blocklist).
Monitoraggio continuo: le SBOM si ri-scansionano contro i database aggiornati, così si scoprono CVE nuovi su software già in produzione da mesi.

Il limite onesto: profondità

Una SBOM è buona quanto il generatore che la produce. Alcuni componenti sfuggono: binari statici, dipendenze incluse a mano, codice generato. La SBOM non è una verità magica, è una misura della tua visibilità — e il primo passo per migliorarla è vedere dove è incompleta.

Domanda: se la SCA già scansiona le dipendenze e trova i CVE, perché serve anche produrre e archiviare una SBOM? Non è informazione duplicata?

Si sovrappongono sull'input — entrambe partono dall'elenco dei componenti — ma rispondono a due domande diverse in due momenti diversi, e averne una sola lascia scoperto l'altro. La SCA è un'analisi che fai ora, nella pipeline, e ti dice "questo artefatto, oggi, contiene questi CVE noti": è puntuale e legata al momento della build. La SBOM è un inventario persistente e interrogabile che sopravvive alla build e viaggia con l'artefatto in produzione. La differenza si vede nel caso che conta di più: un CVE che non esisteva quando hai fatto la build. La SCA di allora non poteva trovarlo, perché il database non lo conosceva ancora. Sei mesi dopo esce il nuovo Log4Shell: con la sola SCA dovresti ricostruire o re-scansionare ogni artefatto per sapere chi è colpito, ammesso di sapere ancora esattamente cosa gira dove. Con le SBOM archiviate e indicizzate, invece, fai una query — "chi contiene libxyz sotto la 1.5?" — e hai la lista in minuti, senza toccare le build. In più la SBOM serve a cose che la SCA non copre: la verifica all'ingresso (l'admission control rifiuta ciò che non ha una SBOM o ha componenti vietati), la conformità delle licenze, e la provenienza. Il modo giusto di vederle: la SCA è l'azione di cercare vulnerabilità, la SBOM è il dato che rende quella ricerca possibile per sempre, anche sui CVE che non erano ancora stati scoperti. Si alimentano a vicenda.

Conclusione

La SBOM è la distinta base del software: sai cosa spedisci, quindi sai in minuti se un nuovo CVE ti riguarda. Si genera nella build, si firma, viaggia con l’artefatto e si interroga nel tempo. Ma sapere cosa c’è dentro un artefatto non basta se non possiamo fidarci di come è stato costruito. Un attaccante che compromette la pipeline può iniettare codice senza toccare il sorgente. Difendere la catena di costruzione è il prossimo tema: SLSA, prossimo capitolo.

SCA: il codice che non hai scritto

Tue, 21 Apr 2026 09:00:00 +0200

Perché conta

Il SAST analizza il codice che scriviamo. Ma in un’applicazione moderna quel codice è una frazione del totale: il resto sono dipendenze — librerie open source, transitivamente centinaia di pacchetti che non abbiamo mai letto. La SCA (Software Composition Analysis) si occupa di questo codice: trova le vulnerabilità note (CVE) nelle librerie che importiamo. Log4Shell ci ha insegnato quanto possa pesare una sola riga in un pom.xml.

L’albero delle dipendenze transitive

Il punto chiave: non si importano le librerie dichiarate, si importa il loro intero albero.

  flowchart TD
    APP[La tua app] --> A[libreria-web]
    APP --> B[client-http]
    A --> C[parser-json v1.2]
    B --> C
    B --> D[logging-lib v2.0<br/>CVE-2024-XXXX]
    style D fill:#fde2e4,stroke:#e63946

Hai dichiarato client-http, ma ti ritrovi logging-lib v2.0 vulnerabile senza averla mai scritta nel tuo manifest. La SCA risolve l’intero albero e confronta ogni nodo con i database di vulnerabilità. La maggior parte dei CVE che ti colpiscono vive nelle dipendenze transitive, quelle che non hai scelto consapevolmente.

Non tutti i CVE ti riguardano

Il tranello della SCA è il diluvio di avvisi. Un CVE in una libreria non significa che la tua app sia vulnerabile. Due domande filtrano il rumore:

Per ogni CVE segnalato:
  1. Uso davvero la funzione vulnerabile?   (reachability)
  2. Il percorso è esposto a input ostile?  (exploitability nel mio contesto)
Se entrambe NO → rischio basso, patch pianificata, non emergenza.

Gli strumenti più avanzati fanno reachability analysis: controllano se il tuo codice chiama davvero la funzione vulnerabile. Un CVE in un metodo che non invochi mai è rumore a bassa priorità; uno nel percorso di autenticazione esposto a internet è un’emergenza. Prioritizzare per contesto, non per numero di avvisi, è ciò che tiene il team sano — lo vedremo meglio nel capitolo sul vulnerability management.

Aggiornare senza rompere

La SCA non serve a nulla se poi non si aggiorna. Le pratiche che funzionano:

Bot di aggiornamento (Dependabot, Renovate) che aprono pull request automatiche per le nuove versioni, testate dalla CI.
Lockfile committati: la build è riproducibile, si sa esattamente quale versione gira.
Aggiornamenti piccoli e frequenti invece del salto di tre major ogni due anni, che nessuno osa fare perché romperebbe tutto.

Nel flusso di lavoro

La SCA sta nella CI (su ogni pull request, analizzando il manifest e il lockfile) e come scansione periodica del codice già in produzione: un CVE nuovo può emergere su una dipendenza che non tocchi da mesi. Questo richiede di sapere cosa gira davvero in produzione — l’inventario degli artefatti, che è il tema della SBOM, tra pochi capitoli.

Domanda: se continuo ad aggiornare le dipendenze a ogni CVE, non introduco instabilità e rischio di supply chain (una versione nuova compromessa) peggiore del CVE stesso?

È una tensione reale e va gestita, non ignorata in nessuna delle due direzioni. Aggiornare alla cieca a ogni avviso è sbagliato quanto non aggiornare mai: una nuova versione può introdurre regressioni, o — caso raro ma grave — essere una release compromessa, come negli attacchi di supply chain dove l'account di un maintainer viene violato. La risposta non è scegliere tra "sempre" e "mai", è prioritizzare e verificare. Prioritizzare: non tutti i CVE sono emergenze, la reachability analysis e il contesto dicono quali patchare subito e quali possono attendere una finestra pianificata, così non sei in aggiornamento perpetuo. Verificare: l'aggiornamento passa dalla CI con i tuoi test, non va dritto in produzione; aggiorni a versioni che hanno qualche giorno di vita, non all'ora zero; usi il lockfile con gli hash così sai che stai scaricando esattamente l'artefatto atteso; e, per i rischi di supply chain veri, ti appoggi alla verifica della provenienza e delle firme (SLSA, Sigstore — i prossimi capitoli) invece di fidarti del solo numero di versione. Il rischio di una dipendenza vulnerabile nota, con exploit pubblico, è quasi sempre più alto e più certo del rischio ipotetico di una release compromessa che i controlli di provenienza intercettano. Aggiornare in modo disciplinato riduce entrambi; non aggiornare ne elimina uno solo e ti lascia l'altro, che è anche il più sfruttato.

Conclusione

La SCA illumina il codice che non hai scritto: risolve l’albero transitivo, trova i CVE noti e — se fatta bene — li prioritizza per reachability invece che per conteggio. Insieme al SAST copre il codice, nostro e altrui, in modo statico. Ma entrambi guardano il codice fermo. Alcuni difetti si vedono solo quando l’applicazione gira e risponde a richieste reali: è il turno dell’analisi dinamica, prossimo capitolo.