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

Cultura e security champions: ciò che regge tutto

Tue, 29 Sep 2026 09:00:00 +0200

Perché conta

Abbiamo attraversato trenta capitoli di strumenti, controlli e metriche. Ma tutto quanto — SAST, firma, gate, metriche — poggia su un presupposto che nessuno strumento può fornire: che le persone vogliano la sicurezza. Un team che vive i controlli come un nemico li aggirerà, non importa quanto siano buoni. La cultura è l’infrastruttura invisibile su cui sta tutto il resto, ed è il motivo per cui questo è l’ultimo capitolo e non il primo: ora si capisce cosa la cultura deve sostenere.

Il principio: sicurezza come abilitatore

  flowchart LR
    A[Sicurezza come<br/>freno / cancello] --> A1[Team la aggira<br/>→ attrito, segreti, buchi]
    B[Sicurezza come<br/>abilitatore / guardrail] --> B1[Team la adotta<br/>→ consegna veloce E sicura]
    style A1 fill:#fde2e4,stroke:#e63946
    style B1 fill:#e8f0fe,stroke:#4361ee

Il cambio di cornice è tutto. Un controllo vissuto come freno genera attrito, e l’attrito genera aggiramenti: il gate disattivato, il segreto committato “per fare in fretta”, l’eccezione che diventa regola. Un controllo vissuto come guardrail — qualcosa che ti fa andare veloce perché ti tiene in carreggiata — viene adottato. Il lavoro della cultura è spostare la percezione dal primo al secondo: la sicurezza che dà strumenti, default sicuri e feedback utile, non che dice solo “no”.

I security champions

Il team di sicurezza non può essere ovunque, e non deve: ricreerebbe il silo che DevSecOps vuole abolire. Il modello che scala è il security champion: una persona dentro ogni team di sviluppo, non necessariamente un esperto, che fa da ponte.

Porta il contesto di sicurezza nel team: partecipa alle decisioni di design, solleva la domanda di threat modeling al momento giusto.
Porta il contesto del team alla sicurezza: spiega perché un certo gate è impraticabile, dove i controlli creano attrito inutile.
Diffonde la conoscenza: è il primo punto di contatto, moltiplica la competenza senza moltiplicare il team di sicurezza.

I champion funzionano se sono supportati — tempo dedicato, formazione, riconoscimento — non se è un titolo in più su chi è già oberato.

Default sicuri: la cultura nel codice

La cultura più efficace è quella che non richiede eroismo quotidiano. Rendere la via sicura anche la via facile: template di pipeline che arrivano già con i controlli, immagini base approvate e minimali, librerie interne sicure per default, scaffold di progetto che nascono hardened. Così lo sviluppatore fa la cosa sicura senza doverci pensare, e la cosa insicura richiede uno sforzo consapevole. È cultura cristallizzata in strumenti.

Blameless come norma

L’abbiamo visto per gli incidenti e per le metriche: la colpa nasconde i problemi, l’apertura li risolve. Una cultura in cui segnalare un errore o un dubbio di sicurezza è sicuro — anzi, premiato — è una cultura che vede i suoi rischi. Una in cui ammettere un errore costa è una cultura cieca per scelta. Questo non è un dettaglio soft: è ciò che determina se la tua detection e la tua IR hanno materiale su cui lavorare o se tutto viene insabbiato fino all’incidente grande.

Chiusura della serie

Trenta capitoli, un unico filo: portare la sicurezza dentro il ciclo di sviluppo invece di appiccicarla alla fine. Dal perché dello shift-left, ai controlli di build, alla supply chain, alla pipeline, al runtime di Kubernetes, all’operare nel tempo. Gli strumenti che abbiamo nominato cambieranno — tra due anni alcuni avranno nomi diversi. I principi no: trovare presto costa meno, fidarsi solo di ciò che si verifica, difendere in profondità, misurare senza ingannarsi, e — soprattutto — fare della sicurezza una proprietà del come lavoriamo, non un reparto alla fine della catena. Quella proprietà non si compra: si costruisce, una cultura e un default sicuro alla volta.

Domanda: "cambiare la cultura" suona come la raccomandazione vaga con cui si chiudono tutti gli articoli di sicurezza. Concretamente, da dove parte un team che oggi vive la sicurezza come un freno?

Hai ragione a diffidare: "cambiate cultura" come imperativo astratto è inutile, perché la cultura non si decreta, si costruisce con atti concreti e ripetuti che cambiano l'esperienza quotidiana delle persone. Ecco da dove si parte, in ordine di impatto. Primo e più potente: togliere attrito prima di aggiungere controlli. Se oggi la sicurezza è vissuta come freno, quasi sempre è perché lo è — gate rumorosi, falsi positivi, processi manuali. Prima di chiedere alle persone di "apprezzare la sicurezza", rendi i controlli esistenti meno dolorosi: taratura dei falsi positivi, feedback nella pull request invece che in un report, default sicuri che non richiedono lavoro. Un solo controllo che passa da ostacolo a invisibile cambia la percezione più di qualsiasi predica. Secondo: rendi la via sicura la via facile, concretamente — un template di pipeline con i controlli già dentro, un'immagine base approvata, uno scaffold di progetto che nasce hardened. Non chiedere allo sviluppatore di ricordarsi di essere sicuro, fai sì che lo sia per default e che l'insicurezza richieda uno sforzo. Terzo: nomina e sostieni un security champion per team, con tempo vero allocato (non "in più del lavoro vero") e riconoscimento visibile — è la persona che traduce in entrambe le direzioni ed è il tuo moltiplicatore. Quarto: scegli una vittoria dimostrabile e raccontala. Un CVE critico patchato in ore grazie alla SBOM invece che in settimane; un incidente contenuto in fretta grazie alla detection; un deploy sicuro che è stato anche più veloce. Le persone cambiano abitudine quando vedono il beneficio, non quando lo sentono affermare. Quinto: rendi il blameless reale — la prossima volta che qualcuno segnala un proprio errore, la reazione pubblica dev'essere gratitudine e un fix di sistema, non una colpa; una sola reazione sbagliata qui azzera anni di parole. Nota cosa hanno in comune questi punti: nessuno è "indire una campagna sulla cultura". Sono atti tecnici e gestionali concreti — meno attrito, default sicuri, persone supportate, prove visibili, sicurezza nel segnalare — la cui somma, nel tempo, è ciò che chiamiamo cultura. La cultura non è il punto di partenza da cui discendono le pratiche; è il risultato che emerge da pratiche ripetute che rendono la sicurezza, giorno dopo giorno, la scelta facile e conveniente. Si parte dagli atti, e la cultura segue.

Conclusione

La cultura è ciò che regge tutto il resto: sicurezza come abilitatore e non come freno, security champions che moltiplicano la competenza nei team, default sicuri che fanno della via giusta la via facile, blameless come norma che rende visibili i rischi. Gli strumenti dei trenta capitoli funzionano solo dentro questa cornice — e la cornice si costruisce con atti concreti, non con proclami. Qui la serie DevSecOps si chiude: la sicurezza migliore non è quella che si aggiunge alla fine, è quella che nessuno nota più perché è semplicemente come si lavora.

Metriche DevSecOps: misurare senza ingannarsi

Tue, 22 Sep 2026 09:00:00 +0200

Perché conta

Abbiamo costruito controlli lungo tutto il ciclo. Funzionano? Migliorano? Senza metriche, la sicurezza è opinione: chi urla più forte ottiene le risorse. Ma le metriche sbagliate sono peggio di nessuna, perché orientano il comportamento nella direzione sbagliata con l’autorità apparente del numero. Questo capitolo è su cosa misurare per governare DevSecOps — e sulle trappole che trasformano una buona intenzione in un incentivo perverso.

Le metriche che contano

  flowchart TD
    V[Velocità<br/>DORA: frequenza deploy,<br/>lead time] 
    S[Sicurezza<br/>MTTR vuln, escape rate,<br/>copertura controlli]
    V -->|non in conflitto| EQ[Un buon programma<br/>migliora ENTRAMBE]
    S --> EQ
    style EQ fill:#e8f0fe,stroke:#4361ee

MTTR delle vulnerabilità (Mean Time To Remediate): quanto tempo passa dalla scoperta di un CVE alla sua correzione in produzione. È la metrica regina: misura la capacità di reagire, che è ciò che conta davvero.
Escape rate: quanti difetti sfuggono ai controlli e arrivano in produzione (o peggio, a un incidente). Misura l’efficacia reale della pipeline di controlli.
Copertura dei controlli: quale percentuale di servizi ha SAST, SCA, scanning immagini, firma. La sicurezza è forte quanto l’anello più scoperto.
Metriche DORA (frequenza di deploy, lead time, change failure rate, tempo di ripristino): perché la sicurezza non deve distruggere la velocità, e le due vanno lette insieme.

MTTR: la forma che conta

Un MTTR medio nasconde la coda pericolosa. La media può essere buona mentre pochi CVE critici restano aperti per mesi:

$$ \text{MTTR} = \frac{1}{n}\sum_{i=1}^{n} (t_{\text{fix},i} - t_{\text{scoperta},i}) $$

La media su tutti gli $n$ CVE livella i casi gravi con i banali. Meglio misurare l’MTTR per severità e guardare i percentili (il 95° percentile dei critici), non la media: è nella coda — i pochi CVE critici dimenticati — che vivono gli incidenti, non nel valore medio.

La metrica tossica: “vulnerabilità trovate”

Contare le vulnerabilità trovate come misura di performance è un classico errore. Più cerchi, più trovi: il numero sale quando migliori la detection, e scende quando smetti di guardare. Premiare “poche vulnerabilità trovate” incentiva a cercare meno, l’esatto contrario dell’obiettivo. Conta ciò che riguarda il rischio gestito — MTTR, escape rate, copertura — non l’attività grezza.

La legge di Goodhart

“Quando una misura diventa un obiettivo, cessa di essere una buona misura.”

È il rischio di ogni metrica, non di una sola. Se l’MTTR diventa il bersaglio su cui si viene valutati, si imparerà a chiudere i ticket velocemente — magari marcando come “risolto” senza risolvere, o declassando la severità per far quadrare i numeri. Le contromisure: usare le metriche per apprendere e orientare, non per punire; guardarne più d’una insieme così barare su una peggiora l’altra (chiudere ticket in fretta fa salire l’escape rate); e verificare sul campo che il numero rifletta la realtà. Lo stesso principio del postmortem blameless: le metriche servono a migliorare il sistema, non a trovare colpevoli.

Maturità, nel tempo

Oltre ai numeri operativi, un modello come OWASP DSOMM misura la maturità dei controlli nel tempo — la stessa logica del Secure SDLC: non “fai SAST?” ma “a che livello, con quale copertura, con quale efficacia?”. Serve a mostrare una traiettoria di miglioramento, che è ciò che un programma di sicurezza deve dimostrare più di qualsiasi valore assoluto.

Domanda: se ogni metrica è soggetta alla legge di Goodhart e può essere manipolata, non è meglio evitare di misurare e fidarsi del giudizio degli esperti?

No, e questa è la conclusione sbagliata da trarre da Goodhart — una trappola simmetrica a quella che mette in guardia. "Non misurare e fidarsi del giudizio" suona prudente ma significa tornare esattamente al mondo che le metriche risolvono: la sicurezza come opinione, dove le risorse vanno a chi è più persuasivo o più allarmista, dove non sai se stai migliorando o peggiorando, dove non puoi dimostrare a nessuno — né a te stesso — che un controllo vale il suo costo. Il giudizio degli esperti è prezioso ma non scala, non è verificabile e non protegge da bias: due esperti onesti possono dissentire su dove sta il rischio, e senza dati la discussione non si chiude. Goodhart non dice "non misurare", dice "non trasformare una singola misura in il bersaglio da ottimizzare a tutti i costi". La differenza è enorme. Le contromisure pratiche esistono e sono quelle che un programma maturo applica: primo, misurare un insieme bilanciato di metriche che si tengono a vicenda, così barare sull'una peggiora l'altra — accorciare l'MTTR chiudendo ticket a vuoto fa esplodere l'escape rate e il tasso di riapertura, e il trucco emerge. Secondo, separare le metriche di apprendimento (che usi per capire dove migliorare, e che non devi mai legare a valutazioni individuali, o le corrompi) dalle metriche di allineamento con cui comunichi verso l'alto. Terzo, usare le metriche come inizio di una conversazione, non come verdetto: un numero che peggiora è una domanda ("perché?"), non una condanna. Quarto, validare periodicamente che il numero rifletta la realtà con controlli a campione, red team, incidenti reali — se l'escape rate dice zero ma gli incidenti no, la metrica mente e va aggiustata. Il giudizio degli esperti rientra proprio qui: serve a scegliere le metriche giuste, a interpretarle, a cogliere ciò che sfugge ai numeri. Non è metriche contro giudizio, è metriche che informano il giudizio. Rinunciare a misurare per paura di Goodhart è come rinunciare a guidare per paura che il tachimetro possa essere ingannato: la risposta a uno strumento imperfetto è usarlo con criterio e affiancarne altri, non guidare a occhi chiusi.

Conclusione

Misurare DevSecOps significa guardare MTTR per severità e percentili, escape rate, copertura dei controlli e metriche DORA insieme — mai “vulnerabilità trovate”, e sempre con Goodhart in mente: le metriche orientano e insegnano, non puniscono. Ma nessuna metrica e nessuno strumento funziona se le persone non vogliono la sicurezza. L’ultimo capitolo è quello che tiene su tutti gli altri: la cultura e i security champions.

Compliance as code: la prova continua

Tue, 15 Sep 2026 09:00:00 +0200

Perché conta

Dopo l’incident response, un altro tipo di pressione della fase operate: dimostrare a un revisore, un cliente o un regolatore che i controlli esistono e funzionano. La compliance tradizionale lo fa a mano — screenshot, fogli di calcolo, interviste — con un difetto fatale: fotografa un istante. È vera il giorno dell’audit e magari falsa il giorno dopo, quando qualcuno cambia una configurazione. La compliance as code la rende continua: i controlli sono codice che si verifica sempre e produce evidenze da solo.

Point-in-time contro continuo

  flowchart TD
    subgraph T[Tradizionale]
        A1[Audit annuale] --> A2[Screenshot,<br/>fogli Excel] --> A3["Conforme<br/>...oggi"]
        A3 --> A4[Drift silenzioso<br/>fino al prossimo audit]
    end
    subgraph C[As code]
        B1[Controlli come codice] --> B2[Verifica continua<br/>in pipeline + runtime]
        B2 --> B3[Evidenze generate<br/>automaticamente]
        B3 --> B2
    end
    style A4 fill:#fde2e4,stroke:#e63946
    style B3 fill:#e8f0fe,stroke:#4361ee

Il problema del modello tradizionale non è la fatica, è la finestra: tra due audit l’infrastruttura deriva e nessuno lo sa. La compliance as code chiude la finestra verificando in continuo e segnalando la deviazione quando avviene, non un anno dopo.

I controlli ci sono già

La buona notizia: gran parte dei controlli richiesti dai framework (ISO 27001, SOC 2, PCI DSS) sono proprio quelli costruiti in questa serie. Non serve un lavoro parallelo, serve mappare:

Requisito del framework           →  Controllo tecnico già in pipeline
"gestione delle vulnerabilità"    →  SCA + vulnerability management + gate
"controllo degli accessi"         →  RBAC + least privilege + identità workload
"integrità del software"          →  firma Sigstore + provenienza SLSA + SBOM
"logging e monitoraggio"          →  audit log a prova di manomissione + detection

Ogni controllo tecnico diventa l’evidenza di un requisito. L’audit smette di essere “trova le prove” e diventa “interroga il sistema che le produce già”.

Generare evidenze, non raccoglierle

Il salto di qualità è l’evidenza automatica. Ogni volta che la pipeline firma un’immagine, verifica una policy, blocca un gate o ruota un segreto, genera un record datato e verificabile. Questi record sono l’evidenza di conformità, prodotta come effetto collaterale del lavoro normale — non raccolta a mano in vista dell’ispezione. Standard emergenti come OSCAL permettono di esprimere i controlli e la loro verifica in forma leggibile dalle macchine, così l’audit può essere in parte automatizzato.

Policy as code, di nuovo

La compliance as code è, nella pratica, policy as code applicata ai requisiti normativi: la regola “ogni immagine in produzione deve essere firmata” è allo stesso tempo un controllo di sicurezza e un’evidenza di conformità al requisito di integrità del software. Un solo meccanismo serve due scopi, ed è verificato di continuo invece che attestato una volta l’anno.

Il limite onesto: la mappatura resta umana

Lo strumento verifica i controlli; decidere quali controlli soddisfano quale requisito, e se la copertura è sufficiente, resta un giudizio umano — spesso negoziato con l’auditor. La compliance as code non elimina il revisore: gli dà evidenze migliori e continue, e sposta la conversazione da “mi fai vedere uno screenshot?” a “interroghiamo insieme il sistema”. Riduce la fatica e il teatro, non la responsabilità.

Domanda: se trasformo la compliance in codice automatico, non rischio il "teatro della conformità" inverso — controlli che passano verde ma non riflettono la sicurezza reale, solo spuntati per far felice l'auditor?

È il rischio giusto da tenere d'occhio, perché esiste in entrambi i mondi e la compliance as code lo sposta ma non lo elimina da sola. Il "teatro della conformità" — controlli spuntati che non significano sicurezza reale — nasce quando la conformità diventa il fine invece del mezzo, e questo può succedere con gli screenshot come con il codice. La versione as code ha però due difese che il modello manuale non ha, e un rischio specifico da gestire. Prima difesa: la verifica continua rende molto più difficile il teatro temporale. Con gli screenshot "conforme il giorno dell'audit, derivato il giorno dopo" è la norma; con la verifica continua un controllo che smette di essere vero si accende rosso subito, quindi il verde significa almeno "vero adesso e ieri e l'altroieri", non "vero il 15 marzo alle 10". Seconda difesa: se il controllo di conformità è lo stesso controllo di sicurezza operativo — la policy "solo immagini firmate" che blocca davvero i deploy — allora passarlo per finta significa disattivare la sicurezza vera, non solo ingannare l'auditor; il costo di barare diventa reale. È esattamente per questo che vale la pena far coincidere i due, invece di avere controlli di sicurezza "veri" e controlli di compliance "per l'audit" separati. Il rischio specifico da gestire è il disallineamento tra ciò che il controllo misura e ciò che il requisito intende: un check può essere verde perché misura la cosa sbagliata o una versione svuotata del requisito — "esiste una policy di password" (verde) mentre la policy permette "1234". Qui la compliance as code non ti salva da sola: serve che la mappatura requisito→controllo sia fatta con onestà e rivista, che i controlli misurino la sostanza e non la forma, e che qualcuno — interno o auditor — sfidi periodicamente "questo verde dimostra davvero ciò che il requisito vuole?". In altre parole, l'automazione elimina il teatro della raccolta di prove e della finestra temporale, ma la qualità del significato dei controlli resta un giudizio umano da presidiare. Il modo per non cadere nel teatro inverso è ancorare ogni controllo a un rischio reale che ti interessa ridurre, non a una casella da spuntare: se il controllo esiste perché previene un attacco che temi, il suo verde vale; se esiste solo perché un documento lo chiede, sei già nel teatro, codice o screenshot che sia.

Conclusione

La compliance as code rende la conformità continua invece che istantanea: i controlli sono codice verificato sempre, le evidenze si generano da sole come effetto del lavoro normale, e gran parte dei requisiti è già coperta dai controlli della pipeline. È policy as code applicata ai framework, con la mappatura che resta umana. Tutto questo — pipeline, runtime, operate, conformità — va governato e misurato per sapere se funziona e migliora. Le metriche DevSecOps sono il prossimo capitolo.

Incident response nel mondo DevSecOps

Tue, 08 Sep 2026 09:00:00 +0200

Perché conta

La detection scatta. E adesso? Un’allerta senza una risposta preparata è panico in tempo reale: decisioni improvvisate, prove distrutte per sbaglio, tempi lunghi. La incident response (IR) è il piano che trasforma il caos in procedura. E in un mondo DevSecOps — infrastruttura immutabile, tutto automatizzato, artefatti verificabili — la risposta cambia forma rispetto all’IR tradizionale: si sfruttano proprio le proprietà che abbiamo costruito nei capitoli precedenti.

Le fasi, in breve

  flowchart LR
    PREP[Preparazione<br/>runbook, ruoli,<br/>accessi] --> DET[Rilevamento<br/>+ analisi]
    DET --> CONT[Contenimento<br/>isola]
    CONT --> ERAD[Eradicazione<br/>rimpiazza]
    ERAD --> REC[Recupero]
    REC --> LESS[Lezioni apprese<br/>postmortem]
    LESS -.migliora.-> PREP
    style CONT fill:#fde2e4,stroke:#e63946

Il modello NIST è un ciclo: ci si prepara prima, si rileva e analizza, si contiene, si eradica, si recupera, e si imparano le lezioni che migliorano la preparazione. La differenza DevSecOps sta in come si eseguono contenimento ed eradicazione.

Isola e rimpiazza, non riparare

Nell’IR classico si “ripuliva” un server compromesso. In un’infrastruttura immutabile è un errore: non sai cosa l’attaccante ha toccato, quindi non puoi fidarti di nessuna pulizia. Il modello cloud-native è diverso:

Contenimento:  isola il pod/nodo compromesso (network policy, cordon)
               → preservalo per la forense, NON spegnerlo subito
Eradicazione:  rimpiazza con un'istanza NUOVA da un artefatto PULITO e firmato
               → non riparare il compromesso, sostituiscilo

Il contenimento sfrutta la microsegmentazione: una network policy che taglia il pod dal resto del cluster lo ferma senza distruggere le prove. L’eradicazione sfrutta gli artefatti firmati e immutabili: si ridistribuisce una versione pulita verificabile, con la certezza di cosa contiene.

La provenienza come bussola forense

Durante l’analisi, le proprietà costruite prima diventano strumenti d’indagine. La SBOM dice esattamente cosa girava nell’immagine compromessa. La provenienza SLSA dice da quale commit e quale build proveniva. Gli audit log a prova di manomissione danno la timeline. La domanda “cosa è stato toccato?” — che senza questi dati richiede settimane — diventa una serie di query.

Automazione: contenere alla velocità della macchina

Gli attacchi automatizzati vanno più veloci di un umano. Per i casi ad alta confidenza, il contenimento può essere automatico (SOAR): la detection “pod che esfiltra dati” innesca da sola l’isolamento del pod, poi avvisa gli umani. L’automazione compra i minuti che contano, con la stessa cautela dell’enforce nella runtime security: solo su segnali affidabili, per non isolare servizi sani a un falso positivo.

Il blameless postmortem

La fase più trascurata e più preziosa. Dopo l’incidente, un postmortem senza colpevoli ricostruisce cosa è successo e perché i controlli non l’hanno fermato — non chi ha sbagliato. L’output non è una reprimenda ma azioni concrete: una regola di detection nuova, un gate più stretto, un controllo mancante aggiunto alla pipeline. È così che l’incidente alimenta il miglioramento invece di ripetersi, chiudendo il ciclo DevSecOps.

Domanda: il "blameless postmortem" non è un modo per non responsabilizzare nessuno? Se nessuno paga per l'errore, cosa impedisce che si ripeta?

È l'obiezione classica, e si basa su un'intuizione sbagliata su cosa previene la ripetizione degli errori. L'idea che la paura della colpa migliori la sicurezza è intuitiva ma smentita da decenni di pratica nelle industrie ad alto rischio, dall'aviazione alla medicina: la colpa non previene gli errori, li nasconde. Se sai che ammettere un errore ti costa, la tua reazione razionale non diventa "starò più attento", diventa "non lo segnalerò, non lascerò tracce, dirò che non so come sia successo". Il risultato è che perdi esattamente l'informazione che ti serve per correggere il sistema, e l'errore si ripete — solo che ora nessuno te lo dice finché non esplode di nuovo, più in grande. "Blameless" non significa "nessuna responsabilità": significa separare la responsabilità di capire e migliorare il sistema (collettiva, aperta, onesta) dalla ricerca di un capro espiatorio (che distrugge l'onestà senza aggiungere sicurezza). Il postmortem blameless parte da un presupposto preciso: le persone competenti fanno quasi sempre scelte sensate con le informazioni e gli strumenti che avevano in quel momento. Quindi se qualcuno ha fatto un errore, la domanda produttiva non è "perché quella persona è incompetente?" ma "perché il sistema ha permesso che quell'errore facile da fare arrivasse fino in produzione? dov'era il controllo che avrebbe dovuto intercettarlo?". Questo porta ad azioni concrete che prevengono davvero la ripetizione — un gate mancante, una detection assente, una procedura ambigua, un valore di default pericoloso — mentre "licenziamo il responsabile" lascia il sistema identico e pronto a far inciampare la prossima persona allo stesso modo. La responsabilità vera, in questo modello, è dare seguito alle azioni del postmortem: quello sì che va tracciato e preteso. Punire l'individuo è emotivamente soddisfacente e tecnicamente inutile; correggere il sistema è il contrario, ed è l'unico che riduce il tasso di incidenti nel tempo.

Conclusione

L’incident response DevSecOps isola e rimpiazza invece di riparare, usa SBOM, provenienza e audit log come bussola forense, automatizza il contenimento sui segnali affidabili e chiude con un postmortem blameless che migliora i controlli. Il piano trasforma il panico in procedura. Molto di ciò che abbiamo costruito — controlli, audit, procedure — deve anche dimostrarsi a un revisore o a un regolatore. Farlo senza fermare la consegna è la compliance as code, prossimo capitolo.

Logging e detection per DevSecOps

Tue, 01 Sep 2026 09:00:00 +0200

Perché conta

Il vulnerability management ordina ciò che sappiamo; la runtime security rileva comportamenti anomali. Ma entrambi dipendono dal vedere. Senza log, un attacco riuscito è invisibile: non sai che è successo, non sai cosa è stato toccato, non puoi rispondere. Il logging è la memoria del sistema, e la detection è ciò che la rende utile. Estende il tema del SIEM e della correlazione dei log al mondo DevSecOps: pipeline, cluster, runtime.

Quali segnali, dove

  flowchart TD
    PIPE[Pipeline CI/CD:<br/>chi ha deployato cosa,<br/>accesso ai segreti] --> AGG[Aggregazione<br/>centrale]
    K8S[Audit log K8s:<br/>chiamate all'API,<br/>exec nei pod, RBAC] --> AGG
    RUN[Runtime / Falco:<br/>processi, rete, file] --> AGG
    APP[App:<br/>auth, errori,<br/>accessi ai dati] --> AGG
    AGG --> DET[Detection<br/>+ correlazione]
    DET --> ALERT[Allerte azionabili]
    style DET fill:#fde2e4,stroke:#e63946

I quattro flussi che contano in DevSecOps:

Audit log di Kubernetes: ogni chiamata all’API — chi ha creato cosa, chi ha letto quali secret, chi ha fatto exec in un pod. È la fonte primaria per investigare una compromissione del cluster.
Log della pipeline: chi ha innescato quale deploy, chi ha acceduto a quali segreti, quali eccezioni ai gate sono state usate. La pipeline è un bersaglio: va osservata.
Eventi di runtime (Falco/eBPF): i comportamenti anomali dei container.
Log applicativi: autenticazioni, errori, accessi ai dati sensibili.

A prova di manomissione

Un attaccante esperto, dopo essere entrato, cancella le proprie tracce. Se i log vivono dove gira il carico, può alterarli. Perciò i log di sicurezza vanno spediti fuori verso un deposito append-only e ad accesso ristretto, a cui il carico compromesso non può scrivere né cancellare. È il principio di non-ripudio dello STRIDE: i log servono proprio quando qualcuno vuole poter dire “non sono stato io”.

1
2

Log sul nodo compromesso        → l'attaccante li cancella → cieco
Log spediti a store append-only → immutabili → hai la timeline dell'attacco

Dal data lake alla detection

Raccogliere tutto e non guardarlo è il fallimento più comune: un data lake costoso che serve solo dopo, per l’autopsia. Il valore sta nella detection: regole che trasformano i log in allerte mentre l’attacco accade.

Basata su regole: pattern di tecniche note, idealmente mappati su MITRE ATT&CK (“accesso a un secret seguito da connessione in uscita insolita”).
Basata su anomalie: deviazioni dal comportamento normale appreso.
Correlazione: unire segnali deboli di fonti diverse in un segnale forte — un fallimento di auth più un exec nel pod più una connessione a un IP sconosciuto raccontano una storia che ogni singolo evento non racconta.

Meno rumore, più segnale

Vale qui la legge della runtime security: le allerte inutili addestrano il team a ignorarle. Una detection va tarata — soppressione del noto, soglie sensate, arricchimento con il contesto (quale servizio, quale ambiente, quale owner) — così ogni allerta che arriva merita di essere guardata. Una detection ignorata è peggio di nessuna, perché dà l’illusione di vedere.

Domanda: con l'observability che già abbiamo per il debugging (metriche, log, tracce), perché serve un flusso di logging separato "di sicurezza"? Non sono gli stessi dati?

Si sovrappongono in parte, ma hanno requisiti così diversi su tre assi che trattarli come un flusso solo compromette entrambi gli scopi. Primo asse, l'integrità e la fiducia. L'observability per il debugging è ottimizzata per comodità e costo: i log vivono vicino ai carichi, sono scrivibili, spesso con ritenzione breve e accesso ampio perché servono agli sviluppatori per lavorare. I log di sicurezza hanno il requisito opposto: devono essere a prova di manomissione, perché il loro utente avversario è proprio chi ha compromesso il sistema e vuole cancellare le tracce. Un log di debug che l'attaccante può alterare è inutile come prova; un log di sicurezza deve vivere in uno store append-only che il carico compromesso non può toccare. Secondo asse, il contenuto. L'observability cattura ciò che serve a capire perché il sistema è lento o rotto: latenze, code, stack trace. La detection ha bisogno di eventi che il debugging spesso non raccoglie affatto — chi ha letto quale secret, chi ha fatto exec in quale pod, quali RBAC sono cambiati, quali eccezioni ai gate sono state usate — e che vanno registrati anche quando tutto "funziona", perché un attacco riuscito spesso non rompe nulla. Terzo asse, la ritenzione e la conformità. Un incidente si scopre in media mesi dopo: i log di sicurezza devono sopravvivere molto più a lungo dei log operativi, spesso per obblighi normativi, con garanzie di conservazione che l'observability non ha. Detto questo, non significa costruire due infrastrutture che si ignorano: i dati di observability sono una fonte preziosa per la detection (un picco anomalo di errori può essere un attacco), e molte piattaforme uniscono i pipe di raccolta. Il punto è che i log di sicurezza aggiungono requisiti — immutabilità, eventi di audit specifici, ritenzione lunga, accesso ristretto — che l'observability da sola non soddisfa. Puoi condividere la raccolta, non puoi condividere le garanzie: un data lake di debug riusato come fonte di prova forense ti lascia scoperto esattamente quando l'attaccante ha fatto il suo lavoro.

Conclusione

Non puoi rispondere a ciò che non vedi: audit log del cluster, log della pipeline, eventi di runtime e log applicativi, spediti fuori in uno store a prova di manomissione, trasformati in detection correlate e tarate contro il rumore. Il logging è la memoria, la detection è l’allarme. Ma un allarme senza una procedura di risposta è solo un suono nel vuoto. Cosa fare quando la detection scatta è la risposta agli incidenti, prossimo capitolo.

Vulnerability management: dal CVSS al rischio reale

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

Perché conta

Il security gate deve decidere cosa è “rischio alto”, e il patch management deve decidere cosa patchare prima. Entrambi si scontrano con lo stesso muro: diecimila CVE aperti, un team con tempo finito. Patchare tutto è impossibile; patchare a caso è pericoloso. Il vulnerability management è la disciplina di mettere in ordine ciò che conta — e comincia dal capire perché il punteggio che tutti usano, da solo, inganna.

Perché il solo CVSS inganna

Il CVSS misura la gravità tecnica di una vulnerabilità: quanto sarebbe grave se sfruttata. Utile, ma risponde alla domanda sbagliata se usato da solo. Un CVE con CVSS 9.8 su una libreria che non è mai esposta a input ostile, e che nessuno sta sfruttando nel mondo, è meno urgente di un CVSS 7.5 con exploit pubblico e attivo sul tuo servizio internet-facing. Ordinare la coda per solo CVSS significa lavorare sui numeri grandi, non sui rischi reali.

EPSS: la probabilità di sfruttamento

L’EPSS (Exploit Prediction Scoring System) aggiunge la dimensione mancante: la probabilità che un CVE venga sfruttato nei prossimi 30 giorni, stimata da un modello su segnali reali (exploit pubblicati, attività osservata). È un numero tra 0 e 1:

$$ \text{EPSS}(cve) = P(\text{sfruttamento entro 30 giorni}) \in [0, 1] $$

Il valore pratico di EPSS è che la stragrande maggioranza dei CVE ha probabilità bassissima di essere sfruttata: filtrare per EPSS alto riduce una coda di migliaia a una manciata di voci che meritano attenzione ora.

Comporre il rischio

Nessun punteggio singolo basta. Il rischio operativo nasce dalla composizione di gravità, probabilità ed esposizione nel tuo contesto:

$$ \text{Rischio} \approx \underbrace{\text{CVSS}}{\text{se sfruttato}} \times \underbrace{\text{EPSS}}{\text{quanto è probabile}} \times \underbrace{E}_{\text{esposizione}} $$

dove $E$ cattura il contesto che solo tu conosci: il servizio è esposto a internet? tratta dati sensibili? la funzione vulnerabile è davvero raggiungibile dal tuo codice? Una formula del genere non è una verità esatta, è un modo per ordinare la coda in modo difendibile invece che per numero grezzo.

Il segnale che batte tutto: KEV

C’è una scorciatoia che precede ogni calcolo. Se un CVE è nel catalogo CISA KEV (Known Exploited Vulnerabilities), significa che è sfruttato attivamente, ora, nel mondo reale. Questi vanno patchati per primi, sempre, indipendentemente dal CVSS:

Ordine di priorità pratico:
  1. Nel catalogo KEV (sfruttato ORA)           → emergenza, patch immediata
  2. EPSS alto + esposto + raggiungibile        → questa settimana
  3. CVSS alto ma EPSS basso / non raggiungibile → finestra pianificata
  4. Non raggiungibile, non esposto              → debito, quando capita

Il ciclo, non l’evento

Il vulnerability management non è una scansione una tantum ma un ciclo: scoprire (da SCA, SBOM, scanner runtime), prioritizzare (CVSS × EPSS × contesto, con KEV in cima), rimediare (patch o mitigazione) e verificare che la correzione sia davvero in produzione. E ricominciare, perché ogni giorno arrivano CVE nuovi su software che non hai toccato. L’obiettivo non è “zero vulnerabilità” — irraggiungibile — ma tenere il rischio noto e sotto una soglia accettabile, con le decisioni tracciate.

Domanda: se prioritizzo con EPSS e raggiungibilità, non rischio di rimandare per sempre un CVSS 9.8 "non raggiungibile" che poi diventa sfruttabile dopo un mio cambio di codice?

È il rischio corretto da temere, e la risposta non è abbandonare la prioritizzazione — che è l'unica alternativa al collasso sotto diecimila CVE — ma renderla dinamica e non un giudizio dato una volta per sempre. Primo, "non raggiungibile" e "EPSS basso" non significano "ignorato": significano "declassato a debito tracciato con una finestra pianificata". Il CVE resta nell'inventario, resta visibile, e viene comunque affrontato — solo dopo ciò che è sfruttato attivamente. La differenza tra "debito pianificato" e "dimenticato" è che il primo è in una lista che qualcuno rivede. Secondo, e qui sta il punto che sollevi: la prioritizzazione va rivalutata di continuo, perché i suoi input cambiano. L'EPSS si aggiorna ogni giorno: un CVE con probabilità bassissima oggi può schizzare quando viene pubblicato un exploit, e un buon sistema di vulnerability management ri-valuta l'intera coda sui punteggi aggiornati, così quel 9.8 "dormiente" risale automaticamente in cima nel momento in cui diventa pericoloso — tipicamente prima che tu venga colpito, perché l'EPSS reagisce alla comparsa dell'exploit, non all'attacco. La comparsa nel catalogo KEV fa lo stesso in modo ancora più netto. Terzo, la raggiungibilità è una proprietà del tuo codice attuale, e hai ragione che un cambio può renderla vera: per questo la raggiungibilità si ricalcola a ogni build nella SCA, non si congela. Se una pull request inizia a chiamare la funzione prima irraggiungibile, lo stesso CVE cambia classe e il gate lo intercetta su quella PR. Quindi il meccanismo che temi — "lo rimando e mi dimentico" — è esattamente ciò che un vulnerability management fatto a ciclo impedisce: niente è giudicato una volta sola, ogni CVE è ri-pesato quando cambiano l'EPSS, il KEV o il tuo codice. La prioritizzazione non è "scegliere cosa ignorare per sempre", è "scegliere l'ordine, e rivedere l'ordine quando il mondo cambia". L'unica vera alternativa — trattare tutti i diecimila CVE come ugualmente urgenti — garantisce che il team si bruci sui 9.8 teorici mentre il 7.5 con exploit attivo aspetta il suo turno in fondo a una lista ordinata per numero. Quello sì che è dimenticare ciò che conta.

Conclusione

Il vulnerability management mette ordine nel caos dei CVE: il CVSS misura la gravità ma inganna da solo, l’EPSS aggiunge la probabilità di sfruttamento, il contesto aggiunge l’esposizione, e il catalogo KEV batte ogni calcolo. È un ciclo che ri-pesa tutto quando cambia il mondo, non un giudizio una tantum. Questo dipende dal sapere cosa succede — le fonti di segnale. Portare i log e la detection dentro la pipeline e il runtime è il prossimo 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.

Patch e dipendenze: il debito che matura

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

Perché conta

La SCA e la SBOM dicono cosa è vulnerabile. Ma trovare non è correggere, e qui comincia il lavoro vero della fase operate: un flusso infinito di CVE su software già in produzione. Le dipendenze non aggiornate sono, anno dopo anno, tra i vettori d’ingresso più sfruttati in assoluto — non per sofisticazione, ma per pigrizia collettiva. Il problema non è tecnico, è di sostenibilità del flusso.

Il debito che matura da solo

Un codice fermo non è un codice sicuro: le vulnerabilità arrivano a lui, non da lui.

Giorno del rilascio:   0 CVE noti nelle dipendenze
3 mesi dopo:           3 CVE scoperti (tu non hai toccato nulla)
12 mesi dopo:          decine di CVE, e il salto di versione è ormai enorme
→ "non aggiorniamo per non rompere" → il costo di aggiornare cresce ogni mese

Il paradosso: più rimandi, più l’aggiornamento diventa rischioso (tre major in un colpo), e più rimandi ancora. Si esce solo con aggiornamenti piccoli e frequenti, resi indolori dall’automazione.

Automatizzare il flusso

  flowchart LR
    SRC[(Nuova versione<br/>o CVE)] --> BOT[Bot: Renovate /<br/>Dependabot]
    BOT -->|apre PR| CI[CI: build + test<br/>+ SCA]
    CI -->|verde| MERGE[Merge<br/>auto o rapido]
    CI -->|rosso| HUMAN[Revisione umana]
    style BOT fill:#fde2e4,stroke:#e63946

Un bot apre pull request di aggiornamento; la CI le testa; quelle a basso rischio (patch, minor con test verdi) si possono auto-mergiare, le altre vanno a revisione. Il team non insegue più i CVE a mano: gestisce un flusso di PR già testate. Questo trasforma il patching da progetto periodico doloroso a routine continua invisibile.

Non tutto è urgente: prioritizzare

Patchare tutto subito è impossibile e inutile. Si prioritizza per rischio reale, non per numero:

Sfruttamento attivo: un CVE nel catalogo CISA KEV (vulnerabilità sfruttate in natura) va prima di cento CVE teorici. Chi vi attacca usa quelli.
Esposizione: internet-facing e dati sensibili prima dei servizi interni.
Raggiungibilità: il CVE in codice che esegui davvero, non in una funzione mai chiamata — il tema del vulnerability management.

Le immagini base: un flusso dedicato

Le immagini container hanno una dinamica propria: anche se la tua app non cambia, la base accumula CVE nei pacchetti OS. La pratica è ricostruire periodicamente le immagini dalla base aggiornata (una pipeline schedulata che ricompila e ridistribuisce), non solo quando cambia il codice. Un’immagine minimale riduce drasticamente questo flusso, perché ha meno pacchetti da patchare.

Patch virtuale: guadagnare tempo

Quando non si può patchare subito (nessuna fix disponibile, finestra di manutenzione lontana, sistema legacy), la patch virtuale compra tempo: un WAF o le regole di runtime security bloccano lo sfruttamento del CVE mentre la correzione vera viene pianificata. È una mitigazione, non una cura: riduce il rischio nell’immediato, non elimina la vulnerabilità.

Domanda: l'auto-merge degli aggiornamenti non è pericoloso? Un bot che fonde dipendenze da solo è esattamente il vettore di un attacco di supply chain.

È una preoccupazione legittima, e la risposta non è "mai auto-merge" né "auto-merge di tutto", ma calibrare l'automazione sul rischio e circondarla di controlli — perché l'alternativa, il patching manuale, ha un tasso di fallimento molto più alto e più silenzioso. Partiamo dal rischio che sollevi: una release compromessa (account del maintainer violato, pacchetto typosquatting) fusa automaticamente in produzione. Si mitiga così. Primo, l'auto-merge non va mai dritto in produzione: fonde in un branch che passa dalla tua CI completa — build, test, SCA, policy — e poi dalla tua pipeline di deploy con i suoi gate; non è "il bot spinge in prod", è "il bot propone, i tuoi controlli decidono". Secondo, si auto-mergia solo la classe a basso rischio: patch e minor con changelog pulito e test verdi, non i major, non le dipendenze critiche di sicurezza, che vanno a revisione umana. Terzo, si impone una quarantena temporale: Renovate può aspettare che una versione abbia N giorni di vita prima di proporla (minimumReleaseAge), così le release malevole, che di solito vengono scoperte e ritirate in fretta, non ti raggiungono all'ora zero. Quarto, i lockfile con hash garantiscono che stai scaricando esattamente l'artefatto atteso, e la verifica di provenienza (SLSA/Sigstore) aggiunge un controllo sull'origine. Ora il rovescio: non automatizzare significa che gli aggiornamenti si accumulano perché "non c'è tempo", il debito matura, e finisci per girare mesi con CVE noti e con exploit pubblici — un rischio molto più certo e sfruttato di una release compromessa che la quarantena intercetta. Il patching manuale fallisce per omissione, in silenzio, ed è il vettore numero uno delle violazioni reali. L'automazione ben calibrata riduce quel rischio enorme e certo, al prezzo di un rischio piccolo e gestibile con quarantena, test e provenienza. La domanda giusta non è "mi fido del bot?" ma "mi fido dei miei controlli automatici più di quanto mi fidi del fatto che qualcuno aggiorni a mano in tempo?" — e quasi sempre la risposta onesta è sì.

Conclusione

Le dipendenze non aggiornate sono il vettore più sfruttato perché il debito matura da solo: si gestisce con aggiornamenti piccoli e frequenti automatizzati dai bot, immagini base ricostruite di continuo, prioritizzazione per sfruttamento reale (KEV) e patch virtuale per guadagnare tempo. Ma decidere cosa patchare prima richiede un modo per confrontare migliaia di CVE: metriche, contesto, triage. È il vulnerability management, prossimo capitolo.

Identità dei workload: dal codice al cloud

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

Perché conta

Il capitolo sui segreti in Kubernetes si è chiuso con un’idea radicale: il modo più sicuro di gestire un segreto è non averne uno. Invece di consegnare a un servizio una chiave statica — che va custodita, ruotata, e che se trapela vale finché non la revochi — gli si dà un’identità, e le credenziali si derivano da quell’identità, attestata dalla piattaforma, a vita breve. È lo stesso principio della firma keyless di Sigstore e dell’identità Zero Trust di SPIFFE/SPIRE, portato attraverso tutto il ciclo DevSecOps.

Il problema del “segreto zero”

Ogni schema a chiavi statiche ha la stessa ricorsione: per proteggere il segreto serve un altro segreto. L’identità dei workload spezza la catena ancorandosi a qualcosa che la piattaforma testimonia.

  flowchart LR
    W[Workload<br/>pod / job CI] -->|"sono il SA X<br/>nel namespace Y"| P[Piattaforma<br/>attesta l'identità]
    P -->|token OIDC<br/>firmato| ID[Identità provata]
    ID -->|scambia con| C[Cloud / Vault<br/>IAM]
    C -->|credenziali TEMPORANEE<br/>a vita breve| W
    style C fill:#fde2e4,stroke:#e63946

Il workload non presenta nessuna chiave: prova chi è (il ServiceAccount, provato dal cluster) e in cambio riceve credenziali temporanee. Non c’è nessun segreto di lunga durata da rubare, perché non esiste.

Nella pipeline: OIDC federation

L’abbiamo già incontrato parlando della pipeline CI/CD: la workload identity federation permette alla CI di autenticarsi al cloud senza chiavi statiche nei secret. La pipeline presenta un token OIDC che prova “sono la build del repo X sul branch main”; il cloud, configurato a fidarsi di quell’emittente e di quell’identità precisa, rilascia credenziali temporanee valide per il job.

1
2

Prima:  AWS_SECRET_KEY statica nei secret della CI  → se trapela, accesso per sempre
Dopo:   token OIDC "repo:org/app:ref:main"          → credenziali valide ~1h, legate al job

Nel runtime: dal ServiceAccount al cloud

Stessa logica dentro il cluster: un pod ha un ServiceAccount, il cui token (proiettato, a vita breve) il cluster firma. Quel token si federa verso il cloud (IAM Roles for Service Accounts, Workload Identity, Managed Identity) per ottenere credenziali cloud temporanee, oppure verso un vault per i segreti applicativi. Per l’identità servizio-a-servizio, SPIFFE/SPIRE emette SVID a vita breve per mTLS, come visto nella serie Zero Trust.

Perché è il punto d’arrivo naturale

L’identità dei workload chiude il cerchio del least privilege e del JIT: ogni componente ha esattamente l’accesso che la sua identità consente, per il tempo in cui serve, senza credenziali permanenti. È la fine della caccia ai segreti statici: non si tratta più di proteggere mille chiavi, ma di eliminarle, sostituendole con identità verificabili e credenziali effimere. È anche il legame più diretto tra DevSecOps e Zero Trust.

Domanda: se le credenziali si derivano dall'identità "attestata dalla piattaforma", non abbiamo semplicemente reso la piattaforma (il cluster, il provider OIDC) l'unico segreto che, se compromesso, dà accesso a tutto?

Hai individuato dove si concentra la fiducia, ed è giusto guardarci, ma il confronto corretto non è "identità contro nessun rischio", è "identità contro mille chiavi statiche sparse" — e su quel confronto l'identità vince nettamente, per ragioni concrete. Primo, la superficie. Con le chiavi statiche hai N segreti di lunga durata in N posti: file di config, variabili d'ambiente, secret di CI, backup, laptop, wiki dimenticate. Ognuno è un punto di fuga indipendente, e statisticamente qualcuno trapela: la maggior parte delle violazioni cloud nasce esattamente da una chiave finita dove non doveva. Con l'identità dei workload quei segreti non esistono: non c'è nulla da trapelare in N posti, c'è un meccanismo di attestazione in un posto. Hai ridotto N punti fragili a un punto, progettato apposta per essere protetto. Secondo, la natura di quel punto. Compromettere "la piattaforma" non è come rubare una stringa: richiede di compromettere il control plane del cluster o il sistema di firma OIDC del provider — componenti isolati, monitorati, con il proprio hardening — ed è un problema di sicurezza che hai comunque, chiavi o no: se un attaccante controlla il tuo cluster, hai già perso, indipendentemente da come gestisci i segreti. L'identità non crea quel rischio, lo rende semplicemente l'unico che conta, invece di sommarlo ai mille rischi delle chiavi. Terzo, il tempo e la verificabilità. Le credenziali derivate sono effimere: anche nel caso peggiore, una credenziale catturata vale minuti, non mesi, e la finestra di attestazione è vincolata a un'identità precisa ("quel repo, quel branch", "quel SA, quel namespace"), non a "chiunque abbia la chiave". E ogni scambio di token è tracciabile e revocabile centralmente: puoi togliere accesso a un'identità istantaneamente, cosa impossibile con una chiave statica già copiata altrove. Quindi sì, la fiducia si concentra — ma si concentra su qualcosa di piccolo, difendibile, monitorato ed effimero, sottraendola a qualcosa di diffuso, fragile e permanente. Concentrare la fiducia dove puoi difenderla è una strategia di sicurezza, non un difetto: è lo stesso motivo per cui metti i valori in una cassaforte invece che sotto mille zerbini.

Conclusione

L’identità dei workload sostituisce le chiavi statiche con credenziali effimere derivate da chi è il servizio, attestato dalla piattaforma: OIDC federation nella pipeline, ServiceAccount e SPIFFE a runtime. Il segreto più sicuro è quello che non esiste. Con questo chiudiamo i controlli di build e runtime; resta la parte operate, dove il software vive nel tempo e le vulnerabilità emergono dopo il rilascio. Si parte dal tenere aggiornato ciò che gira: patch e dipendenze, prossimo capitolo.

Segreti in Kubernetes senza lacrime

Tue, 28 Jul 2026 09:00:00 +0200

Perché conta

Abbiamo imparato a non mettere mai i segreti nel codice. Nel cluster il problema torna con una trappola specifica: i Secret di Kubernetes sono codificati in base64, non cifrati. Chiunque legga l’oggetto Secret, o acceda a etcd, li legge in chiaro con un comando. Sono comodi per consegnare un segreto a un pod, ma pessimi come deposito. Questo capitolo è come usarli bene senza illudersi.

base64 non è cifratura

1
2
3

kubectl get secret db-pass -o jsonpath='{.data.password}' | base64 -d
# → stampa la password in chiaro.
# base64 è una CODIFICA, non una protezione: reversibile da chiunque, senza chiave.

Due conseguenze immediate: cifrare etcd a riposo (encryption-at-rest, idealmente con un KMS esterno) perché altrimenti chi copia etcd ha tutti i segreti; e restringere con RBAC chi può leggere i Secret, perché il permesso get secrets equivale ad avere quei segreti.

Il problema del GitOps

Il GitOps vuole tutto in git, inclusa la configurazione dei Secret. Ma committare un Secret, anche base64, è committare il segreto in chiaro nella history. Due soluzioni opposte:

  flowchart TD
    subgraph A[External Secrets Operator]
        G1[Git: solo un<br/>RIFERIMENTO al segreto] --> ESO[Operator]
        V[(Vault / cloud<br/>secret manager)] --> ESO
        ESO -->|crea/sincronizza| S1[Secret nel cluster]
    end
    subgraph B[Sealed Secrets]
        G2[Git: segreto<br/>CIFRATO, sicuro da<br/>committare] --> CTRL[Controller]
        CTRL -->|decifra con chiave<br/>solo nel cluster| S2[Secret nel cluster]
    end
    style V fill:#fde2e4,stroke:#e63946

External Secrets Operator: la fonte di verità resta un vault esterno; in git c’è solo un riferimento. L’operator sincronizza. Il segreto non tocca mai git.
Sealed Secrets: il segreto si cifra con una chiave pubblica; la cifratura è sicura da committare perché solo il controller nel cluster ha la chiave privata per decifrarla.

Montare senza esporre

Il modo in cui il segreto arriva al container conta. Le variabili d’ambiente sono comode ma trapelano facilmente (compaiono nei dump, nei log di errore, nell’introspezione del processo). Montare i segreti come file è più sicuro, e i CSI Secrets Store driver fanno un passo oltre: montano il segreto dal vault esterno direttamente nel filesystem del pod a runtime, senza nemmeno creare un oggetto Secret persistente. Il segreto esiste solo finché il pod vive.

Rotazione e vita breve

Vale qui ciò che valeva per i segreti applicativi: meglio dinamici e a vita breve che statici e rotati a mano. L’External Secrets Operator può ri-sincronizzare periodicamente; i vault possono emettere credenziali effimere. E l’approdo naturale è non consegnare affatto un segreto condiviso, ma dare a ogni workload una identità da cui derivare le credenziali — il tema del prossimo capitolo.

Domanda: se cifro etcd a riposo e restringo l'RBAC, i Secret nativi di Kubernetes non sono già abbastanza sicuri? Perché aggiungere la complessità di vault esterni e operator?

Cifrare etcd e stringere l'RBAC sono necessari e vanno fatti comunque, ma risolvono solo una parte del problema, e la parte che lasciano aperta è spesso quella dove i segreti trapelano davvero. Cosa coprono: chi ruba una copia di etcd non legge i segreti (cifratura a riposo), e chi non ha i permessi non può fare get secrets (RBAC). Cosa non coprono: primo, il ciclo di vita. Un Secret nativo è statico — lo crei una volta e resta lì finché qualcuno lo ruota a mano, cosa che in pratica non succede mai; non c'è rotazione automatica, non c'è scadenza, un segreto trapelato vale finché qualcuno non se ne accorge. Un vault esterno offre credenziali dinamiche a vita breve, così il valore di un furto crolla. Secondo, il perimetro di fiducia. Con i Secret nativi, la tua sorgente di verità per i segreti è il cluster stesso: chiunque comprometta il cluster — o un suo amministratore — ha tutti i segreti. Con un vault esterno il cluster è solo un consumatore, il vault applica le proprie policy di accesso e audit, e puoi revocare l'accesso del cluster senza toccare i segreti. Terzo, la frammentazione. Senza un vault, ogni cluster ha i suoi Secret scollegati; con un vault hai una gestione centralizzata, un audit unico di chi ha letto cosa, e la stessa credenziale non duplicata in dieci posti. Quarto, il GitOps: i Secret nativi ti costringono a scegliere tra non mettere i segreti in git (e perdere la riproducibilità) o committarli in base64 (e bruciarli); External Secrets e Sealed Secrets risolvono esattamente questo. Non sto dicendo che ti serva sempre tutto l'armamentario: per un cluster piccolo, Secret nativi + etcd cifrato + RBAC stretto sono un punto di partenza onesto. Ma la complessità del vault non è gratuita per capriccio: compra rotazione, vita breve, centralizzazione e audit — cioè proprio le proprietà che trasformano "il segreto è protetto se nessuno sbaglia" in "il segreto vale poco anche se qualcosa va storto". La domanda da farsi è quanto vale ciò che quei segreti proteggono.

Conclusione

I Secret di Kubernetes sono un meccanismo di consegna, non una cassaforte: base64 non è cifratura, quindi servono etcd cifrato e RBAC stretto, e per il GitOps o un vault esterno (External Secrets) o la cifratura (Sealed Secrets), montando a runtime via CSI quando possibile. Il passo successivo è smettere di consegnare segreti condivisi e dare a ogni workload la propria identità verificabile, da cui tutto il resto deriva. È l’identità dei workload nella pipeline e nel cluster, prossimo capitolo.

Runtime security: vedere l'attacco mentre accade

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

Perché conta

Ogni controllo visto finora è preventivo: cerca di impedire che un difetto nasca o che un carico non conforme parta. Ma la prevenzione, da sola, è una scommessa che prima o poi si perde: un CVE zero-day, una configurazione sfuggita, una credenziale rubata. La runtime security accetta questa realtà e aggiunge l’altra metà: osservare il comportamento reale dei container in esecuzione e reagire quando qualcosa esce dal normale. Si appoggia a eBPF per vedere nel kernel senza modificare le app.

L’idea: il comportamento atteso

Un container ha un comportamento prevedibile e stretto: un server web ascolta su una porta, legge certi file, parla con certi servizi. Tutto il resto è sospetto.

  flowchart TD
    OBS[eBPF osserva nel kernel:<br/>syscall, exec, rete, file] --> ENG[Motore di regole<br/>Falco]
    ENG --> N{Comportamento<br/>atteso?}
    N -->|sì| OK[Normale]
    N -->|no| AL["ALLERTA:<br/>shell in un container web,<br/>connessione a IP ignoto,<br/>scrittura su /etc"]
    AL --> ACT[Notifica / blocca / isola]
    style AL fill:#fde2e4,stroke:#e63946

A differenza dell’antivirus basato su firme, la runtime security moderna ragiona per comportamento: non “riconosco questo malware”, ma “questo container sta facendo qualcosa che un container di quel tipo non dovrebbe fare”.

Cosa rileva Falco

Falco, lo standard CNCF, osserva le syscall via eBPF e le valuta contro regole. Segnali tipici di compromissione:

Esempi di regole comportamentali:
  - shell avviata dentro un container             ← quasi mai legittimo in prod
  - processo che legge /etc/shadow                ← tentativo di furto credenziali
  - connessione in uscita verso IP non previsto   ← possibile C2 / esfiltrazione
  - scrittura in una directory di sistema         ← tampering del binario
  - montaggio sospetto o accesso al socket Docker  ← tentativo di escape

Molti di questi sono proprio ciò che un’immagine distroless rende impossibile (niente shell) o che l’hardening rende difficile — la prevenzione riduce ciò che Falco deve vedere, e Falco cattura ciò che la prevenzione non ha fermato. Difesa in profondità.

Allertare o bloccare?

Due modalità, con un compromesso:

Detect (allerta): segnala l’anomalia a chi risponde. Nessun rischio di bloccare traffico legittimo, ma richiede qualcuno (o un’automazione) che reagisca in fretta.
Enforce (blocca/isola): ferma il processo o isola il pod automaticamente. Reazione immediata, ma un falso positivo può interrompere un servizio.

La pratica comune: partire in detect per imparare il comportamento normale e tarare le regole, riducendo i falsi positivi, e passare a enforce solo sulle anomalie ad alta confidenza. Le allerte alimentano la detection e il SIEM e innescano la risposta agli incidenti.

Il rumore è il vero nemico

Come ogni detection, la runtime security vive o muore sui falsi positivi. Mille allerte al giorno equivalgono a zero allerte: nessuno le guarda. Il lavoro vero non è installare Falco, è tarare le regole sul comportamento reale dei propri carichi, sopprimere il rumore noto e mantenere solo i segnali azionabili. Una detection ignorata è peggio di nessuna detection, perché dà un falso senso di copertura.

Domanda: se ho già fatto prevenzione seria — immagini distroless, hardening, admission control, network policy — cosa mi aggiunge davvero la runtime security? Non dovrebbe essere già tutto bloccato?

La prevenzione risponde alla domanda "può succedere?" e tu l'hai ridotta tanto; la runtime security risponde a una domanda diversa, "sta succedendo?", e nessuna quantità di prevenzione la rende superflua, per tre ragioni. Primo, la prevenzione ha un orizzonte: conosce i difetti e le configurazioni sbagliate note oggi. Uno zero-day nella tua applicazione, una catena di exploit che nessuna policy prevedeva, una credenziale legittima rubata e usata in modo legittimo-ma-malevolo — tutto questo passa i controlli preventivi proprio perché non viola nessuna regola conosciuta. La runtime security non chiede "questo è permesso?" ma "questo è normale per questo container?", e un comportamento anomalo è anomalo anche se tecnicamente permesso. Secondo, la prevenzione può avere buchi che non sai di avere: una policy di admission con un'eccezione dimenticata, un namespace legacy non ancora hardened, un workload con una deroga temporanea diventata permanente. La runtime security è la rete che vede cosa succede davvero, indipendentemente da cosa credevi di aver bloccato — e spesso è lì che scopri che un controllo preventivo non era attivo dove pensavi. Terzo, e decisivo: la prevenzione non lascia testimonianza. Se un attacco riesce nonostante tutto, senza osservazione a runtime non lo sai — non hai allerta, non hai timeline, non hai le prove per capire cosa è stato toccato. La runtime security è ciò che trasforma una compromissione silenziosa e indefinita in un incidente rilevato, delimitato e investigabile. Il punto non è che la prevenzione sia debole: più è forte, meno rumore deve gestire la detection e più ogni allerta è significativa. I due lavorano insieme — la prevenzione riduce la superficie e il volume, la detection copre l'inevitabile residuo e ti dà occhi su ciò che la prevenzione non ha visto. La sicurezza seria non sceglie tra "impedire" e "rilevare": fa entrambi perché falliscono in modi diversi.

Conclusione

La runtime security accetta che la prevenzione prima o poi ceda: osserva il comportamento reale via eBPF, segnala la shell inattesa e la connessione sospetta, allerta o blocca, e dà la testimonianza che la prevenzione non lascia. Vive e muore sulla taratura dei falsi positivi. Tra i comportamenti più sensibili c’è l’accesso ai segreti: come i container ottengono le credenziali in un cluster, senza lasciarle in chiaro, è il prossimo capitolo.

Admission control: il buttafuori del cluster

Tue, 14 Jul 2026 09:00:00 +0200

Perché conta

L’hardening definisce come dovrebbe girare un pod. Ma chi impedisce che qualcuno applichi comunque un manifest che viola quelle regole? L’admission control è la risposta: il punto, lungo il percorso di ogni richiesta all’API server, in cui si può rifiutare o modificare un oggetto prima che venga persistito e schedulato. È l’ultima porta — e la più efficace, perché agisce su tutto ciò che entra nel cluster, da qualunque fonte.

Dove si inserisce

  flowchart LR
    U[kubectl / CI / operator] -->|crea pod| API[API server]
    API --> AUTH[AuthN/AuthZ<br/>RBAC]
    AUTH --> MUT[Mutating<br/>webhook]
    MUT --> VAL[Validating<br/>webhook<br/>= PEP]
    VAL -->|conforme| ETCD[(etcd → schedulato)]
    VAL -.non conforme.-> REJ[RIFIUTATO<br/>con motivazione]
    style VAL fill:#fde2e4,stroke:#e63946

Dopo l’autenticazione e RBAC, la richiesta passa da due tipi di webhook:

Mutating: modifica l’oggetto. Es. inietta automaticamente un security context sicuro, aggiunge label, imposta limiti di risorse di default.
Validating: accetta o rifiuta. È il PEP del cluster: valuta l’oggetto contro le policy e, se viola, lo blocca con un messaggio.

Cosa si applica qui

L’admission control è dove le promesse dei capitoli precedenti diventano enforcement reale:

Rifiuta se:
  - immagine NON firmata da identità attesa   (verifica Sigstore/cosign)
  - immagine con CVE critici o senza SBOM
  - container privilegiato / runAsRoot / hostPath pericolosi
  - manca il limite di risorse, usa tag :latest, namespace sbagliato
Muta per imposizione:
  - aggiungi securityContext sicuro di default, label owner, networkpolicy

La verifica della firma è l’esempio più nitido: la firma diventa un controllo d’accesso solo quando un validating webhook la verifica e rifiuta ciò che non proviene dall’identità attesa. Senza admission control, firmare è teatro.

Kyverno e OPA Gatekeeper

Due approcci allo stesso ruolo di PEP:

Kyverno: le policy sono risorse Kubernetes in YAML, native per chi già conosce i manifest. Nessun linguaggio nuovo da imparare; fa anche mutazione e generazione di risorse.
OPA Gatekeeper: porta OPA e Rego nel cluster. Più potente ed espressivo, a costo di imparare Rego, e con il vantaggio di condividere lo stesso linguaggio di policy tra pipeline e cluster.

Pipeline e cluster: due reti, non una

L’admission control e il controllo in pipeline si rafforzano a vicenda. La pipeline cattura presto e dà feedback allo sviluppatore (shift-left); l’admission control cattura tutto ciò che arriva all’API, incluso ciò che bypassa la pipeline — un kubectl apply manuale, un operator, un attaccante con credenziali. Fare entrambi significa feedback precoce e enforcement inaggirabile.

Domanda: se già controllo tutto in pipeline — scansione immagini, firma, policy Rego — perché aggiungere l'admission control nel cluster? Non è controllare due volte la stessa cosa?

È controllare la stessa regola in due punti con garanzie diverse, e la differenza è tutta in ciò che ciascun punto può garantire. La pipeline ha un presupposto fatale come unico controllo: che ogni cosa che arriva nel cluster sia passata dalla pipeline. Nella realtà non è così. Un operatore sotto incidente fa un kubectl apply a mano per "sistemare al volo"; un operator o un controller crea pod dinamicamente senza passare da nessuna CI; un Helm chart di terze parti installa risorse che la tua pipeline non ha mai visto; un attaccante che ha ottenuto credenziali valide parla direttamente con l'API server — e nessuno di questi percorsi tocca la pipeline. Tutto ciò che la pipeline verifica diventa irrilevante per qualunque oggetto che entra da una porta diversa. L'admission control chiude proprio questo: sta sull'API server, quindi vede ogni richiesta di creazione o modifica, da qualunque fonte, e applica la policy lì, nell'unico collo di bottiglia che nessuno può aggirare senza compromettere l'API stessa. Questo non rende inutile la pipeline, anzi: i due hanno scopi complementari. La pipeline è veloce, dà feedback allo sviluppatore riga per riga sulla pull request, fa fallire la build quando il contesto è fresco — è prevenzione e insegnamento (shift-left). L'admission control è tardivo e muto per lo sviluppatore ma inaggirabile — è enforcement. Il modello corretto è lo stesso principio ("solo immagini firmate") espresso una volta e applicato in due punti: in pipeline per fermare presto e bene, all'ammissione per fermare comunque. Togliere la pipeline ti lascia l'enforcement senza feedback precoce; togliere l'admission control ti lascia il feedback con un enforcement pieno di buchi. Li vuoi entrambi perché difendono da fallimenti diversi.

Conclusione

L’admission control è il buttafuori del cluster: mutating webhook che impongono default sicuri, validating webhook che rifiutano ciò che viola le policy — immagini non firmate, container privilegiati, configurazioni fuori norma. È dove firma e policy diventano enforcement inaggirabile, a complemento della pipeline. Ma tutti i controlli visti finora sono preventivi: agiscono prima che il codice giri. Qualcosa passerà comunque, e allora serve vedere e reagire a ciò che accade mentre succede. È la runtime security, prossimo capitolo.

Hardening di Kubernetes

Tue, 07 Jul 2026 09:00:00 +0200

Perché conta

Abbiamo immagini minimali; ora girano in un cluster. E un cluster Kubernetes di default è progettato per funzionare facilmente, non per essere sicuro: permessi ampi, nessuna restrizione di rete, pod che possono girare come root. L’hardening è il lavoro di restringere questi default senza rompere i carichi. Si appoggia al modello di rete di Kubernetes già visto, e ne chiude i margini.

Le quattro leve principali

  flowchart TD
    RBAC[RBAC<br/>chi può fare cosa<br/>sull'API] 
    SC[Security Context<br/>come gira il pod]
    NP[Network Policy<br/>chi parla con chi]
    PSS[Pod Security<br/>Standards<br/>cosa è ammesso]
    RBAC --- SC --- NP --- PSS --- RBAC
    style RBAC fill:#fde2e4,stroke:#e63946

1. RBAC a privilegio minimo

Il controllo d’accesso all’API è la prima linea. L’errore classico è concedere cluster-admin “per non avere problemi”. Ogni ServiceAccount e ogni utente deve potere solo ciò che serve. Attenzione speciale ai permessi che consentono l’escalation: creare pod, leggere i secret, modificare i RoleBinding sono poteri che equivalgono quasi al controllo del cluster.

2. Security context del pod

Come abbiamo indurito l’immagine, induriamo l’esecuzione:

securityContext:
  runAsNonRoot: true            # mai root nel container
  readOnlyRootFilesystem: true  # niente scrittura sul filesystem del container
  allowPrivilegeEscalation: false
  capabilities: { drop: ["ALL"] }  # togli tutte le capability Linux, riaggiungi solo il minimo

Queste quattro righe eliminano le vie più comuni di escape e di movimento. Un container che non può diventare root, non può scrivere su disco e non ha capability è molto meno utile a un attaccante.

3. Network policy di default-deny

Di default, in Kubernetes ogni pod parla con ogni pod. È l’opposto dello Zero Trust. Una microsegmentazione con network policy di default-deny chiude tutto il traffico est-ovest e riapre solo i flussi necessari. Così un pod compromesso non può raggiungere liberamente il resto del cluster.

4. Pod Security Standards

I Pod Security Standards (Restricted, Baseline, Privileged) definiscono cosa un pod può chiedere. Applicati a livello di namespace tramite il Pod Security Admission, impediscono che venga schedulato un pod privilegiato o con host mount pericolosi — un controllo all’ammissione, che è il ponte verso il prossimo capitolo.

L’isolamento dei nodi e il resto

Oltre ai pod: proteggere l’accesso all’etcd (contiene tutti i segreti del cluster, in chiaro se non cifrato a riposo), limitare l’accesso all’API server, isolare i nodi, e trattare i carichi multi-tenant con namespace separati e, per i casi più sensibili, sandbox di runtime (gVisor, Kata). L’hardening non è una checklist una tantum: è un confronto periodico con il CIS Benchmark.

Domanda: se applico RBAC stretto, readOnlyRootFilesystem, drop di tutte le capability e default-deny di rete, non rischio di rompere metà dei miei workload che oggi funzionano?

Il rischio di rottura è reale, ma rivela una verità scomoda: se un workload smette di funzionare quando gli togli root, la scrittura sul filesystem, le capability e la rete libera, vuol dire che oggi sta usando privilegi che non dovrebbe avere, e quello è precisamente il problema di sicurezza che stai cercando di chiudere. L'hardening non va fatto a martellate su tutto il cluster in un giorno, va fatto come una migrazione guidata. Prima osservi: molti di questi controlli hanno una modalità non bloccante — i Pod Security Standards si applicano per namespace con livelli warn e audit prima di enforce, così vedi quali pod violerebbero la policy senza fermarli; per le network policy usi strumenti che registrano il traffico reale prima di passare al default-deny, così sai quali flussi riaprire. Poi correggi alla fonte: un'app che vuole scrivere lo fa su un volume emptyDir montato apposta, non sul root filesystem; una che crede di aver bisogno di root quasi sempre non ne ha bisogno davvero una volta sistemati i permessi dei file; le capability si riaggiungono una per una, solo quelle effettivamente necessarie (spesso zero). Poi procedi per gradi: un namespace non critico prima, i default stretti sui nuovi workload subito (è molto più facile nascere conformi che diventarlo), e i workload legacy migrati uno alla volta con una deroga tracciata dove serve tempo. Infine, imposti i default sicuri a livello di piattaforma, così il prossimo team parte già hardened senza doverci pensare. Il punto è che la rottura non è un effetto collaterale dell'hardening: è la diagnosi. Ti dice esattamente dove i tuoi workload sono sovra-privilegiati, che è l'informazione che ti serviva per renderli difendibili.

Conclusione

Un cluster sicuro è un cluster ristretto: RBAC a privilegio minimo, security context che impediscono root e scrittura, network policy di default-deny, Pod Security Standards per namespace, più etcd cifrato e API protetta. Molti di questi controlli si fanno rispettare al momento dell’ammissione di un pod — il meccanismo che permette di dire “no” prima ancora che qualcosa parta. È l’admission control, prossimo capitolo.

Sicurezza delle immagini container

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

Perché conta

Gli artefatti verificabili dei capitoli precedenti, nel mondo cloud-native, sono quasi sempre immagini container. E un’immagine non è solo la tua app: è la tua app più un sistema operativo, librerie, utility. Ogni pacchetto incluso è codice che può avere vulnerabilità e che un attaccante può sfruttare una volta dentro. La regola guida è semplice: meno c’è nell’immagine, meno c’è da attaccare. Questo poggia sul modello di networking dei container già visto; qui ci concentriamo sull’immagine come superficie.

Il peso dell’immagine di base

  flowchart TD
    A["FROM ubuntu<br/>~400 pacchetti, shell,<br/>package manager"] --> A1[Grande superficie:<br/>molti CVE, strumenti<br/>utili all'attaccante]
    B["FROM distroless/static<br/>solo libc + la tua app"] --> B1[Superficie minima:<br/>niente shell,<br/>pochi/zero CVE OS]
    style A1 fill:#fde2e4,stroke:#e63946
    style B1 fill:#e8f0fe,stroke:#4361ee

Un’immagine basata su una distribuzione completa porta centinaia di pacchetti che l’app non usa — ma che l’attaccante sì: una shell per muoversi, curl per scaricare payload, un package manager per installare strumenti. Un’immagine distroless (o scratch per i binari statici) contiene solo l’app e lo stretto indispensabile: niente shell significa niente kubectl exec in una shell, molto meno con cui lavorare dopo una compromissione.

Il multi-stage build

Lo strumento che rende tutto questo pratico: compilare in un’immagine ricca, spedire in una minimale.

# stage di build: ha compilatore, strumenti, dipendenze di sviluppo
FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

# stage finale: SOLO il binario, su base minimale, utente non-root
FROM gcr.io/distroless/static:nonroot
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]

Le righe evidenziate sono il punto: gli strumenti di build restano nello stage build e non arrivano in produzione; l’immagine finale ha solo il binario, gira come utente non-root, e non ha né shell né package manager da sfruttare.

Scansione delle vulnerabilità dell’immagine

Oltre a minimizzare, si scansiona. Uno scanner (Trivy, Grype) ispeziona i layer e trova i CVE nei pacchetti OS e nelle dipendenze applicative — è la SCA applicata all’immagine assemblata, non solo al manifest. Si colloca:

In pipeline, come gate dopo la build: blocca il nuovo rischio critico.
Nel registry, in continuo: un CVE nuovo può colpire un’immagine già pubblicata, come per la SBOM.

Le altre regole d’oro

USER non-root        → mai processi come root nel container
tag immutabili       → riferire per digest (sha256), non per :latest mutabile
niente segreti       → mai chiavi nei layer (restano nella history dell'immagine!)
filesystem read-only → l'app non deve scrivere sulla propria immagine
.dockerignore        → non copiare .git, .env, chiavi nel contesto di build

Nota il parallelo con i segreti: un segreto copiato in un layer resta nell’immagine per sempre, come nella history di Git. L’immagine va trattata con la stessa cautela del repository.

Domanda: le immagini distroless senza shell non rendono un incubo il debug in produzione? Quando qualcosa va storto non posso nemmeno aprire una shell nel container.

È lo scambio reale, e la risposta è che la cosa che rende il debug scomodo per te è esattamente ciò che rende la vita difficile all'attaccante — ma oggi non devi più scegliere tra le due. Partiamo dal perché l'assenza di shell è un bene: la stragrande maggioranza delle tecniche post-exploitation presuppone di avere, dentro il container, una shell per esplorare, `curl`/`wget` per scaricare lo stadio successivo, un package manager per installare strumenti. Toglierli non ferma un attaccante determinato, ma alza nettamente il costo e il rumore di ogni suo movimento, e neutralizza del tutto gli automatismi che contano sulla presenza di `/bin/sh`. Rinunciarci per comodità di debug significa lasciare armi in casa. Detto questo, il debug non è compromesso: i runtime moderni offrono i debug container effimeri (in Kubernetes kubectl debug con ephemeral containers), che attaccano un container temporaneo pieno di strumenti al pod in esecuzione, condividendone namespace e filesystem, senza che quegli strumenti vivano mai nell'immagine di produzione. Hai la shell quando ti serve, dove ti serve, e sparisce quando hai finito — l'immagine resta minimale. In aggiunta, la disciplina distroless spinge verso un debug migliore a monte: logging strutturato, metriche ed endpoint di health invece dell'ispezione manuale via shell, che è comunque il modo in cui si opera un sistema a scala. Quindi: sì, cambi abitudine, ma non perdi capacità — sposti gli strumenti di debug fuori dall'immagine e li porti dentro solo quando servono, ottenendo insieme operabilità e una superficie d'attacco minima.

Conclusione

Un’immagine sicura è piccola per principio: distroless o scratch via multi-stage build, utente non-root, niente segreti nei layer, riferita per digest, scansionata in pipeline e nel registry. Meno contiene, meno offre all’attaccante. Ma l’immagine è solo metà della storia: una volta in esecuzione nel cluster, conta come gira. L’hardening di Kubernetes, prossimo capitolo.

Policy as code nella pipeline

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

Perché conta

Lo scanning dell’IaC applica regole predefinite. Ma ogni organizzazione ha regole proprie: “solo immagini da registry approvati”, “ogni risorsa deve avere un tag owner”, “niente security group aperti al mondo in produzione”. Scritte in una wiki, queste regole non si applicano da sole: si violano per distrazione o per fretta. Il policy as code le trasforma in codice versionato, testabile e applicato automaticamente. È il tema generale di cui avevamo già parlato con OPA; qui lo mettiamo al lavoro nella pipeline.

Il pattern PDP/PEP, di nuovo

Il policy as code è lo stesso schema PDP/PEP dello Zero Trust, applicato agli artefatti e alle configurazioni invece che agli accessi di rete:

  flowchart LR
    CI[Step pipeline<br/>PEP] -->|"questo manifest/<br/>immagine è conforme?"| OPA[OPA<br/>PDP]
    POL[(Policy in Rego<br/>versionate in git)] --> OPA
    OPA -->|consenti / nega<br/>+ motivazione| CI
    CI -->|se nega| STOP[Build fallita<br/>con messaggio chiaro]
    style OPA fill:#fde2e4,stroke:#e63946

La pipeline è il PEP (chiede e applica); OPA è il PDP (decide in base alle policy). Le policy vivono in git: revisionate con pull request, testate, con una history di chi le ha cambiate e perché.

Rego: la regola come codice

OPA usa Rego, un linguaggio dichiarativo. Una policy nega finché una condizione non è soddisfatta:

package pipeline

# nega qualunque immagine non firmata o da registry non approvato
deny[msg] {
  not input.image.signed
  msg := sprintf("immagine %v non firmata", [input.image.ref])
}

Il risultato non è un booleano muto ma un messaggio azionabile: lo sviluppatore legge perché la build è fallita e come rimediare. Questo distingue un guardrail utile da un cancello frustrante.

Cosa si esprime come policy

Sugli artefatti: solo immagini firmate (Sigstore), con SBOM presente, senza CVE critici, da basi approvate.
Sui manifest Kubernetes: niente container privilegiati, niente latest, limiti di risorse obbligatori, nessun segreto in chiaro.
Sull’IaC: le regole su misura che lo scanner generico non conosce (le tue convenzioni di tag, di naming, di rete).

Strumenti come Conftest valutano file di configurazione (YAML, JSON, HCL, Dockerfile) contro policy Rego direttamente in pipeline, con un comando.

Testare le policy

Il vantaggio decisivo del policy as code è che le policy stesse sono testabili. Si scrivono casi — “questo manifest deve passare”, “quest’altro deve essere rifiutato” — e si eseguono in CI. Una policy senza test è fragile quanto codice senza test: può diventare troppo permissiva senza che nessuno se ne accorga.

Un motore, molti punti di applicazione

La stessa policy (“solo immagini firmate”) può valere nella pipeline e all’ingresso del cluster via admission control. Un solo linguaggio, un solo repository di regole, più punti di enforcement: è la coerenza che rende governabile la sicurezza su scala, invece di regole scollegate ripetute in dieci posti.

Domanda: se la policy as code può bloccare le build, chi impedisce che una regola troppo severa (o un bug in una policy) fermi tutti i deploy dell'azienda?

È un rischio concreto — una policy è codice con potere di veto sulla consegna — e si gestisce con le stesse pratiche che rendono sicuro qualunque altro codice critico, più alcune specifiche. Primo: le policy si trattano come software, non come configurazione sacra. Vivono in git, passano da pull request con revisione, e hanno test propri: casi che devono passare e casi che devono essere rifiutati, eseguiti in CI a ogni modifica della policy stessa. Una regola troppo severa si manifesta come un test rosso prima di arrivare in produzione, esattamente come una regressione in un servizio. Secondo: le policy si rilasciano in modo graduale. Una regola nuova parte in modalità warn (segnala ma non blocca), si osserva quanto e cosa catturerebbe sui deploy reali per un periodo, e solo quando i falsi positivi sono sotto controllo si promuove a enforce. Questo evita il blocco a sorpresa dell'intera azienda al primo giorno. Terzo: serve una via di emergenza esplicita e tracciata — un meccanismo di eccezione o di break-glass che permetta, con approvazione e audit, di scavalcare una policy quando è palesemente lei a sbagliare durante un incidente, invece di lasciare l'unica scelta tra "bloccati tutti" e "disattiviamo tutto". Quarto, la scelta del comportamento di default per fase: in pipeline spesso conviene fail-closed sulle regole di sicurezza critiche (meglio una build bloccata che un'immagine non firmata in produzione), ma la decisione va presa consapevolmente regola per regola, non subita. Il punto di fondo: il potere di bloccare è esattamente ciò che rende la policy utile — una regola che non può fermare nulla non è un controllo, è un suggerimento — quindi la risposta non è togliere il potere, è circondarlo di test, rollout graduale e vie di fuga, come si fa con ogni cosa che può rompere la produzione.

Conclusione

Il policy as code trasforma le regole dell’organizzazione in codice versionato, testato e applicato: lo schema PDP/PEP portato nella pipeline, con messaggi azionabili e un solo repository di regole per più punti di enforcement. Abbiamo blindato codice, artefatti e pipeline. Ora quegli artefatti devono girare, e il primo è quasi sempre un container: la sicurezza delle immagini, prossimo capitolo.

Sicurezza dell'Infrastructure as Code

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

Perché conta

La pipeline non costruisce solo applicazioni: costruisce anche l’infrastruttura, ormai definita come codice — Terraform, CloudFormation, Pulumi, manifest Kubernetes. È una grande notizia per la sicurezza: se l’infrastruttura è codice, possiamo analizzarla come codice, prima del deploy. È anche un rischio nuovo: un errore in un modulo riusato si replica identico su ogni ambiente, trasformando un singolo sbaglio in una falla sistemica.

L’errore si moltiplica

  flowchart TD
    M["modulo-storage.tf<br/>(acl = public-read)"] --> A[Ambiente dev]
    M --> B[Ambiente staging]
    M --> C[Ambiente prod]
    A --> X1[Bucket pubblico]
    B --> X2[Bucket pubblico]
    C --> X3[Bucket pubblico<br/>con dati reali]
    style X3 fill:#fde2e4,stroke:#e63946

Un bucket reso pubblico in un modulo condiviso diventa tre bucket pubblici. Il lato positivo è speculare: correggere il modulo e ripassare lo scanner mette in sicurezza tutti gli ambienti in un colpo. L’IaC amplifica sia gli errori sia le correzioni.

Cosa trova lo scanning dell’IaC

Gli scanner statici (Checkov, tfsec, Terrascan, KICS) applicano centinaia di regole, spesso allineate ai CIS Benchmark, cercando le configurazioni pericolose più comuni:

resource "aws_s3_bucket_public_access_block" "ex" {
  bucket                  = aws_s3_bucket.ex.id
  block_public_acls       = false   # ← lo scanner segnala: accesso pubblico possibile
  restrict_public_buckets = false   # ← idem
}

Difetti tipici: storage pubblico, security group con 0.0.0.0/0 su porte di gestione, cifratura a riposo disattivata, log disabilitati, ruoli IAM troppo ampi, assenza di tag. Sono misconfiguration, non bug di codice: il SAST non le vede, perché il “codice” qui descrive infrastruttura, non logica.

Dove collocarlo

Come il SAST, l’IaC scanning dà il meglio presto e in modo incrementale:

Pre-commit / IDE: feedback immediato mentre si scrive il Terraform.
Pull request: gate che blocca il nuovo rischio alto, con baseline sul debito esistente.
Pre-apply nella pipeline: ultimo controllo prima di toccare l’infrastruttura reale, idealmente anche sul piano (terraform plan) per vedere l’effetto concreto, non solo il sorgente.

Il problema spesso dimenticato: lo state

Il file di state di Terraform contiene spesso dati sensibili in chiaro: password generate, chiavi, output. Va trattato come un segreto: backend remoto cifrato, accesso ristretto, mai committato nel repository. È l’errore IaC meno appariscente e più comune, perché non riguarda una risorsa ma il meccanismo stesso che le gestisce.

Il limite: lo statico non vede il reale

Lo scanning dell’IaC vede ciò che il codice dichiara, non ciò che esiste davvero nel cloud. Le modifiche manuali (il famigerato “clic in console”) creano drift: la realtà diverge dal codice, e lo scanner, che legge solo il codice, non se ne accorge. Servono controlli a runtime sul cloud (CSPM) e la disciplina di non modificare mai l’infrastruttura fuori dall’IaC. Il “cosa è dichiarato pericoloso” è però esprimibile come regola generale, e questo apre il tema del prossimo capitolo: le policy as code.

Domanda: se lo scanner IaC non vede il drift e le modifiche manuali, posso fidarmi che un "piano pulito" significhi infrastruttura sicura?

No, e confondere le due cose è una delle illusioni di sicurezza più comuni con l'IaC. Uno scanner che passa sul tuo Terraform dimostra una cosa precisa e limitata: che ciò che il codice descrive non contiene le misconfigurazioni note alle sue regole. Non dimostra che l'infrastruttura reale sia in quello stato, per tre motivi. Primo, il drift: qualcuno apre la console cloud e modifica a mano un security group per "sbloccare al volo" un incidente, e non lo riporta mai nel codice; il tuo Terraform resta pulito, il cloud no, e il prossimo apply potrebbe persino non toccare quella risorsa. Secondo, la copertura: quasi nessuna infrastruttura è gestita al 100% da IaC — ci sono risorse create prima dell'adozione, risorse di altri team, cose fatte a mano "temporaneamente" tre anni fa; tutto ciò che non è nel codice è invisibile allo scanner per definizione. Terzo, le regole hanno punti ciechi: lo scanner trova le misconfigurazioni che conosce, non la logica di autorizzazione sbagliata o la combinazione insolita di risorse che crea un percorso d'attacco non previsto da nessuna singola regola. La risposta corretta è usare due lenti complementari: lo scanning statico dell'IaC come controllo preventivo sul codice prima del deploy (economico, precoce, ferma l'errore prima che esista), e un controllo a runtime sul cloud reale — un CSPM che interroga le API del provider e confronta lo stato effettivo con le policy — come rete che cattura drift, risorse fuori IaC e deviazioni. Più la disciplina organizzativa di vietare le modifiche manuali e far passare ogni cambiamento dall'IaC, così il drift tende a zero. Un piano pulito è una condizione necessaria, non sufficiente: ti dice che non stai introducendo un problema noto, non che non ne hai già uno in produzione.

Conclusione

L’IaC rende l’infrastruttura analizzabile prima del deploy: gli scanner trovano bucket pubblici, security group aperti e cifratura mancante, e una correzione al modulo mette in sicurezza ogni ambiente. Ma lo statico non vede il drift, e le regole predefinite non conoscono le tue policy. Per esprimere ed applicare regole su misura — nella pipeline e nel cluster — serve un motore di policy generale. È il policy as code, 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.

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.

Fuzzing: trovare i bug che non hai immaginato

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

Perché conta

Ogni controllo visto finora — SAST, DAST, IAST — cerca problemi che sappiamo descrivere. I test unitari verificano i casi che immaginiamo. Ma gli attaccanti vivono nei casi che non abbiamo immaginato: l’input malformato, la lunghezza assurda, la sequenza impossibile. Il fuzzing esplora proprio quello spazio, generando input anomali a milioni e osservando cosa rompe.

Dall’input casuale alla copertura guidata

Il fuzzing ingenuo lancia byte casuali e spera in un crash: inefficiente, perché quasi tutti gli input vengono rifiutati subito dal parsing. Il salto di qualità è il coverage-guided fuzzing: il fuzzer osserva quali rami di codice ogni input attiva e tiene gli input che esplorano codice nuovo, mutandoli per andare più in profondità.

  flowchart LR
    SEED[Corpus iniziale<br/>input validi] --> MUT[Muta l'input<br/>bit flip, splice]
    MUT --> RUN[Esegue la funzione<br/>sotto test]
    RUN --> COV{Copre codice<br/>nuovo?}
    COV -->|sì| KEEP[Aggiungi al corpus<br/>→ base per altre mutazioni]
    COV -->|no| DROP[Scarta]
    RUN -->|crash / hang| BUG[Salva l'input:<br/>bug riproducibile]
    KEEP --> MUT
    style BUG fill:#fde2e4,stroke:#e63946

Guidato dalla copertura, il fuzzer “impara” a superare i controlli di validazione e a penetrare in profondità nel codice, trovando in ore ciò che input casuali non troverebbero in anni.

Cosa trova

Il fuzzing eccelle sul codice che interpreta input non fidati: parser, decoder, deserializzatori, protocolli di rete, elaborazione di file. Scopre:

Crash: dereferenze null, buffer overflow (in C/C++), eccezioni non gestite.
Corruzioni di memoria: potenti vettori di exploit, rilevate se si combina il fuzzing con i sanitizer (ASan, UBSan) che rendono visibile una corruzione altrimenti silenziosa.
Hang e consumo di risorse: input che mandano l’app in loop o esauriscono la memoria (DoS).

Il fuzz target

Il cuore pratico è scrivere una piccola funzione che riceve i byte del fuzzer e li passa al codice da testare:

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // il fuzzer fornisce 'data'; noi lo passiamo al parser sotto test
    parse_config(data, size);   // ← se crasha, abbiamo un bug riproducibile
    return 0;
}

La riga evidenziata è tutto: dai l’input non fidato alla funzione critica e lasci che il fuzzer trovi l’input che la rompe. Lo stesso pattern esiste per i linguaggi gestiti (Go testing.F, Jazzer per la JVM, Atheris per Python).

Continuo, non una tantum

Il fuzzing dà di più col tempo: più gira, più in profondità arriva. Per questo in DevSecOps è continuo — gira in background su un corpus che cresce, non in un singolo passaggio di pipeline che deve finire in cinque minuti. Progetti come OSS-Fuzz dimostrano il modello: fuzzing 24/7, con i bug che aprono automaticamente ticket. Nella CI si esegue un fuzzing breve di regressione sul corpus noto (per non reintrodurre crash già risolti) e si lascia il fuzzing profondo all’infrastruttura dedicata.

Domanda: il fuzzing sembra utile solo per codice in C/C++ che fa parsing di basso livello; ha senso per una tipica app web in un linguaggio gestito?

Ha senso, ma cambia cosa trova e dove conviene puntarlo. È vero che il raccolto più ricco del fuzzing — corruzioni di memoria sfruttabili — vive in C/C++, dove un buffer overflow diventa un exploit; in un linguaggio gestito la memoria è protetta dal runtime, quindi quella classe sparisce. Ma non sparisce il resto: eccezioni non gestite che diventano DoS o errori 500 informativi, loop e allocazioni che esauriscono le risorse (una "zip bomb" o un input che fa esplodere un parser in tempo quadratico), bug logici nei deserializzatori, differenze di parsing tra due librerie che portano a confusione di tipo o a bypass di validazione. E soprattutto conta dove lo punti: non sulla logica di business, ma su ogni punto in cui l'app ingoia input non fidato e lo struttura — l'endpoint che accetta JSON o XML, il decoder di immagini, il parser di un formato proprietario, il layer che gestisce upload di file. Lì il fuzzing coverage-guided trova casi limite che nessun test scritto a mano copre, perché nessuno pensa a un JSON annidato diecimila livelli o a un campo numerico con un valore che fa overflow in una conversione. In più le dipendenze native sotto a un'app gestita (una libreria di compressione, un codec) sono spesso C/C++ sotto mentite spoglie, e lì il raccolto classico torna. La regola pratica: se un componente parsa qualcosa che arriva dall'esterno, è un candidato al fuzzing, qualunque sia il linguaggio.

Conclusione

Il fuzzing esplora lo spazio degli input che non abbiamo immaginato; guidato dalla copertura, impara a penetrare in profondità e trova crash e corruzioni riproducibili, specie nei parser di input non fidato. È continuo per natura. Con questo chiudiamo i controlli sul codice e sul comportamento. Ma il software che spediamo non è solo codice: è un artefatto costruito da una catena di strumenti, e di quella catena dobbiamo poterci fidare. Comincia la parte sulla supply chain, con l’inventario di ciò che spediamo: la SBOM, prossimo capitolo.

IAST e RASP: sicurezza dall'interno

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

Perché conta

Il SAST vede il codice ma non il runtime; il DAST vede il runtime ma non il codice. IAST e RASP colmano il divario strumentando l’applicazione dall’interno: un agent gira dentro il processo, osserva il flusso reale dei dati nel codice mentre l’app riceve richieste vere. Uniscono la localizzazione precisa del SAST al realismo del DAST.

IAST: osservare durante i test

L’IAST (Interactive AST) è un agent attivo durante i test (funzionali, DAST, QA). Mentre il traffico di test attraversa l’app, l’agent vede dall’interno se un input contaminato raggiunge un sink pericoloso — ma stavolta nel codice reale in esecuzione, non per inferenza.

  flowchart LR
    T[Test / DAST<br/>generano traffico] --> APP
    subgraph APP[App strumentata]
        AG[Agent IAST<br/>osserva dall'interno]
    end
    APP --> AG
    AG --> F["Finding preciso:<br/>riga + percorso dati<br/>+ richiesta che l'ha innescato"]
    style F fill:#fde2e4,stroke:#e63946

Il risultato è il meglio dei due mondi: pochi falsi positivi (l’ha visto accadere) e localizzazione esatta (riga di codice, non solo URL). Lo svantaggio: copre solo ciò che i test esercitano — se non c’è traffico di test su un percorso, l’IAST non vede nulla lì.

RASP: difendere in produzione

Il RASP (Runtime Application Self-Protection) è lo stesso principio spostato in produzione e con un ruolo diverso: non osservare, ma bloccare. L’agent, dentro l’app, intercetta le operazioni pericolose a runtime e le ferma quando vede uno sfruttamento in corso.

Richiesta → entra nell'app → RASP osserva l'operazione reale
  query SQL che contiene la struttura di un'injection?   → blocca
  tentativo di leggere /etc/passwd via path traversal?   → blocca
  → decide sul COMPORTAMENTO reale, non su firme di pattern come un WAF

La differenza con un WAF: il WAF sta fuori e indovina dalle richieste; il RASP sta dentro e vede cosa l’app sta effettivamente per fare con quell’input. Meno falsi positivi, ma al prezzo di vivere nel processo.

Il costo: prestazioni e accoppiamento

Niente è gratis. Un agent nel processo aggiunge overhead (CPU, latenza) e si accoppia al runtime specifico (JVM, .NET, Node): va mantenuto, aggiornato, testato a ogni upgrade del linguaggio. Il RASP in produzione aggiunge anche un rischio di stabilità: un agent difettoso può degradare o far cadere l’app che dovrebbe proteggere. Per questo non sono controlli “di default” ma scelte mirate, su applicazioni ad alto valore dove il beneficio giustifica il peso.

Domanda: se il RASP vede e blocca gli attacchi dall'interno dell'app, non rende superflui WAF, SAST e DAST?

No, e pensarlo porta a un unico punto di difesa, che è l'opposto della sicurezza a strati. Il RASP ha un difetto strutturale che gli altri controlli non hanno: protegge l'app solo se l'attacco arriva fino all'app, e lo fa consumando risorse dell'app stessa. Un WAF davanti assorbe il rumore di fondo — le scansioni automatiche, i payload banali, i picchi volumetrici — prima che tocchino il processo, così il RASP si occupa solo di ciò che passa; toglierlo significa far arrivare ogni tentativo fin dentro la JVM. Il SAST e il DAST agiscono prima del rilascio: il loro scopo è che la vulnerabilità non esista in produzione, non difenderla una volta che c'è. Affidarsi al solo RASP equivale a dire "lasciamo pure i difetti nel codice, tanto li blocca a runtime" — ma il RASP può fallire, può essere aggirato, può essere disattivato per un problema di prestazioni, e nel frattempo la falla è lì. C'è anche il rischio di stabilità già citato: il RASP vive nel processo, un suo bug degrada l'app. Il modello corretto è difesa in profondità: eliminare i difetti a sinistra con SAST/DAST, filtrare il grosso con il WAF, e tenere il RASP come ultima rete interna per lo sfruttamento che supera tutto il resto — non come sostituto di nessuno di essi.

Conclusione

IAST e RASP strumentano l’app dall’interno: l’IAST unisce precisione e realismo durante i test, il RASP blocca lo sfruttamento in produzione. Pagano in prestazioni e accoppiamento, quindi si scelgono per i servizi ad alto valore, non ovunque. Finora abbiamo testato ciò che immaginiamo possa andare storto; manca un metodo per scoprire i difetti che non abbiamo immaginato, bombardando l’app di input imprevisti. È il fuzzing, prossimo capitolo.

DAST: testare l'applicazione viva

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

Perché conta

Il SAST e la SCA guardano il codice fermo. Ma un’applicazione in esecuzione è più della somma del suo sorgente: ha una configurazione, un web server, header HTTP, sessioni, un ambiente. Il DAST (Dynamic Application Security Testing) la testa viva, attaccandola dall’esterno come farebbe un avversario, senza vedere il codice. Trova ciò che esiste solo a runtime.

Black box: la prospettiva dell’attaccante

Il DAST non sa nulla del codice: manda richieste, osserva le risposte, deduce.

  flowchart LR
    Z[Scanner DAST] -->|crawl: scopre<br/>URL e form| APP[App in esecuzione<br/>staging]
    Z -->|payload malevoli:<br/>', < script >, ../| APP
    APP -->|risposte,<br/>codici, errori| Z
    Z --> R[Report:<br/>XSS, injection,<br/>header mancanti,<br/>config errata]
    style R fill:#fde2e4,stroke:#e63946

Prima esplora (crawl) per scoprire URL, parametri e form; poi attacca iniettando payload e osservando se l’app reagisce in modo rivelatore. Trova:

Configurazioni errate: header di sicurezza assenti, cookie senza flag, pagine di errore troppo verbose, metodi HTTP pericolosi abilitati.
Vulnerabilità confermate a runtime: una XSS che si attiva davvero, un’injection che restituisce dati, un redirect aperto.
Problemi di sessione e autenticazione osservabili dall’esterno.

Il vantaggio: pochi falsi positivi

Dove il SAST dice “questo potrebbe essere sfruttabile”, il DAST spesso dimostra lo sfruttamento: ha inviato il payload e ha visto la risposta. Un finding DAST confermato è quasi sempre reale, perché riproduce l’attacco. Questo lo rende prezioso come controprova dei sospetti del SAST.

I limiti, da conoscere

Limiti strutturali del DAST:
  - Copertura parziale: testa solo i percorsi che riesce a RAGGIUNGERE
  - Lento: una scansione completa può durare ore
  - Non localizza: dice "c'è una XSS qui", non "riga 42 del file X"
  - Richiede un ambiente in esecuzione, simile a produzione

La copertura è il limite più sottile: se lo scanner non riesce a navigare un flusso complesso (un wizard multi-step, un’area dietro login), non lo testa. Per questo si fornisce al DAST l’autenticazione e, idealmente, la mappa degli endpoint (una definizione OpenAPI), così attacca anche le API, non solo le pagine che riesce a cliccare.

Nel flusso di lavoro

La lentezza impone una collocazione diversa dal SAST:

Scansione “baseline” veloce su ogni deploy in staging: pochi minuti, solo i controlli passivi e rapidi, come gate leggero.
Scansione completa notturna o settimanale, fuori dal percorso critico della pipeline.
Mai in produzione senza cautela: il DAST invia payload reali; girarlo su produzione può creare dati spazzatura o, peggio, innescare azioni. Si usa uno staging fedele.

Domanda: se il DAST trova vulnerabilità confermate e con pochi falsi positivi, non è semplicemente migliore del SAST? Perché tenere entrambi?

"Migliore" dipende da cosa misuri, e sulle due metriche che contano di più i due si invertono. Il DAST vince su precisione (i suoi finding sono spesso dimostrati) e su realismo (vede l'app come un attaccante, con la sua configurazione e il suo ambiente). Ma perde su copertura e tempismo, che per un difetto grave contano quanto la precisione. Copertura: il DAST testa solo i percorsi che riesce a raggiungere navigando; un ramo di codice che si attiva solo con un input raro non verrà mai esercitato, mentre il SAST lo legge comunque. Tempismo: il DAST richiede un'app in esecuzione in staging, quindi arriva a codice già scritto e integrato, mentre il SAST dà feedback sulla pull request, riga per riga, quando correggere costa un commento invece di un ciclo di rilascio. E c'è una classe di difetti che il DAST non localizza: ti dice "c'è una XSS raggiungendo questo URL", non "nasce da questa funzione" — per il fix serve comunque risalire al codice. Il modello mentale giusto non è una gara ma una pipeline di reti progressivamente più fini e più tardive: SAST e SCA ampi e precoci sul codice, DAST realistico e confermante sull'app viva, poi i controlli di runtime in produzione. Scartarne uno non ti dà più precisione, ti dà un buco in un punto preciso della timeline.

Conclusione

Il DAST attacca l’applicazione viva dall’esterno: trova configurazioni errate e difetti di runtime che il codice fermo nasconde, con pochi falsi positivi ma copertura parziale e tempi lunghi. SAST e DAST insieme coprono codice e comportamento. Esiste però un terzo punto di vista, ibrido: strumentare l’app dall’interno mentre viene testata, per unire visibilità sul codice e realismo del runtime. Sono IAST e RASP, 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.

SAST: analizzare il codice senza eseguirlo

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

Perché conta

Tolti i segreti dal codice, possiamo analizzare il codice stesso. Il SAST (Static Application Security Testing) legge il sorgente — senza eseguirlo — cercando pattern che portano a vulnerabilità. È il primo controllo che tocca la logica di ciò che scriviamo, e si attiva prima ancora della compilazione, nel punto più a sinistra possibile dopo il threat modeling.

Cosa trova (e cosa no)

Il SAST eccelle sui difetti locali e riconoscibili nel codice:

Injection (SQL, comandi, LDAP): input non sanitizzato che finisce in una query o in una shell.
Path traversal, XSS, deserializzazione insicura.
Crypto debole: MD5 per le password, algoritmi deprecati, chiavi hardcoded.
Pattern pericolosi: eval, formattazione di stringhe in query.

Non vede i difetti che emergono solo a runtime o dalla configurazione: un bucket pubblico, un header mancante, una logica di autorizzazione sbagliata che il codice esprime “correttamente”. Per quelli servono DAST e analisi di configurazione, capitoli successivi.

Come funziona: la taint analysis

Il cuore del SAST moderno è l’analisi del flusso dei dati contaminati (taint): segue un dato da una sorgente non fidata (input utente) fino a un sink pericoloso (una query), controllando se passa per un sanitizer.

  flowchart LR
    SRC["Source<br/>request.getParameter()"] -->|dato contaminato| F[Flusso nel codice]
    F --> SAN{"Passa da un<br/>sanitizer?"}
    SAN -->|no| SINK["Sink<br/>db.execute(sql)"]
    SAN -->|sì| OK[Sicuro]
    SINK --> V[VULNERABILITÀ:<br/>SQL injection]
    style V fill:#fde2e4,stroke:#e63946

Se un dato arriva dalla sorgente al sink senza sanitizzazione, lo strumento segnala. Questo spiega sia la potenza (trova catene non ovvie) sia i limiti (non sa che una certa funzione è un sanitizer se non gliel’hai detto → falso positivo).

Il problema dei falsi positivi

Il SAST ingenuo è famoso per il rumore. Un tool che segnala 500 problemi di cui 480 irrilevanti viene disattivato in una settimana. Le contromisure in una pipeline sana:

# esempio di gate SAST ragionevole nella CI
sast:
  fail_on: high          # blocca solo su severità alta, non su tutto
  diff_aware: true       # analizza solo il codice cambiato nella PR
  baseline: true         # ignora il debito preesistente, blocca il NUOVO
  suppress_with: comment # i falsi positivi si marcano, tracciati e revisionati

Le righe evidenziate sono ciò che rende il SAST sopportabile: blocca solo il nuovo rischio alto, non tutto il debito storico, e lascia una via esplicita (tracciata) per i falsi positivi.

Nel flusso di lavoro

Il posto giusto è la pull request: il feedback arriva come commento in linea, nel contesto, a chi ha appena scritto quel codice. Molti team aggiungono il SAST anche nell’IDE (feedback in tempo reale) e un passaggio nella CI come gate. Regole personalizzate (Semgrep rende questo semplice) codificano gli abuse case del threat model: la minaccia diventa una regola che fallisce se la falla ritorna.

Domanda: se il SAST ha tanti falsi positivi e non vede i difetti di runtime, perché non affidarsi solo al DAST che testa l'app reale?

Perché vedono cose diverse e in momenti diversi, e scartarne uno lascia un buco. Il SAST ha una visibilità totale sul codice — ogni ramo, ogni percorso, anche quelli che un test dinamico non raggiungerebbe mai senza l'input giusto — e dà feedback sulla singola riga, in fase di scrittura, quando correggere costa un minuto. Il DAST vede l'applicazione viva, quindi trova i difetti di configurazione e di ambiente che il SAST ignora, ma solo sui percorsi che riesce effettivamente a esercitare, e arriva tardi, in staging, quando il codice è già scritto e il contesto mentale perso. Non sono ridondanti, sono complementari: il SAST è la copertura ampia e precoce con il prezzo del rumore, il DAST è la conferma realistica ma tardiva e parziale. La risposta ai falsi positivi non è eliminare il SAST, è configurarlo bene — diff-aware, baseline, gate solo su severità alta, regole tarate sul tuo codice — così il segnale emerge dal rumore. Un difetto di injection trovato dal SAST sulla pull request costa un commento; lo stesso difetto trovato dal DAST in staging costa un ticket; trovato in produzione costa un incidente. Vuoi entrambe le reti, non la più comoda.

Conclusione

Il SAST legge il codice senza eseguirlo e segue i dati contaminati dalla sorgente al sink: ampio, precoce, ma rumoroso se non tarato su diff, baseline e severità. Cattura però solo il codice che scriviamo noi. La maggior parte di un’applicazione moderna, però, è codice che non abbiamo scritto: le dipendenze. Analizzarle è un problema diverso — la Software Composition Analysis, prossimo capitolo.

Gestione dei segreti: mai nel codice

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

Perché conta

Il threat modeling identifica dove i dati attraversano confini di fiducia; i segreti — chiavi, token, password — sono proprio ciò che protegge quei confini. Lasciarli nel codice è l’errore più banale e più diffuso: una chiave AWS in un commit, un token in un file .env versionato, e un repository anche privato diventa una bomba a orologeria. È il primo difetto concreto da eliminare nel flusso di sviluppo.

Il problema della history di Git

Il tranello peggiore: rimuovere un segreto con un commit successivo non lo elimina. Resta nell’intera history, recuperabile da chiunque abbia accesso al repository.

git add config.py        # contiene AWS_SECRET=...
git commit -m "config"   # il segreto è ora NELLA history, per sempre
git rm config.py         # lo toglie dalla HEAD, NON dalla history
# → il segreto va considerato COMPROMESSO: ruotalo subito

Regola d’oro: un segreto committato è un segreto bruciato. Non basta rimuoverlo, va ruotato (invalidato e rigenerato). La pulizia della history (con strumenti come git filter-repo) serve a non ripetere l’incidente, non a “annullarlo”.

I tre livelli di difesa

  flowchart TD
    A[1. Prevenzione<br/>secret scanning<br/>pre-commit] --> B[2. Centralizzazione<br/>secret manager<br/>niente segreti nel codice]
    B --> C[3. Riduzione del danno<br/>segreti dinamici<br/>a vita breve]
    style C fill:#fde2e4,stroke:#e63946

Prevenzione: uno scanner (gitleaks, trufflehog) come hook di pre-commit e nella pipeline blocca il segreto prima che entri nella history.
Centralizzazione: un secret manager (Vault, AWS Secrets Manager, cloud KMS) custodisce i segreti; l’applicazione li recupera a runtime con una propria identità, non li porta nel codice.
Riduzione del danno: i segreti dinamici — credenziali generate su richiesta e valide pochi minuti — fanno sì che un segreto trapelato valga quasi nulla, perché scade subito.

Segreti dinamici: il salto di qualità

Un segreto statico vive per mesi: se trapela, l’attaccante ha mesi. Vault può invece generare al volo una credenziale di database valida un’ora, legata al servizio che l’ha chiesta. Il furto diventa una finestra di minuti, non un accesso permanente. È lo stesso principio dei certificati a vita breve che vedremo per l’identità dei workload: ridurre il valore nel tempo di ogni credenziale.

Nel flusso di lavoro

Pre-commit: hook locale che rifiuta il commit con un segreto.
CI: scansione del diff e, periodicamente, dell’intera history.
Runtime: l’app chiede il segreto al manager con la sua identità; nessun segreto nel container image né nelle variabili d’ambiente scritte a mano.
Rotazione: automatica e regolare, non “quando ci ricordiamo”.

Domanda: se l'app recupera i segreti da Vault, le serve comunque una credenziale per autenticarsi a Vault — non abbiamo solo spostato il problema?

È la domanda giusta, ed è il classico "problema del segreto zero" — lo stesso che SPIFFE/SPIRE risolve per i workload. Sì, serve una credenziale iniziale per parlare con Vault, ma la si è spostata da "mille segreti sparsi in mille repository e file di config" a "un solo punto di bootstrap, progettato apposta per essere protetto". E quel bootstrap non deve essere a sua volta un segreto statico scritto da qualche parte: i metodi di auth di Vault sfruttano un'identità che la piattaforma attesta, non una stringa consegnata. In Kubernetes l'app si autentica con il suo ServiceAccount token, che il cluster emette e verifica; in cloud con l'identità dell'istanza (IAM role, managed identity), provata dal provider; con SPIFFE, con lo SVID emesso per attestazione. In tutti i casi la fiducia iniziale poggia su qualcosa che l'ambiente testimonia — "sei il pod X nel namespace Y sul nodo Z" — non su una chiave che qualcuno deve custodire per prima. Il problema non è "spostato" in circolo: è ridotto da N segreti fragili a un unico punto radicato nell'identità della piattaforma, molto più difendibile e monitorabile.

Conclusione

I segreti non stanno mai nel codice: si previene con lo scanning, si centralizza con un secret manager, si riduce il danno con segreti dinamici a vita breve. E un segreto committato è un segreto da ruotare, non da nascondere. Con i segreti fuori dal codice, possiamo guardare il codice stesso: il primo controllo automatico che lo ispeziona mentre viene scritto è l’analisi statica, prossimo capitolo.

Threat modeling nel ciclo di sviluppo

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

Perché conta

Il Secure SDLC colloca il threat modeling nel design, la fase più economica in assoluto: qui un difetto costa una gomma su una lavagna. Lo stesso ragionamento l’abbiamo già applicato alle reti nel post sul threat modeling delle reti; qui lo portiamo dentro il ciclo di sviluppo del software, dove diventa un’abitudine ricorrente e non un documento scritto una volta e mai più aperto.

I quattro passi

Il threat modeling risponde a quattro domande, nell’ordine:

  flowchart LR
    Q1["1. Cosa stiamo<br/>costruendo?"] --> Q2["2. Cosa può<br/>andare storto?"]
    Q2 --> Q3["3. Cosa facciamo<br/>al riguardo?"]
    Q3 --> Q4["4. Abbiamo fatto<br/>un buon lavoro?"]
    Q4 -.rivaluta a ogni<br/>cambio di design.-> Q1
    style Q2 fill:#fde2e4,stroke:#e63946

Cosa costruiamo: un diagramma di flusso dei dati (DFD) con i confini di fiducia — dove i dati attraversano una frontiera tra componenti con privilegi diversi.
Cosa può andare storto: si enumerano le minacce, tipicamente con STRIDE.
Cosa facciamo: per ogni minaccia una mitigazione, un rischio accettato o un trasferimento.
Com’è andata: si verifica che le mitigazioni esistano davvero nel codice e nei test.

STRIDE: una lente per le minacce

STRIDE è una checklist mnemonica per non dimenticare categorie di minaccia:

S  Spoofing        → identità falsificata        → autenticazione
T  Tampering       → dati/codice alterati        → integrità, firme
R  Repudiation     → "non sono stato io"         → log a prova di manomissione
I  Info disclosure → fuga di dati                → cifratura, controllo accessi
D  Denial of svc   → risorsa resa indisponibile  → rate limit, quote
E  Elevation       → privilegi oltre il dovuto   → least privilege, validazione

Si scorre ogni elemento del DFD e, per ciascuno, si chiede: può essere vittima di spoofing? di tampering? e così via. La forza non è la completezza teorica, ma il fatto che struttura una conversazione che altrimenti dipende da chi è il più paranoico nella stanza.

Renderlo leggero e continuo

Il threat modeling fallisce quando diventa un rito pesante: un documento di 40 pagine, redatto una volta da un consulente, ignorato da chi scrive il codice. Le pratiche che funzionano in DevSecOps:

Incrementale: si modella la modifica, non tutto il sistema, a ogni design significativo.
Di squadra: chi costruisce partecipa; il modello vive nelle loro teste, non in un PDF.
Tracciato come codice: le minacce diventano issue e test, così “l’abbiamo mitigata” è verificabile e non un’affermazione.

Dall’abuse case al test

Ogni minaccia identificata dovrebbe generare qualcosa di eseguibile: un abuse case (“un utente non autenticato tenta di leggere l’ordine di un altro”) che diventa un test di sicurezza automatico. Così il modello non invecchia in silenzio: se qualcuno reintroduce la falla, il test fallisce. È il ponte tra il design e i controlli di build dei prossimi capitoli.

Domanda: con pipeline che rilasciano dieci volte al giorno, come si fa threat modeling senza bloccare ogni deploy?

Non si modella ogni deploy: si modella ogni decisione di design, che è molto più rara di un deploy. La maggior parte dei rilasci sono cambi incrementali dentro un'architettura già modellata — una nuova colonna, un fix, un endpoint in più su un pattern esistente — e non spostano confini di fiducia: non richiedono nulla. Il trigger non è il tempo né il commit, è il cambio strutturale: un nuovo componente, un nuovo flusso di dati verso l'esterno, una nuova integrazione di terze parti, un cambio nel modello di autenticazione. Quando succede, un threat model leggero di trenta minuti sulla sola modifica basta, e si fa in fase di design, giorni prima del deploy, non nel percorso critico della pipeline. Alcuni team lo agganciano alla pull request con una checklist automatica ("questo cambio tocca autenticazione, dati personali, confini di rete?"): se tutte le risposte sono no, non serve una sessione; se una è sì, si convoca. Così il controllo pesa solo quando il rischio c'è davvero, e i dieci deploy al giorno di routine non vengono toccati.

Conclusione

Il threat modeling è il controllo più economico perché agisce prima della prima riga di codice: quattro domande, la lente STRIDE, e minacce trasformate in test che non invecchiano. Ma il design sicuro vale poco se poi il codice lascia una chiave API in chiaro nel repository. Il primo difetto concreto da eliminare nel flusso di sviluppo è proprio questo: la gestione dei segreti, prossimo capitolo.

Il Secure SDLC: un controllo per ogni fase

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

Perché conta

Nel capitolo precedente abbiamo stabilito il perché dello shift left. Ora il dove: quali attività di sicurezza appartengono a quale fase. Senza una cornice, ogni team reinventa un insieme casuale di controlli, dimentica interi domini (la gestione dei segreti, la supply chain) e non sa dire se sta migliorando. Il Secure SDLC è quella cornice.

Le fasi e i loro controlli

  flowchart LR
    REQ[Requisiti<br/>abuse case,<br/>requisiti di sicurezza] --> DES[Design<br/>threat modeling]
    DES --> DEV[Sviluppo<br/>SAST, SCA,<br/>secret scanning]
    DEV --> TST[Test<br/>DAST, fuzzing,<br/>security gate]
    TST --> REL[Rilascio<br/>SBOM, firma,<br/>hardening]
    REL --> OPS[Operate<br/>runtime, patch,<br/>detection, IR]
    style DES fill:#fde2e4,stroke:#e63946

Ogni fase ha un controllo naturale: il momento in cui quel tipo di difetto è più economico da prevenire. Mettere il threat modeling nel design evita di scrivere codice su un’architettura sbagliata; mettere il SAST nello sviluppo cattura i bug mentre il contesto è fresco nella mente di chi li ha scritti.

Due framework da conoscere

NIST SSDF (SP 800-218): descrive pratiche in quattro gruppi — preparare l’organizzazione, proteggere il software, produrre software ben protetto, rispondere alle vulnerabilità. È prescrittivo sul cosa, agnostico sul come. Ottimo come checklist di copertura.
OWASP SAMM: un modello di maturità. Non chiede solo “lo fai?” ma “a che livello?” (1, 2, 3) su quindici pratiche. Serve a misurare dove sei e dove andare, non a fare tutto subito.

Maturità, non perfezione

L’errore classico è voler implementare ogni controllo al massimo livello dal primo giorno. Risultato: pipeline lentissime, team in rivolta, controlli disattivati. La maturità è un percorso:

1
2
3

Livello 1  controllo implementato, anche solo su progetti pilota   ← comincia qui
Livello 2  applicato in modo coerente, con processo definito
Livello 3  misurato, ottimizzato, automatizzato ovunque

Si sceglie per rischio: i servizi esposti a internet e che toccano dati sensibili salgono di livello prima di un tool interno letto da tre persone. Una cornice serve a prioritizzare, non a pretendere uniformità.

Il SDLC incontra il CI/CD

Il Secure SDLC è il cosa; la pipeline CI/CD è il dove lo automatizzi. Ogni controllo della catena ha una collocazione naturale nella pipeline: il secret scanning come hook di pre-commit, il SAST sulla pull request, il DAST in staging, la firma dell’artefatto al rilascio. I capitoli successivi riempiono ogni casella; questa è la mappa che impedisce di dimenticarne una.

Domanda: i framework come SSDF e SAMM non sono solo burocrazia che rallenta un team agile?

Diventano burocrazia solo se usati male — come moduli da compilare per un auditor invece che come checklist per non dimenticare domini interi. Usati bene fanno l'opposto di rallentare: evitano la retromarcia costosa. Il team agile che salta il threat modeling e scopre a sei mesi dal lancio che l'architettura di multi-tenancy perde dati tra clienti non è stato veloce, è stato veloce verso un muro. Il valore di una cornice non è la cerimonia, è la copertura: senza, è statisticamente certo che dimenticherai qualcosa — di solito la gestione dei segreti o la supply chain, i due domini che nessuno "sente" come proprio finché non esplodono. Il modo agile di usare questi framework è prenderli come menu, non come contratto: scegli i controlli proporzionati al rischio del servizio, li automatizzi nella pipeline così non pesano sul lavoro quotidiano, e sali di maturità quando il rischio lo giustifica. La cornice è leggera; è l'incidente che evita a essere pesante.

Conclusione

Il Secure SDLC mappa un controllo a ogni fase, e i modelli di maturità trasformano “fai tutto” in un percorso guidato dal rischio. È la mappa; il resto della serie sono le tappe. La prima, e quella con il miglior rapporto costo/beneficio, vive nel design: ragionare da attaccante prima di scrivere codice. È il threat modeling, prossimo capitolo.

Che cos'è DevSecOps (e cosa non è)

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

Perché conta

Il modello tradizionale tratta la sicurezza come un cancello: il team costruisce per mesi, poi un gruppo separato fa un audit e restituisce una lista di problemi. A quel punto correggere è costoso, lento e conflittuale. DevSecOps elimina il cancello e distribuisce la sicurezza lungo tutto il flusso. La serie parte da qui perché, senza capire il perché, ogni strumento diventa solo un altro ostacolo da aggirare.

Il costo del difetto nel tempo

L’argomento economico è il più solido. Un difetto costa in modo crescente a seconda di quando lo si scopre:

Fase in cui si trova il difetto      Costo relativo di correzione
  Design / requisiti                  1×   ← qui vuoi i controlli
  Implementazione                     ~5×
  Test / QA                           ~10×
  Produzione                          ~30× e oltre  ← qui li trovi se non fai nulla

Le cifre esatte variano da studio a studio, ma la direzione è costante: prima trovi, meno paghi. Questo è il senso economico dello shift left, spostare i controlli verso sinistra nella timeline.

I tre pilastri

DevSecOps non è un prodotto. È l’incontro di tre dimensioni:

  flowchart TD
    P[Persone<br/>responsabilità condivisa] --- PR[Processi<br/>sicurezza in ogni fase]
    PR --- T[Tecnologia<br/>automazione nel flusso]
    T --- P
    style P fill:#fde2e4,stroke:#e63946

Persone: la sicurezza è di tutti, non di un team isolato. Gli sviluppatori ricevono feedback nel loro strumento (IDE, pull request), non in un report che leggeranno forse mai.
Processi: ogni fase ha un controllo adeguato, dal design al runtime. Niente è lasciato “al momento del rilascio”.
Tecnologia: i controlli sono automatizzati nella pipeline. Ciò che è manuale viene saltato sotto pressione; ciò che è automatico vale per ogni commit.

Cosa NON è DevSecOps

Non è comprare uno strumento: uno scanner senza un processo che agisca sui risultati produce solo rumore.
Non è assumere un “DevSecOps engineer” che faccia sicurezza al posto degli altri: ricrea il silo che si voleva eliminare.
Non è bloccare ogni build al primo warning: una pipeline che grida al lupo viene disattivata. La sicurezza utile è quella azionabile e proporzionata al rischio.

Guardrail, non gate

La metafora giusta non è il cancello (gate) che ferma tutti, ma il guardrail: una protezione che ti lascia andare veloce mantenendoti in carreggiata. Un buon controllo DevSecOps dà un feedback rapido, con pochi falsi positivi, e dice come risolvere — non solo che c’è un problema.

Domanda: se "shift left" mette tutti i controlli all'inizio, non trascuriamo la sicurezza in produzione, dove avvengono gli attacchi veri?

È un fraintendimento comune e importante da correggere: shift-left non significa spostare tutto a sinistra, significa aggiungere controlli a sinistra senza togliere quelli a destra. Il termine più onesto oggi è "shift everywhere". Trovare una SQL injection in fase di design con il threat modeling costa un disegno su una lavagna; trovarla con il SAST in fase di build costa un commento su una pull request; trovarla con il DAST in staging costa un ticket; trovarla in produzione con un WAF o la detection costa un incidente. Sono controlli complementari, non alternativi: ognuno cattura ciò che gli altri si lasciano sfuggire. Il SAST non vede un errore di configurazione del server, il runtime non vede una logica di business difettosa fino a quando non viene sfruttata. La difesa in profondità vuole controlli a ogni stadio; shift-left corregge solo lo squilibrio storico per cui a sinistra non c'era nulla e tutto il peso cadeva su un audit finale. Chi interpreta shift-left come "smontiamo il monitoraggio di produzione" ha capito l'esatto contrario.

Conclusione

DevSecOps è un cambiamento di responsabilità (da un silo a tutti), di tempismo (da fine a ovunque) e di modo (da manuale ad automatico). L’argomento è economico prima che morale: trovare presto costa meno. Il primo controllo che sposta a sinistra non è uno scanner, ma una conversazione sul design: il threat modeling. Ma prima serve una cornice che dica quali pratiche e dove — il Secure SDLC, prossimo capitolo.