Governance on My personal blog

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.

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.