Un artefatto software firmato che nessuno verifica protegge quanto un artefatto non firmato: niente. Lo stesso per un SBOM (Software Bill of Materials) generato a ogni build e mai confrontato con una policy: documenta la supply chain, non la mette al sicuro. La provenienza verificabile — inventario delle dipendenze, attestazioni di build, firma crittografica — diventa un controllo solo nel momento in cui un punto della catena rifiuta ciò che non supera la verifica. Tolto quel rifiuto, resta carta per la conformità.

Il problema

Dicembre 2021, CVE-2021-44228 (Log4Shell): una stringa come ${jndi:ldap://…} scritta nei log da Apache Log4j 2 apre la strada all’esecuzione di codice da remoto, con punteggio CVSS 10.0. Le versioni colpite vanno dalla 2.0-beta9 alla 2.14.1; la prima a contenere la mitigazione è la 2.15.0. La domanda operativa per migliaia di organizzazioni — quali nostri sistemi usano Log4j, in quali versioni, anche come dipendenza transitiva? — quasi mai trovava risposta in tempo utile. Il difetto era nel codice da anni; a far male, nell’immediato, era l’assenza di un inventario delle dipendenze su cui poter fare una query.

L’industria ha risposto con tre artefatti distinti, che spesso si confondono tra loro:

  • SBOM — l’inventario dei componenti (nome, versione, hash, licenza, dipendenze transitive). Risponde a cosa c’è dentro.
  • Provenance e attestazioni di build — chi ha costruito l’artefatto, da quale sorgente, con quale builder. Risponde a come è stato prodotto.
  • Firma — il legame crittografico tra l’artefatto e un’identità. Risponde a chi se ne fa garante.

Nessuno dei tre, da solo, ferma un deploy malevolo. Per fermarlo serve un quarto elemento: la verifica imposta.

L’architettura

La catena che funziona ha tre stadi, e il terzo è quello che la maggior parte delle pipeline salta.

Generazione. A build time si producono SBOM (nei formati SPDX o CycloneDX) e provenance. Il framework di riferimento per la provenance è SLSA (Supply-chain Levels for Software Artifacts), la cui Build track definisce livelli crescenti. Build L1 chiede una provenance che descriva piattaforma, processo e input di primo livello — può essere incompleta e non firmata. Build L2 chiede che la build giri su infrastruttura dedicata e che la provenance sia legata a quell’infrastruttura da una firma digitale, con verifica a valle dell’autenticità. Build L3 aggiunge i controlli che impediscono a run diversi di influenzarsi e ai passi definiti dall’utente di toccare il materiale segreto usato per firmare. Le attestazioni si scrivono di solito con in-toto, progetto graduato CNCF che standardizza i metadati su passi, esecutori e ordine della supply chain.

Firma e trasparenza. Sigstore rende la firma praticabile senza dover gestire chiavi a lungo termine. Il flusso keyless funziona così: cosign genera una coppia di chiavi effimera, Fulcio (la CA) verifica un token OIDC ed emette un certificato a vita breve legato a quell’identità, la chiave privata viene buttata dopo una singola firma. Firma, certificato e digest dell’artefatto finiscono su Rekor, un transparency log append-only e immutabile. Il problema si sposta: non più custodire una chiave, ma fidarsi di un’identità OIDC e di un log pubblico. Chi consuma l’artefatto interroga Rekor e conferma che il certificato fosse valido nel momento della firma.

Enforcement della verifica. È lo stadio che trasforma gli artefatti precedenti in un controllo. In una pipeline CI/CD è il passo che fa fallire la build se l’SBOM contiene un componente in denylist o una CVE oltre soglia. A runtime, su Kubernetes, è un admission controller che valuta una policy di firma e respinge i Pod la cui immagine non porta una firma cosign da un’identità attesa, o una provenance SLSA al livello richiesto. Senza questo cancello, generare e firmare è lavoro buttato: il deploy passa lo stesso.

Dove si rompe

I punti di rottura stanno nel modello di fiducia e nella verifica, non nella generazione.

Trust root. La firma keyless sposta la fiducia su tre elementi: il provider OIDC che attesta l’identità, la CA Fulcio che emette i certificati, il transparency log Rekor. Una policy che accetta qualsiasi identità firmataria non verifica niente di utile: deve vincolare l’identità OIDC attesa — per esempio uno specifico workflow GitHub Actions dentro uno specifico repository. Controllare che la firma ci sia, senza controllare chi ha firmato, è la forma più diffusa di verifica-teatro.

Key management nel keyless. Togliere le chiavi a lungo termine elimina il furto di chiavi persistenti, ma sposta la superficie d’attacco: chi controlla l’identità OIDC controlla la firma. Un token OIDC compromesso, o una configurazione che lascia un workflow qualsiasi impersonare l’identità attesa, produce firme valide su artefatti malevoli. Il transparency log rende l’abuso rilevabile dopo, non impedito.

Completezza e accuratezza dell’SBOM. Un SBOM vale quanto è fedele al binario che spedisci. Generato dal manifest delle dipendenze, può perdere componenti introdotti dal build system o vendored nel codice; generato dall’artefatto finale, dipende da quanto lo scanner riesce a riconoscere. Le dipendenze transitive sono il punto preciso in cui un inventario incompleto fa cilecca, esattamente come con Log4j. Un SBOM che elenca solo le dipendenze dirette non avrebbe risposto alla domanda del dicembre 2021.

Verifica a runtime. Verificare alla build e non al deploy lascia aperta la finestra tra i due momenti. Un’immagine può essere firmata come si deve e poi sostituita nel registry, oppure un tag mutabile può puntare a un digest diverso. La verifica che conta è quella sul digest immutabile, fatta dall’admission controller nell’istante del deploy.

Cosa cambia con la normativa

L’aggancio normativo porta questa architettura da buona pratica a vincolo. Il Cyber Resilience Act — Regolamento (UE) 2024/2847 — è entrato in vigore il 10 dicembre 2024, con applicazione scaglionata. Gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi scattano dall’11 settembre 2026; il grosso dei requisiti essenziali, documentazione tecnica inclusa, dall’11 dicembre 2027. L’Allegato I chiede di documentare i componenti del prodotto in un SBOM in formato di uso comune e leggibile dalle macchine, che copra almeno le dipendenze di primo livello, da inserire nella documentazione tecnica e da fornire alle autorità di sorveglianza su richiesta — senza obbligo di pubblicarlo.

I due fronti sono lo stesso lavoro visto da due lati. Per rispondere entro 24 ore (early-warning) quando una dipendenza viene sfruttata bisogna sapere, in quel momento, quali prodotti la contengono. È esattamente la domanda a cui risponde un SBOM accurato e interrogabile. La scadenza normativa è il 2027; la capacità operativa che la soddisfa è un inventario costruito e verificato prima.

I limiti

La provenienza verificabile copre integrità e origine della catena di build, non la correttezza del codice. Un artefatto può essere firmato in modo impeccabile, costruito a SLSA Build L3, con un SBOM completo, e contenere comunque una vulnerabilità ancora ignota: Log4Shell era firmabile e attestabile quanto qualsiasi altra libreria. La provenienza dice da dove viene e chi se ne fa garante, non è privo di difetti.

Gli NTIA minimum elements per un SBOM (campi dati di base, tracciabilità, prassi operative) restano un pavimento: l’allineamento tra l’SBOM dichiarato e il binario eseguito lo standard non lo verifica, lo deve verificare la pipeline. E a oggi nessun atto delegato UE impone un formato SBOM specifico: la scelta tra SPDX e CycloneDX resta all’organizzazione, così come l’onere di tenerli aggiornati a ogni release.

Per chi parte adesso il passo concreto è aggiungere il cancello che verifica gli artefatti, prima ancora che generarne altri. Una pipeline che sforna SBOM e firme senza un admission controller che le imponga ha aumentato il lavoro, non la sicurezza.

https://slsa.dev/spec/v1.0/levels https://docs.sigstore.dev/ https://www.sigstore.dev/ https://in-toto.io/ https://www.ntia.gov/page/software-bill-materials https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://www.noze.it/insights/sbom-slsa-supply-chain/

Immagine di copertina: Lettera di carta piegata a mano, chiusa da un sigillo di ceralacca rossa con impressa la lettera “A” — foto di Contrafool, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Wax_seal_with_impression_of_uppercase_letter_A.jpg