L’8 dicembre 2026 Docker ritira ufficialmente Docker Content Trust, il sistema di firma delle immagini container che per anni era stato lo standard de facto. Il problema è che quasi nessuno lo usava davvero: secondo una stima citata dal blog di Safeguard, meno dello 0,05% dei pull effettuati da Docker Hub passava attraverso quel meccanismo. Al suo posto, tre progetti open source si contendono il ruolo di nuovo standard per la sicurezza della supply chain dei container, Cosign, Notation (l’implementazione pratica di Notary v2) e in-toto. Non sono concorrenti diretti nel senso stretto del termine, ognuno copre un livello diverso del problema, ma per chi deve scegliere cosa adottare nella propria pipeline CI/CD la confusione è reale. Questo confronto mette a terra specifiche tecniche, numeri di adozione, costi e scenari d’uso concreti, con un occhio alle esigenze di conformità che in Europa stanno diventando sempre più pressanti con NIS2.
Non perderti le nuove storie tech su Google
Aggiungi Shattered una volta nell'app Google e i nostri articoli compariranno nei tuoi suggerimenti.
Perché la firma delle immagini container è diventata urgente
Per anni la firma crittografica delle immagini container è rimasta un esercizio da manuale di sicurezza, qualcosa che si sapeva andrebbe fatto ma che pochi team mettevano davvero in produzione. Gestire chiavi private, ruotarle, proteggerle da furti e compromissioni richiedeva un’infrastruttura che la maggior parte delle organizzazioni non aveva voglia di costruire. Il risultato è stato un’adozione marginale, confermata proprio dal dato sotto lo 0,05% di Docker Hub.
Il contesto però è cambiato in fretta. Gli attacchi alla supply chain software hanno spinto governi e regolatori a imporre requisiti più stringenti su provenienza e integrità del software distribuito. In Europa la direttiva NIS2 chiede alle organizzazioni critiche di dimostrare controlli concreti sulla catena di fornitura digitale, e la firma delle immagini container è uno dei modi più diretti per farlo. Allo stesso tempo Sigstore, il progetto che sta dietro Cosign, ha eliminato il principale ostacolo pratico, la gestione delle chiavi. Con la firma keyless, basata su certificati a vita breve emessi da Fulcio e registrati nel transparency log Rekor, un team può firmare immagini senza conservare mai una chiave privata a lungo termine.
A questo si aggiunge un fattore temporale preciso, il pensionamento di Docker Content Trust l’8 dicembre 2026 costringe chi lo usava ancora a migrare verso qualcos’altro entro fine anno. Non è un evento che riguarda solo gli utenti attuali di DCT, è anche l’occasione per chi non aveva mai preso sul serio la firma dei container di colmare il ritardo scegliendo uno strumento moderno fin da subito. Cosign 2.6, rilasciato il 6 agosto 2026, introduce proprio in questo periodo un nuovo formato bundle con trusted root portabile e verifica offline, segno che il progetto sta investendo pesantemente per intercettare questa fase di transizione.
Cosign, Notation e in-toto: tre strumenti, tre livelli di sicurezza
Il primo equivoco da chiarire è che Cosign, Notation e in-toto non competono esattamente sullo stesso terreno. Si sovrappongono in parte, ma ciascuno risolve un problema diverso e spesso complementare.
Cosign è il client da riga di comando del progetto Sigstore e si concentra sulla firma e verifica di immagini container, artefatti OCI generici, blob, file, binari, chart Helm e attestazioni in-toto. È pensato per vivere dentro la pipeline CI/CD, si firma l’artefatto appena costruito, si pubblica la firma insieme all’immagine nel registry, e chiunque la scarichi può verificarla senza bisogno di accedere a infrastrutture separate.
Notation, l’implementazione di riferimento di Notary v2, sposta l’attenzione sul registry. Invece di trattare la firma come un passaggio isolato della pipeline, Notation la integra nel modello degli artefatti OCI e si appoggia a registry che supportano nativamente le trust policy, come Azure Container Registry e Quay di Red Hat. Qui la verifica può avvenire a livello di infrastruttura condivisa, non solo nel singolo client che scarica l’immagine.
in-toto alza ulteriormente il livello di astrazione, non si limita a certificare che un’immagine finale è integra, ma prova a tracciare e attestare ogni passaggio della pipeline di build, da chi ha eseguito il checkout del codice a chi ha lanciato il test fino a chi ha prodotto l’artefatto finale. È lo strumento più adatto a chi deve dimostrare conformità a framework come SLSA al livello 3, dove la provenienza dell’intero processo conta quanto l’integrità del prodotto finito.
Un modo utile per inquadrare la differenza, Cosign risponde alla domanda “questa immagine è davvero quella che ha pubblicato questo team?”, Notation risponde a “il registry può imporre che solo immagini firmate vengano distribuite?”, in-toto risponde a “posso dimostrare chi ha fatto cosa in ogni fase della build?”. Le tre domande non si escludono a vicenda, e infatti molte organizzazioni mature finiscono per usarne più di una in combinazione.
Come funziona Cosign e il progetto Sigstore
Cosign nasce dentro Sigstore, un progetto ombrello che punta a rendere la firma del software accessibile senza l’onere operativo della gestione delle chiavi. Il meccanismo centrale è la firma keyless, invece di generare e custodire una coppia di chiavi a lungo termine, chi firma si autentica tramite un provider OpenID Connect, come Google, GitHub o Microsoft, e riceve da Fulcio un certificato a vita brevissima, pensato per essere usato una sola volta e poi scartato. L’evento di firma viene registrato in modo immutabile nel transparency log pubblico Rekor, cosa che permette a chiunque di verificare in un secondo momento chi ha firmato cosa e quando, senza dover fidarsi ciecamente di un singolo attore.
Il rilascio più recente, Cosign 2.6, datato 6 agosto 2026 secondo i dati raccolti da x-cmd, introduce un nuovo formato bundle che include un trusted root portabile. In pratica questo significa poter distribuire a un verificatore tutto il materiale necessario per controllare una firma, incluse le informazioni sulla catena di fiducia, senza che quel verificatore debba avere accesso in tempo reale a Fulcio o Rekor. È un passo importante per ambienti air-gapped o con restrizioni di rete, uno scenario comune nella pubblica amministrazione e nella difesa europee, dove la connettività costante verso servizi cloud pubblici non è sempre garantita.
Dal punto di vista della copertura funzionale, Cosign è lo strumento più versatile dei tre, firma immagini container, artefatti OCI generici, blob arbitrari, file, binari, chart Helm e perfino dichiarazioni in-toto, il che lo rende una sorta di collante tra i tre mondi. Il progetto resta attivo, secondo x-cmd l’ultimo commit registrato risale al 16 ottobre 2026, appena tre giorni prima della stesura di questo articolo, un segnale di sviluppo continuo piuttosto che di manutenzione passiva.
Il rovescio della medaglia riguarda la governance della fiducia. Con la firma keyless, la verifica dipende dal fatto che l’identità OIDC usata per firmare sia davvero quella attesa, e questo sposta parte della responsabilità sulla configurazione delle policy OIDC del provider di identità scelto. Per organizzazioni che preferiscono un controllo più tradizionale basato su chiavi statiche gestite internamente, Cosign supporta comunque anche quella modalità, ma è la firma keyless ad aver trainato la sua adozione negli ultimi due anni.
Notation e Notary v2: la firma nativa dei registry OCI
Notation nasce per risolvere un problema specifico che Notary v1, alla base di Docker Content Trust, non aveva mai risolto bene, l’integrazione nativa con il modello degli artefatti OCI. Invece di trattare la firma come un meccanismo separato e parallelo al registry, come faceva il vecchio Notary legato a Docker, Notation archivia le firme come manifest OCI distinti collegati all’immagine originale. Questo significa che qualsiasi registry compatibile con lo standard OCI artifacts può, in teoria, ospitare le firme Notation senza bisogno di estensioni proprietarie.
In pratica, però, l’adozione di Notation si concentra su un numero ristretto di registry che hanno investito per renderla parte integrante della propria offerta, come documentato nell’approfondimento di TT Lab sui registry container nel 2026. Azure Container Registry è il caso più citato, con la possibilità di definire trust policy direttamente a livello di registry e bloccare il pull di immagini non firmate prima ancora che raggiungano un cluster. Quay di Red Hat segue un percorso simile, offrendo la verifica delle firme come funzionalità gestita a livello di piattaforma. Questo approccio ha un vantaggio operativo concreto, il controllo della firma non dipende dalla configurazione corretta di ogni singolo client Kubernetes, ma viene applicato in modo centralizzato dal registry stesso.
Il rovescio della medaglia è che questo modello funziona meglio quanto più l’organizzazione è già allineata su un registry che supporta nativamente Notation. Se il proprio stack usa un mix di registry eterogenei, o un registry generico che non ha investito nell’integrazione, Notation perde parte del suo vantaggio rispetto a un approccio più agnostico come quello di Cosign. Non a caso, secondo il confronto pubblicato da Pi Stack, Notation risultava a circa 477 stelle su GitHub, un numero nettamente inferiore ai 5.834 di Cosign nello stesso periodo di osservazione, segno di una comunità più di nicchia legata a specifici ecosistemi enterprise piuttosto che a un’adozione trasversale nel mondo open source.
Resta comunque uno strumento solido per chi parte da zero su Azure o su un’infrastruttura basata su Quay, la configurazione della trust policy è relativamente semplice da impostare e la verifica avviene in modo trasparente senza richiedere modifiche pesanti alla pipeline CI/CD esistente, a patto di accettare la dipendenza stretta dal registry scelto.
in-toto: attestare l’intera pipeline di build
Se Cosign e Notation si concentrano sull’artefatto finale, in-toto parte da un presupposto diverso, anche un’immagine firmata correttamente può nascondere un problema se uno dei passaggi intermedi della build è stato compromesso. Un attaccante che riesce a iniettare codice malevolo in uno step di compilazione, prima ancora che l’immagine venga firmata, rende inutile qualsiasi controllo successivo sulla firma finale.
in-toto risolve questo con un sistema di layout e attestazioni, si definisce in anticipo quali passaggi compongono la pipeline, chi è autorizzato a eseguire ciascuno, e quali materiali e prodotti ogni step deve generare. A ogni esecuzione, lo strumento registra prove crittografiche che collegano l’output di uno step all’input dello step successivo, costruendo una catena di custodia verificabile dall’inizio alla fine. Questo è esattamente il tipo di evidenza richiesta per dimostrare conformità al livello 3 del framework SLSA, lo standard sempre più citato nelle conversazioni su sicurezza della supply chain software in ambito enterprise ed europeo.
Il costo di questa granularità è la complessità di adozione. Mentre firmare un’immagine con Cosign richiede in sostanza una riga di comando in più nella pipeline, strutturare un layout in-toto completo richiede di mappare con precisione ogni fase del processo di build, assegnare responsabilità e autorizzazioni, e mantenere questa mappa aggiornata quando la pipeline cambia. È un investimento che si giustifica per organizzazioni con requisiti di conformità stringenti, mentre può risultare sproporzionato per un piccolo team che vuole solo iniziare a firmare le proprie immagini.
Numericamente, in-toto risultava a circa 994 stelle su GitHub secondo lo stesso confronto Pi Stack citato sopra, un numero intermedio tra Cosign e Notation che riflette bene il suo posizionamento, più specializzato di Cosign ma con una base di adozione più ampia di Notation grazie al fatto che non dipende da un registry specifico per funzionare. Scritto in Python, a differenza di Cosign e Notation che sono entrambi in Go, in-toto si integra spesso come libreria dentro strumenti di orchestrazione della build più ampi, piuttosto che essere invocato direttamente da riga di comando in ogni pipeline.
Tabella comparativa: le specifiche tecniche a confronto
Mettere le tre tecnologie fianco a fianco aiuta a visualizzare dove si sovrappongono e dove invece divergono radicalmente.
| Caratteristica | Cosign (Sigstore) | Notation (Notary v2) | in-toto |
|---|---|---|---|
| Organizzazione di riferimento | Sigstore / OpenSSF | CNCF, Notary v2 Project | CNCF, in-toto Project |
| Linguaggio principale | Go | Go | Python |
| Stelle GitHub (confronto 2026) | circa 5.834 | circa 477 | circa 994 |
| Ultima release nota | v2.6, 6 agosto 2026 | N/D | N/D |
| Ultimo commit noto | 16 ottobre 2026 | N/D | N/D |
| Modalità di firma principale | Keyless (OIDC + Fulcio) o chiave statica | Chiave gestita via KMS o trust store del registry | Chiave per ogni step della pipeline |
| Transparency log | Rekor | Non nativo | Non nativo |
| Oggetti firmabili | Immagini, artefatti OCI, blob, file, binari, chart Helm, attestazioni in-toto | Artefatti OCI | Materiali e prodotti di ogni step della build |
| Verifica offline | Sì, da v2.6 con trusted root portabile | Dipende dal registry/KMS usato | Sì, basata su layout locale |
| Integrazione registry nativa | Qualsiasi registry compatibile OCI | Azure Container Registry, Quay (supporto nativo) | Nessuna, opera a livello di pipeline |
| Standard di conformità più adatto | SLSA (vari livelli) | Specifica OCI artifacts | SLSA Level 3 |
| Ambito di utilizzo tipico | Firma e verifica in pipeline CI/CD | Distribuzione e verifica lato registry | Provenienza e integrità dell’intero processo di build |
Il divario nelle stelle GitHub tra Cosign e gli altri due progetti non misura da solo la qualità dello strumento, ma dà un’indicazione abbastanza chiara di dove si concentra l’attenzione della comunità open source nel 2026. Cosign beneficia del fatto di essere utilizzabile fuori dal contesto di un registry specifico, mentre Notation resta più legato a ecosistemi enterprise come Azure e Quay dove l’adozione passa spesso attraverso canali diversi dal semplice star su GitHub, ad esempio tramite documentazione ufficiale del vendor piuttosto che tramite il repository stesso.
Benchmark e adozione: cosa dicono tre fonti indipendenti
Oltre ai conteggi di popolarità su GitHub, vale la pena guardare a tre angolazioni diverse per capire quanto questi strumenti siano davvero utilizzati in produzione, non solo osservati con curiosità.
La prima fonte è il repository DevSecOps-Kit su GitHub, una raccolta di riferimento che copre l’intero stack di sicurezza DevSecOps, da Linux e Git fino a infrastructure as code e Kubernetes. Cosign compare in questa raccolta accanto a strumenti ormai affermati come Trivy, Syft, Grype, Checkov, tfsec, Terrascan, Semgrep, CodeQL, SonarQube, ZAP e Falco. Il fatto che Cosign sia considerato parte integrante del toolkit standard di un professionista DevSecOps, alla pari di scanner di vulnerabilità consolidati da anni, racconta più di un semplice conteggio di stelle.
La seconda fonte è lo stesso approfondimento di TT Lab sui registry container nel 2026, che analizza nel dettaglio come Cosign e Sigstore si siano affermati come standard de facto per la firma delle immagini, mentre Notary v2 e in-toto vengono trattati come tecnologie complementari per la sicurezza della supply chain più ampia. Secondo questa analisi, Docker Content Trust è di fatto già deprecato nella pratica, molto prima della sua dismissione formale di dicembre 2026, perché la comunità si è spostata su alternative più moderne con largo anticipo.
La terza fonte riguarda il contesto di mercato più ampio in cui si inserisce questa tecnologia. Secondo i dati di MarketsandMarkets, il mercato italiano del Managed Detection and Response, che include servizi di sicurezza legati anche alla protezione della supply chain software, era valutato 114,7 milioni di dollari nel 2026 con una proiezione a 334,3 milioni di dollari entro il 2031, corrispondente a un tasso di crescita annuo composto del 23,9%. Non è una misura diretta dell’adozione di Cosign o Notation, ma conferma che gli investimenti in sicurezza operativa in Italia, categoria in cui rientra la firma della supply chain, stanno crescendo a un ritmo sostenuto piuttosto che stagnare.
Mettendo insieme queste tre angolazioni, il quadro che emerge è coerente, Cosign si è affermato come lo strumento di riferimento per chi deve firmare container in modo trasversale, Notation resta la scelta naturale per chi opera dentro ecosistemi registry specifici come Azure o Quay, e in-toto cresce lentamente ma in modo costante come livello aggiuntivo per chi deve rispondere a requisiti di conformità più severi.
Cosa dice il settore sulla firma dei container
Al di là delle metriche sui singoli progetti, diversi studi di settore pubblicati negli ultimi anni fotografano quanto la firma dei container sia passata da pratica di nicchia a elemento sempre più diffuso nelle organizzazioni che gestiscono pipeline container in produzione.
Uno dei primi segnali arriva dal report di VMware “The State of the Software Supply Chain: Open Source Edition” del 2021, che rilevava come “31% of respondents reported using signing and verifying signatures or notary technologies for open-source software security” (VMware). Un numero relativamente basso per l’epoca, ma che segnava già l’inizio di un interesse concreto ben prima che Sigstore diventasse mainstream.
Due anni dopo, la Open Source Security Foundation pubblicava i risultati del suo sondaggio sulla sicurezza della supply chain, trovando che “25% of respondents reported that their teams always sign built artifacts” (OpenSSF). Il salto rispetto al dato VMware di due anni prima suggerisce un’accelerazione reale nell’adozione, non solo un cambio di metodologia tra i due sondaggi.
Il report sullo stato della sicurezza Kubernetes pubblicato da Red Hat nel 2024 aggiunge un dettaglio più specifico sugli strumenti usati, “23% of respondents identified Tekton Chains or Sigstore/Cosign as signing or attestation tools used for software supply-chain security” (Red Hat). Questo dato conferma che, già nel 2024, Cosign era tra gli strumenti di firma esplicitamente nominati dai team Kubernetes intervistati, molto prima che la dismissione di Docker Content Trust rendesse la scelta quasi obbligata.
Più recentemente, il report sullo stato della sicurezza cloud-native 2026 di Red Hat ha rilevato un’accelerazione netta, “49% of surveyed organizations reported currently using container image signing and verification” (Red Hat). Quasi metà delle organizzazioni intervistate firma e verifica oggi le proprie immagini, un balzo enorme rispetto al 23% del 2024 legato specificamente a Cosign e Tekton Chains.
Un’ultima prospettiva, più sfumata, arriva dal report 2026 di DigiCert sullo stato della sicurezza della supply chain software, “12% of respondents said they always sign container images, while 32% said they do so sometimes” (DigiCert). Sommando le due percentuali si arriva al 44% di organizzazioni che firmano almeno occasionalmente le proprie immagini, un dato che resta coerente con il 49% rilevato da Red Hat nello stesso periodo, pur misurando la domanda in modo leggermente diverso.
Il filo conduttore tra questi cinque dati, raccolti su un arco di cinque anni e da organizzazioni diverse, è una traiettoria di crescita costante, si parte da un 31% generico nel 2021 per arrivare a quasi la metà delle organizzazioni che firmano i propri container nel 2026. La dismissione di Docker Content Trust arriva quindi in un momento in cui l’adozione della firma dei container, lungi dall’essere frenata, sta semplicemente cambiando strumento di riferimento.
| Anno | Fonte | Dato rilevato |
|---|---|---|
| 2021 | VMware | 31% usa firma o tecnologie notary per la sicurezza open source |
| 2023 | Open Source Security Foundation | 25% firma sempre gli artefatti costruiti |
| 2024 | Red Hat (Kubernetes Security Report) | 23% usa Tekton Chains o Sigstore/Cosign |
| 2026 | Red Hat (Cloud-Native Security Report) | 49% firma e verifica oggi le proprie immagini |
| 2026 | DigiCert | 12% firma sempre, 32% firma a volte (44% combinato) |
Letta in sequenza, questa tabella racconta meglio di qualsiasi singolo numero quanto velocemente la firma dei container sia passata da pratica marginale a comportamento quasi maggioritario. Nessuno dei cinque studi misura esattamente la stessa popolazione di organizzazioni con la stessa metodologia, ma la direzione del trend è identica in ciascuno di essi, e questo conta più della precisione del singolo punto percentuale.
Costi e modelli di prezzo: cosa cambia davvero
Tutti e tre gli strumenti condividono una caratteristica di fondo, sono progetti open source e il software in sé non ha un costo di licenza. Quello che cambia, e che spesso viene sottovalutato in fase di valutazione, è il costo operativo dell’infrastruttura necessaria a farli funzionare bene in un ambiente di produzione.
| Voce di costo | Cosign (Sigstore) | Notation (Notary v2) | in-toto |
|---|---|---|---|
| Licenza del software | Gratuita, open source | Gratuita, open source | Gratuita, open source |
| Infrastruttura di firma | Istanza pubblica gratuita di Fulcio/Rekor, oppure self-hosted | Richiede un servizio KMS esterno o il trust store nativo del registry | Gestione chiavi per ogni step, spesso con hardware token |
| Dipendenza dal registry | Nessuna, funziona con qualsiasi registry OCI | Vantaggio massimo con Azure Container Registry o Quay | Nessuna, opera a livello di pipeline |
| Costo di integrazione CI/CD | Basso, una riga di comando aggiuntiva | Medio, richiede configurazione di trust policy | Alto, richiede mappatura completa della pipeline |
| Supporto enterprise | Disponibile tramite vendor terzi specializzati in Sigstore | Disponibile tramite Red Hat per lo stack Quay | Generalmente gestito internamente o tramite integratori |
Il punto chiave è che il costo nascosto più significativo non è quasi mai il prezzo del tool, ma il tempo ingegneristico necessario a integrarlo correttamente. Cosign, grazie alla firma keyless e all’infrastruttura Sigstore pubblica gratuita, minimizza questo costo per i casi d’uso più comuni, un team può iniziare a firmare immagini in una pipeline GitHub Actions con poche righe di configurazione, senza dover gestire alcuna chiave o pagare per servizi aggiuntivi.
Notation sposta parte di quel costo verso il registry, se l’organizzazione usa già Azure Container Registry a un livello che supporta le trust policy, il costo incrementale è contenuto, ma se serve fare l’upgrade del piano del registry o migrare verso Quay per ottenere il supporto nativo, quel costo va messo in conto separatamente e varia da fornitore a fornitore.
in-toto, infine, è quello con il costo di adozione iniziale più alto in termini di ore ingegneristiche, perché richiede di documentare e strutturare l’intera pipeline prima di ottenere il primo beneficio tangibile. Per organizzazioni che devono dimostrare conformità SLSA Level 3, questo costo è spesso già previsto nel budget di compliance, mentre per chi non ha quell’obbligo specifico può risultare uno sforzo sproporzionato rispetto al beneficio immediato.
Cinque esempi concreti di utilizzo in produzione
Al di là della teoria, vale la pena guardare a come questi strumenti vengono effettivamente impiegati in scenari reali, dalla pipeline CI/CD fino al cluster Kubernetes in produzione.
- Firma keyless in GitHub Actions. Un pattern diffuso consiste nell’usare Cosign dentro una pipeline GitHub Actions, sfruttando l’identità OIDC del workflow stesso per firmare l’immagine appena costruita, senza mai generare o conservare una chiave privata nel repository. È l’esempio più citato nelle guide DevSecOps moderne proprio perché elimina il problema storico della gestione delle chiavi nei sistemi CI.
- Trust policy native su Azure Container Registry. Team che operano già dentro l’ecosistema Microsoft usano Notation per imporre, a livello di registry, che solo le immagini firmate possano essere distribuite ai cluster AKS collegati, bloccando sul nascere il pull di artefatti non verificati prima ancora che raggiungano l’ambiente di produzione.
- Verifica centralizzata su Quay. Red Hat Quay integra Notation per offrire verifica delle firme a livello di piattaforma, uno scenario tipico di organizzazioni enterprise che vogliono un unico punto di controllo per tutte le immagini che transitano dal registry interno.
- Ammissione Kubernetes basata su firma. Diversi progetti open source combinano Cosign con Open Policy Agent per creare admission controller che verificano la firma dell’immagine prima di permettere la creazione di un pod, rifiutando il deploy se la verifica fallisce. Questo pattern compare ripetutamente tra i progetti catalogati sotto il topic Cosign di GitHub, segno di quanto sia diventato uno schema riconosciuto.
- Attestazione di pipeline per conformità SLSA Level 3. Organizzazioni con requisiti normativi stringenti, pensiamo a settori come finanza e difesa in ambito europeo dove NIS2 impone controlli più severi sulla supply chain, strutturano layout in-toto che tracciano ogni fase della build, dal checkout del codice sorgente fino alla pubblicazione dell’immagine finale, per poter dimostrare in audit la provenienza completa del software distribuito.
- Infrastruttura pubblica gratuita per progetti open source. Molti mantainer di progetti open source si appoggiano all’istanza pubblica gratuita di Fulcio e Rekor gestita da Sigstore, evitando di dover gestire in proprio un’infrastruttura di certificazione. Questo abbassa drasticamente la barriera d’ingresso per chi vuole iniziare a firmare i propri rilasci senza alcun budget dedicato alla sicurezza della supply chain.
Questi cinque scenari non sono mutuamente esclusivi. Anzi, le organizzazioni più mature nella sicurezza della supply chain tendono a combinarli, Cosign per la firma dell’artefatto, Notation o le trust policy del registry per imporre il controllo a livello infrastrutturale, in-toto per la parte di attestazione documentale richiesta in fase di audit.
Cosa cambia per le aziende italiane ed europee sotto NIS2
Per le organizzazioni italiane ed europee che rientrano nel perimetro NIS2, dai fornitori di infrastrutture digitali alla pubblica amministrazione fino a settori come energia, trasporti e sanità, la scelta tra Cosign, Notation e in-toto non è solo una questione tecnica, ma anche un modo per rispondere in modo documentabile a un obbligo normativo. NIS2 non impone un elenco chiuso di strumenti, ma chiede misure concrete di gestione del rischio sulla catena di fornitura, incluse quelle legate allo sviluppo e alla distribuzione del software.
In questo contesto, i tre strumenti coprono tre livelli diversi della stessa richiesta normativa. Firmare le immagini con Cosign dimostra che il software distribuito non è stato alterato dopo la pubblicazione. Imporre trust policy a livello di registry con Notation dimostra che l’organizzazione applica un controllo centralizzato e non lasciato alla discrezione del singolo sviluppatore. Attestare l’intera pipeline con in-toto dimostra la provenienza end-to-end richiesta dagli auditor più esigenti, in particolare in settori dove un incidente alla supply chain software avrebbe conseguenze dirette sulla sicurezza fisica o sulla continuità di servizi essenziali.
| Esigenza di conformità | Strumento più rilevante | Cosa dimostra in audit |
|---|---|---|
| Integrità dell’artefatto distribuito | Cosign | L’immagine non è stata modificata dopo la firma |
| Controllo centralizzato sul registry | Notation | Solo immagini firmate raggiungono i cluster di produzione |
| Provenienza end-to-end della build | in-toto | Chi ha eseguito ogni fase della pipeline e con quale autorizzazione |
| Conformità SLSA Level 3 | in-toto, spesso insieme a Cosign | Catena di custodia verificabile dell’intero processo |
Il margine di tempo prima dell’8 dicembre 2026 è anche un’occasione pratica per queste organizzazioni, pianificare la migrazione da Docker Content Trust nello stesso ciclo di lavoro in cui si implementano i controlli richiesti da NIS2 evita di dover affrontare due progetti separati, uno di adeguamento tecnico e uno di conformità normativa, quando in realtà rispondono entrambi alla stessa esigenza di fondo.
Quando scegliere Cosign
Cosign è la scelta di default per la maggior parte dei team che partono da zero nel 2026. Se la priorità è iniziare a firmare le immagini il prima possibile, senza investire tempo in infrastruttura di gestione chiavi, la combinazione tra firma keyless e infrastruttura Sigstore pubblica gratuita rende l’adozione quasi immediata.
È la scelta giusta anche per chi opera su registry eterogenei o non vuole legarsi a un singolo vendor, funzionando con qualsiasi registry compatibile OCI, Cosign non impone vincoli sulla scelta infrastrutturale a valle. Team open source, startup e organizzazioni che pubblicano su più registry contemporaneamente, da Docker Hub a GitHub Container Registry, trovano in Cosign lo strumento con meno attrito operativo. Anche chi opera in ambienti con restrizioni di connettività beneficia della nuova modalità offline introdotta con la versione 2.6, che permette la verifica senza accesso continuo ai servizi Sigstore pubblici.
Quando scegliere Notation
Notation conviene quando l’organizzazione è già profondamente integrata in un ecosistema che lo supporta nativamente, in particolare Azure Container Registry o Quay di Red Hat. In questi contesti il vantaggio pratico è concreto, la trust policy si configura a livello di registry, non serve modificare ogni singola pipeline CI/CD o cluster per imporre la verifica, e il controllo diventa parte dell’infrastruttura condivisa invece che una responsabilità distribuita tra i vari team.
È una scelta sensata anche per organizzazioni enterprise che preferiscono una gestione delle chiavi più tradizionale, basata su KMS, rispetto al modello keyless di Cosign, magari per motivi di policy interna o di requisiti normativi specifici del proprio settore. Il limite da tenere a mente è la dipendenza dal registry, se in futuro l’organizzazione dovesse cambiare provider verso uno che non supporta Notation nativamente, parte del valore dell’investimento andrebbe ricostruito altrove.
Quando scegliere in-toto, o tutti e tre insieme
in-toto diventa indispensabile quando la domanda non è più “questa immagine è autentica?” ma “posso dimostrare l’intera catena di custodia del software che sto distribuendo?”. È lo strumento giusto per organizzazioni regolamentate che devono rispondere a framework di conformità come SLSA Level 3, un requisito sempre più comune in settori critici e nella pubblica amministrazione europea sotto la pressione di NIS2.
Per team più piccoli senza obblighi di conformità specifici, adottare in-toto da subito può essere eccessivo rispetto al beneficio immediato. In questi casi la strategia più comune è partire con Cosign per la firma di base, aggiungere eventualmente Notation o le trust policy del registry quando l’infrastruttura lo giustifica, e introdurre in-toto solo nel momento in cui emerge un requisito di conformità concreto, anziché implementarlo in anticipo su un processo che potrebbe ancora cambiare. Le organizzazioni che finiscono per usare tutti e tre insieme lo fanno quasi sempre per questo motivo, ogni strumento è arrivato in risposta a un’esigenza specifica emersa in momenti diversi della crescita dell’organizzazione, non per una decisione architetturale presa a tavolino il primo giorno.
Guida alla migrazione da Docker Content Trust
Per chi usa ancora Docker Content Trust, i mesi che precedono l’8 dicembre 2026 sono la finestra pratica per pianificare la transizione senza farsi trovare impreparati. Ecco un percorso ragionevole in otto passaggi.
- Censire l’uso attuale di Docker Content Trust, quali repository, quali pipeline e quali cluster dipendono oggi dalla verifica DCT per funzionare correttamente.
- Scegliere lo strumento sostitutivo in base al registry in uso, Notation se si opera già su Azure Container Registry o Quay, Cosign per tutti gli altri scenari o per chi vuole restare agnostico rispetto al registry.
- Impostare l’infrastruttura di firma, per Cosign significa decidere tra la firma keyless con l’istanza pubblica Sigstore o una configurazione self-hosted, per Notation significa collegare un servizio KMS o il trust store nativo del registry.
- Integrare il passaggio di firma nella pipeline CI/CD esistente, partendo da un singolo repository pilota prima di estendere la modifica a tutte le pipeline dell’organizzazione.
- Configurare la verifica lato cluster, tipicamente tramite un admission controller Kubernetes che rifiuta il deploy di immagini non firmate o non conformi alla policy definita.
- Se richiesto da obblighi di conformità, aggiungere attestazioni in-toto per i passaggi critici della pipeline, concentrandosi prima sugli step a più alto rischio come il checkout del codice sorgente e la fase di build.
- Eseguire un periodo di affiancamento in cui sia il vecchio meccanismo DCT sia il nuovo strumento restano attivi in parallelo, per verificare che nessuna pipeline dipenda ancora in modo nascosto dal vecchio sistema.
- Disattivare definitivamente Docker Content Trust prima dell’8 dicembre 2026, documentando il passaggio per eventuali audit di conformità successivi legati a NIS2 o ad altri requisiti normativi di settore.
Il passaggio chiave, spesso sottovalutato, è il quinto, migrare lo strumento di firma senza aggiornare anche il punto di verifica lato cluster lascia l’organizzazione con una firma che nessuno controlla davvero, il che vanifica gran parte del beneficio dell’intera operazione.
Pro e contro a confronto
Cosign
- Firma keyless senza gestione di chiavi a lungo termine
- Funziona con qualsiasi registry compatibile OCI
- Copertura ampissima di oggetti firmabili, dalle immagini ai chart Helm
- Sviluppo molto attivo, con rilasci e commit recenti
- Comunità open source più ampia tra i tre strumenti
- La verifica keyless dipende dalla corretta configurazione delle policy OIDC
- Non copre da solo l’attestazione dell’intera pipeline di build
Notation
- Integrazione nativa con il modello degli artefatti OCI
- Controllo centralizzato a livello di registry su Azure Container Registry e Quay
- Gestione delle chiavi più tradizionale per chi preferisce un modello KMS classico
- Vantaggio massimo solo su un numero ristretto di registry
- Comunità più piccola, circa 477 stelle GitHub nel confronto citato sopra
- Meno flessibile se l’organizzazione cambia provider di registry
in-toto
- Unico strumento tra i tre pensato per attestare l’intera pipeline, non solo l’artefatto finale
- Allineato ai requisiti di SLSA Level 3
- Indipendente dal registry, opera a livello di processo
- Costo di adozione iniziale più alto in ore ingegneristiche
- Richiede di mappare e mantenere aggiornato un layout completo della pipeline
- Spesso eccessivo per organizzazioni senza obblighi di conformità specifici
Il verdetto finale: quale scegliere nel 2026
Guardando i numeri raccolti in questo confronto, il quadro è abbastanza chiaro. Cosign, con circa 5.834 stelle GitHub contro le 477 di Notation e le 994 di in-toto, un rilascio recente il 6 agosto 2026 e un commit registrato appena tre giorni prima della pubblicazione di questo articolo, si è affermato come lo strumento di riferimento per la maggior parte dei team che devono firmare container nel 2026. La combinazione tra firma keyless, copertura ampia di oggetti firmabili e indipendenza dal registry lo rende la scelta più pragmatica per chi parte da zero o vuole sostituire rapidamente Docker Content Trust prima della sua dismissione dell’8 dicembre 2026.
Questo non significa che Notation e in-toto siano scelte minori. Notation resta la decisione più sensata per chi opera già dentro Azure Container Registry o Quay e vuole un controllo centralizzato a livello di registry, mentre in-toto rimane l’unico strumento in grado di rispondere a requisiti di conformità SLSA Level 3 che Cosign da solo non copre. Il dato del 49% di organizzazioni che oggi firmano e verificano le proprie immagini, rilevato da Red Hat nel suo report 2026 sulla sicurezza cloud-native, conferma che la domanda non è più se firmare i container, ma con quale strumento e a quale livello di profondità farlo.
Per la maggior parte delle organizzazioni europee che si preparano alla scadenza di dicembre, la strategia più sensata resta pragmatica, iniziare con Cosign per coprire rapidamente la firma di base, valutare Notation se l’infrastruttura di registry lo giustifica, e riservare in-toto al momento in cui un requisito di conformità concreto lo rende necessario, piuttosto che cercare di implementare tutto in un’unica fase.
Domande frequenti
Cosign, Notation e in-toto sono tra loro alternativi o si possono usare insieme?
Non sono mutuamente esclusivi. Molte organizzazioni mature li combinano, Cosign per firmare l’artefatto, Notation o le trust policy del registry per imporre il controllo a livello infrastrutturale, in-toto per l’attestazione documentale dell’intero processo di build.
Cosa succede se continuo a usare Docker Content Trust dopo l’8 dicembre 2026?
Docker Content Trust verrà ritirato da quella data, quindi le pipeline che dipendono ancora da quel meccanismo smetteranno di ricevere supporto e verifica attiva. Dato che meno dello 0,05% dei pull su Docker Hub lo usava, l’impatto pratico sulla maggior parte degli utenti dovrebbe essere limitato, ma chi lo usa attivamente deve migrare prima della scadenza.
La firma keyless di Cosign è sicura quanto una firma con chiave tradizionale?
Il modello keyless sposta la fiducia dalla custodia di una chiave privata alla sicurezza del provider OIDC usato per autenticarsi e alla trasparenza del log Rekor, che registra pubblicamente ogni evento di firma. Per molte organizzazioni questo riduce il rischio legato al furto o smarrimento di chiavi a lungo termine, anche se la sicurezza finale dipende comunque dalla corretta configurazione delle policy di identità.
Notation funziona solo con Azure Container Registry e Quay?
No, essendo basato sullo standard OCI artifacts, Notation può in teoria funzionare con qualsiasi registry compatibile. In pratica, però, il supporto nativo delle trust policy e l’integrazione più fluida restano concentrati su Azure Container Registry e Quay di Red Hat, dove l’adozione è più avanzata.
Serve davvero in-toto se uso già Cosign per firmare le immagini?
Dipende dal requisito. Cosign certifica che l’immagine finale non è stata alterata dopo la firma, ma non dimostra da solo cosa sia accaduto durante ogni fase della build. Se l’organizzazione deve rispondere a requisiti di conformità come SLSA Level 3, in-toto resta necessario per coprire quella parte specifica.
Quanto costa realisticamente adottare uno di questi strumenti?
Il software è gratuito in tutti e tre i casi. Il costo reale riguarda l’infrastruttura di supporto e il tempo ingegneristico di integrazione, Cosign minimizza entrambi grazie all’infrastruttura Sigstore pubblica gratuita, Notation richiede un allineamento con il registry scelto, in-toto richiede il costo più alto in termini di mappatura e manutenzione della pipeline.
NIS2 impone esplicitamente l’uso di questi strumenti?
NIS2 non nomina strumenti specifici, ma richiede alle organizzazioni critiche di dimostrare controlli concreti sulla sicurezza della supply chain digitale. Firma delle immagini e attestazione della pipeline di build sono tra i mezzi più diretti per fornire quella dimostrazione in sede di audit.
Qual è il modo più semplice per iniziare se non ho mai firmato un’immagine container?
Cosign resta il punto di partenza più accessibile, con la firma keyless e l’infrastruttura Sigstore pubblica gratuita, è possibile firmare e verificare la prima immagine aggiungendo poche righe a una pipeline CI/CD esistente, senza dover prima costruire alcuna infrastruttura di gestione chiavi.