CI/CD 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.

Security gates: bloccare senza strangolare

Tue, 18 Aug 2026 09:00:00 +0200

Perché conta

Tutti i controlli della serie — SAST, SCA, scanning immagini, policy — a un certo punto devono decidere: fermo o no questa build? Quella decisione è il security gate. Ed è il punto dove DevSecOps vive o muore nella pratica: un gate progettato male non rende sicuri, rende lenti, e un team rallentato trova il modo di disattivarlo. L’obiettivo è un cancello che il team non voglia aggirare.

I due fallimenti simmetrici

  flowchart TD
    A[Gate troppo severo<br/>blocca su tutto] --> A1[Team frustrato<br/>→ disattiva o ignora<br/>→ sicurezza ZERO]
    B[Gate troppo lasco<br/>non blocca mai] --> B1[Decorativo<br/>→ il rischio passa<br/>→ sicurezza ZERO]
    style A1 fill:#fde2e4,stroke:#e63946
    style B1 fill:#fde2e4,stroke:#e63946

Entrambi gli estremi portano allo stesso posto: zero sicurezza effettiva. Il gate utile vive nel mezzo, e ci sta grazie a tre principi.

1. Baseline: blocca il nuovo, non il vecchio

Un repository esistente ha un debito di problemi preesistenti. Un gate che pretende di azzerarlo prima di accettare qualsiasi commit blocca tutto il lavoro: inaccettabile. La baseline separa il debito dalla regressione:

1
2
3

Problemi esistenti (baseline)  →  tracciati, pianificati, NON bloccano
Problemi NUOVI introdotti dalla PR  →  BLOCCANO
# risultato: non peggiori mai, e riduci il debito quando puoi, senza fermare tutto

Così il gate garantisce che la situazione non peggiori a ogni commit, mentre il debito si riduce in modo pianificato, non in un big-bang che paralizza.

2. Severità e contesto, non conteggio

Bloccare su “qualunque finding” produce rumore e aggiramento. Si blocca su ciò che conta: severità alta/critica, raggiungibile, su servizi esposti. La soglia va tarata sul rischio del servizio — un servizio internet-facing che tratta dati sensibili ha un gate più stretto di un tool interno. Il vulnerability management dà i criteri per decidere cosa è “alto” davvero.

3. Eccezioni tracciate, non aggiramenti nascosti

A volte bisogna rilasciare nonostante un finding: un falso positivo, un rischio accettato consapevolmente, un’urgenza. Se l’unico modo è disattivare il gate, prima o poi resta disattivato. Il gate maturo offre una via di eccezione esplicita: si marca il finding come accettato, con un responsabile, una motivazione e una scadenza, e resta tracciato. La differenza tra un’eccezione tracciata e un aggiramento nascosto è tutta: la prima è una decisione di rischio visibile e revisionabile, la seconda è un buco che nessuno ricorda.

Fail closed o fail open?

Cosa succede se il controllo stesso fallisce (lo scanner va in errore, il servizio di policy è giù)? Per i controlli di sicurezza critici, fail closed (blocca) è il default prudente: meglio una build ferma che un’immagine non verificata in produzione. Per i controlli informativi, fail open (passa con warning) evita che un problema infrastrutturale blocchi tutta la consegna. La scelta va fatta consapevolmente per ogni gate, non subita come comportamento accidentale dello strumento.

Domanda: la via di eccezione tracciata non diventa inevitabilmente la scorciatoia che tutti usano per far passare qualsiasi cosa, svuotando il gate dall'interno?

Può diventarlo, ma solo se la progetti come un timbro invece che come una decisione — e la differenza sta in quattro dettagli concreti. Primo, l'eccezione deve costare abbastanza da non essere la via di minor resistenza: richiede un'approvazione di qualcuno diverso da chi la chiede (il principio dei quattro occhi), una motivazione scritta che diventa un record, non un flag silenzioso in un file. Se accettare un rischio è più scomodo che risolverlo per i casi facili, i casi facili si risolvono. Secondo, l'eccezione deve scadere: non "accettato per sempre" ma "accettato fino al 30 del mese prossimo", dopodiché il gate torna a bloccare. Questo impedisce al debito di eccezioni di accumularsi silenziosamente — ogni eccezione è un impegno a tempo, non un condono. Terzo, le eccezioni devono essere visibili e misurate: un cruscotto che mostra quante eccezioni attive ci sono, su quali servizi, chi le ha approvate, quando scadono. Nel momento in cui le eccezioni diventano un numero che qualcuno guarda — e un trend che cresce è un segnale d'allarme discusso nelle metriche di sicurezza — smettono di essere invisibili e quindi di essere abusate. Quarto, va distinta l'eccezione (rischio accettato consapevolmente) dalla soppressione del falso positivo (il finding non è reale): la seconda migliora la taratura dello strumento ed è sana, la prima è una decisione di rischio che va pesata. Il punto di fondo: la via di eccezione non è una debolezza del gate, è ciò che lo rende sostenibile e quindi mantenuto. Un gate senza via di uscita viene disattivato alla prima emergenza legittima, e una volta disattivato protegge zero. Un gate con eccezioni tracciate, approvate, a scadenza e misurate rimane acceso, e il rischio residuo è noto e gestito invece che nascosto. Preferisci cento eccezioni che puoi contare e far scadere, o un gate spento di cui nessuno parla più?

Conclusione

Il security gate utile è un equilibrio: blocca il nuovo rischio alto grazie alla baseline, decide per severità e contesto invece che per conteggio, offre eccezioni tracciate invece di aggiramenti, e sceglie fail-closed o fail-open consapevolmente. Un gate che il team vuole tenere acceso vale più di uno perfetto che viene disattivato. Ma “rischio alto” finora è stato un’etichetta: come si misura e si confronta davvero una vulnerabilità contro le altre? È il vulnerability management, prossimo capitolo.

Sicurezza della pipeline CI/CD

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

Perché conta

SLSA e Sigstore rendono la build verificabile, ma restano un presupposto: che la pipeline stessa non sia già compromessa. Ed è un bersaglio ideale. La CI/CD legge il codice sorgente, custodisce i segreti di produzione, e ha il diritto di deployare. Chi controlla la pipeline non ha bisogno di bucare la produzione: ci arriva passando dalla porta principale. Eppure è spesso l’ambiente meno indurito di tutti.

Perché è un bersaglio così ricco

  flowchart TD
    P[Pipeline CI/CD] --> C[Accesso a TUTTO<br/>il codice sorgente]
    P --> S[Segreti di produzione:<br/>cloud, registry, DB]
    P --> D[Diritto di DEPLOY<br/>in produzione]
    P --> X[Esegue codice<br/>da PR non fidate]
    style P fill:#fde2e4,stroke:#e63946

Un solo ambiente concentra accesso al codice, segreti potenti e privilegi di deploy. E in più esegue codice fornito da altri: un contributo esterno, una dipendenza di build, uno script in un workflow. Questa combinazione — alti privilegi ed esecuzione di codice non fidato — è esattamente ciò che si evita in ogni altro sistema.

I controlli che contano

1. Runner effimeri

Un runner persistente accumula stato tra una build e l’altra: segreti in cache, file lasciati, processi. Un job malevolo può lasciare una backdoor che colpisce i job successivi. I runner effimeri nascono puliti per ogni job e muoiono subito dopo: niente stato da avvelenare. È anche un requisito per i livelli alti di SLSA.

2. Minimo privilegio dei token

Il token di un job dovrebbe potere esattamente ciò che serve a quel job e nulla più:

# GitHub Actions: permessi espliciti e minimi per job
permissions:
  contents: read      # legge il codice, non lo scrive
  id-token: write     # per OIDC (firma / deploy), niente segreti statici
# tutto il resto: negato di default

Il default di molte pipeline è l’opposto: un token onnipotente usato da ogni job. Restringere per job limita il danno di un singolo step compromesso.

3. OIDC invece di chiavi statiche

Mettere le chiavi cloud di lungo termine nei secret della CI è un rischio permanente. Con OIDC la pipeline prova la propria identità al cloud provider e riceve credenziali temporanee per quel job: niente chiave statica da rubare, stesso principio della firma keyless di Sigstore.

4. Difesa dai workflow da PR non fidate

Le pull request da fork sono codice ostile potenziale. Regole essenziali: non dare i segreti ai workflow innescati da PR esterne, richiedere l’approvazione manuale prima di eseguirli, e fissare le action a un hash (uses: actions/checkout@<sha>), non a un tag mutabile che un attaccante potrebbe spostare.

La disciplina delle action di terze parti

Ogni uses: nella pipeline è codice di terzi con l’accesso del job. Un tag come @v3 può essere ri-puntato dall’autore (o da chi lo compromette) a codice diverso. Fissare all’hash del commit rende immutabile ciò che gira, e va trattato come una dipendenza qualsiasi: inventariato, aggiornato con giudizio, verificato.

Domanda: fissare ogni action a un hash e dare permessi minimi a ogni job sembra tanta frizione; con decine di repository, non diventa ingestibile?

La frizione è reale ma è un costo di configurazione una tantum, mentre il rischio che elimina è permanente e si realizza nel modo peggiore — e la soluzione alla scala non è rinunciarvi, è automatizzarlo. Prendi il pinning all'hash: sì, un tag è più comodo di uno sha, ma un tag è mutabile, e la storia recente è piena di action e pacchetti il cui tag è stato ripuntato a codice malevolo dopo che migliaia di pipeline lo usavano già — con l'accesso completo del job, inclusi i segreti. Il pinning trasforma "eseguo qualunque cosa ci sia dietro v3 oggi" in "eseguo esattamente questo commit che ho verificato". Alla scala di decine di repo non lo fai a mano: lo fai con gli stessi strumenti che già usi per le dipendenze — Renovate o Dependabot aggiornano gli hash con pull request testate, esattamente come fanno con le librerie, così resti aggiornato senza fidarti ciecamente di un tag. Lo stesso per i permessi minimi: non li scrivi repo per repo, li imponi con una policy organizzativa — permessi di default a sola lettura a livello di org, template di workflow condivisi, e un controllo in pipeline (anche OPA) che segnala i job con permessi eccessivi. Il punto è che la pipeline è l'ambiente a più alto privilegio che hai: concentra codice, segreti e diritto di deploy. È esattamente il posto dove la frizione di configurazione è giustificata, perché un singolo step compromesso qui non è un bug in un servizio, è l'accesso a tutti i servizi. La domanda da ribaltare è: con decine di repository che possono deployare in produzione, puoi permetterti che non siano induriti?

Conclusione

La pipeline concentra codice, segreti e diritto di deploy, ed esegue codice non fidato: va trattata come l’ambiente più critico, non il più trascurato. Runner effimeri, token a privilegio minimo, OIDC al posto delle chiavi statiche e action fissate all’hash sono i controlli base. Una classe di protezione merita un capitolo a sé, perché gran parte dell’infrastruttura oggi nasce da codice: l’Infrastructure as Code e i suoi rischi, prossimo capitolo.