Sintesi Tecnica: La Soglia dell'Involucro di Custodia (The Custody Envelope Threshold)

Definizione del Problema

Le moderne infrastrutture istituzionali si affidano pesantemente ad artefatti mantenuti esternamente (ad esempio, dipendenze di pacchetti, immagini di container, azioni CI/CD, moduli Terraform, pesi dei modelli). Sebbene questi artefatti siano banali da recuperare e comporre per un singolo sviluppatore, le istituzioni faticano ad ammetterli, governarli, revocarli o difenderli dopo un fallimento. Gli attuali framework come SLSA, NIST SSDF e il modello S2C2F di Microsoft si concentrano sull'integrità del produttore, sulle pratiche di sviluppo sicure o sulla maturità del consumo sicuro. Tuttavia, essi non riescono a spiegare un cruciale enigma empirico: perché classi di artefatti comparabili producono esiti istituzionali divergenti. Alcuni artefatti vengono ammessi direttamente, altri sono mediati da proxy, da policy, da vendor o internalizzati, oppure vengono rifiutati. Il documento sostiene che la letteratura attuale manca di un modello descrittivo-predittivo che spieghi perché diverse classi di artefatti si vincolino a diverse condizioni di custodia e come le istituzioni selezionino le modalità di governance in risposta.

Metodologia

Il documento propone l'Involucro di Custodia (Custody Envelope Threshold), un modello di ammissione degli artefatti scalato sull'autorità. La metodologia è strutturata come segue:

1. Lineage Teorico: Il modello sintetizza la tradizione del monitor di riferimento (least privilege, completezza della mediazione) e l'economia dei costi di transazione (modalità di governance come scelte istituzionali comparative).
2. Lo Strumento: Un strumento ordinale a quattro condizioni valuta gli artefatti in un contesto d'uso specifico:
   • Autorità di Esecuzione ($A$): Il livello di privilegio che l'artefatto riceve (0: non esecutivo a 3: produzione/infrastruttura privilegiata).
   • Identità dell'Oggetto ($I$): La stabilità e la verificabilità dell'identità dell'artefatto (0: instabile/implicita a 3: verificabile/vincolata a policy).
   • Percorso di Ingress ($G$): Il controllo su come l'artefatto entra nell'istituzione (0: recupero pubblico diretto a 3: confine garantito da policy).
   • Capacità di Revoca ($R$): La capacità di bloccare, rimuovere o sostituire l'artefatto dopo l'ammissione (0: nessun percorso a 3: revoca rapida e verificabile).
3. La Regola di Chiusura: L'ammissione istituzionale diretta è difendibile solo se l'anello più debole della custodia soddisfa la soglia di autorità:
   $$\min(I, G, R) \ge A$$
   Se questa condizione fallisce ($D = A - \min(I, G, R) > 0$), esiste un "deficit di custodia".
4. Euristica di Selezione della Governance: Quando l'ammissione diretta fallisce, l'istituzione seleziona la modalità di governance con il minor onere capace di colmare il deficit. Questa selezione dipende da:
   • Specificità della Custodia Locale ($S$): Quanta conoscenza specifica dell'istituzione è necessaria per un uso sicuro (0: commodity a 3: specifica dell'istituzione).
   • Disponibilità di Chiusura Esterna: Se un fornitore esterno può fornire il confine mancante.
   • Scrutinio Istituzionale ($Q$): Il livello di revisione esterna/interna.
5. Derivazione e Validazione: Il modello viene applicato a sei casi di derivazione (dipendenze di pacchetti, GitHub Actions, immagini di container, provider/moduli Terraform, estensioni per sviluppatori, artefatti di modelli open) ed è sottoposto a stress test contro i flussi curl | bash ed è valutato rispetto a evidenze trattenute (held-out) dai server del Model Context Protocol (MCP). Viene proposto un design di validazione che prevede la codifica indipendente di input e output per testare quattro ipotesi riguardanti la scalabilità dell'autorità, i deficit di vincolo, la dipendenza dal contesto e l'interazione dello scrutinio.

Contributi Chiave

• Modello Descrittivo-Predittivo: A differenza dei framework di maturità prescrittivi (es. S2C2F), questo documento offre un modello che predice perché le istituzioni scelgono specifiche modalità di governance (proxy, mediate da policy, mediate da vendor, internalizzate, in quarantena) basandosi sull'interazione tra autorità dell'artefatto e chiusura della custodia.
• Custodia Scalata sull'Autorità: Il documento stabilisce che i requisiti di custodia non sono statici; essi scalano con l'autorità di esecuzione delegata all'artefatto. Un artefatto a bassa autorità richiede controlli modesti, mentre artefatti ad alta autorità richiedono identità forte, ingresso controllato e rapida revoca.
• Tassonomia delle Modalità di Governance: Definisce sei distinti esiti di governance non come etichette arbitrarie, ma come risposte economiche ai deficit di custodia sotto autorità delegata.
• Strumento Operativo: Fornisce una rubrica di punteggio deterministica (0–3) per identità, ingresso, revoca e specificità, permettendo la predizione meccanica delle modalità primarie di governance.
• Evidenza Trattenuta (MCP): Il documento introduce i server del Model Context Protocol (MCP) come classe di artefatto trattenuta, dimostrando che le emergenti superfici di governance (registri, gateway, autorizzazione granulare) si stanno materializzando esattamente come previsto dal modello per gli strumenti AI ad alta autorità.

Risultati e Osservazioni

L'applicazione del framework ai sei casi di derivazione produce i seguenti pattern:

• Dipendenze di Pacchetti: Esibiscono tipicamente deficit di ingresso e di risoluzione del namespace. Il modo predetto e osservato è Proxy (feed interni, mirror).
• GitHub Actions: Spesso affrontano deficit di identità mutabile e di alta autorità. Il modo predetto è Mediato da Policy (pinning del full-SHA, allowlist) o In Quarantena.
• Immagini di Container: Frequentemente soffrono di deficit di revoca e di ingresso. Il modo è Proxy con controlli di runtime curati.
• Provider Terraform: Nonostante l'alta autorità, la forte identità (firma) e l'ingresso (mirror) permettono l'Ammissione con distribuzione firmata/bloccata.
• Moduli Terraform: Si vincolano sulla specificità della custodia locale (conoscenza architettonica). Il modo è Internalizzato (copiato/avvolto internamente).
• Estensioni per Sviluppatori: Affrontano deficit di autorità dell'endpoint e di controllo degli aggiornamenti. Il modo è Mediato da Policy o Mediato da Catalogo.
• Artefatti di Modelli Open: Spesso mancano di meccanismi di caricamento sicuri e percorsi di revoca per contesti ad alta autorità. Il modo è Mediato da Vendor (cataloghi gestiti) o In Quarantena.
• Server MCP (Held-Out): Le prime evidenze suggeriscono che i server MCP ad alta autorità si stanno muovendo verso una governance Mediata da Vendor (gateway, cataloghi) man mano che l'ecosistema matura.

Il documento nota che "curl | bash" persiste nei contesti a basso scrutinio, ma viene trasformato o bloccato negli ambienti ad alto scrutinio, confermando la previsione del modello secondo cui lo scrutinio guida la convergenza verso una custodia più forte.

Significato e Rivendicazioni

Il documento rivendica lo spostamento dell'unità di analisi dall' "approvazione dell'open source" all' "ammissione della classe di artefatto". Il suo significato centrale risiede nel fornire un framework falsificabile che spieghi la divergenza istituzionale:

1. Falsificabilità: Il modello è indebolito se le istituzioni ad alto scrutinio ammettono regolarmente artefatti ad alta autorità con debole chiusura della custodia senza mediazione. Al contrario, è indebolito se la forte chiusura della custodia non correla con l'ammissione.
2. Economia della Governance: Inquadra le decisioni di sicurezza come scelte economiche in cui le istituzioni selezionano le modalità di governance per minimizzare l'onere di chiudere i deficit di custodia rispetto alla tolleranza al rischio.
3. Potere Predittivo: Il framework predice che il recupero pubblico diretto declinerà nei percorsi di produzione seri, sostituito da proxy, registri curati e gateway, anche mentre l'uso di artefatti pubblici aumenta.
4. Distinzione dal Lavoro Precedente: Si distingue da SLSA e NIST SSDF concentrandosi sulla decisione di ammissione e sulla divergenza degli esiti tra le classi di artefatti, piuttosto che solo sull'integrità del produttore o sulle pratiche di sviluppo sicure.

Il documento conclude che le istituzioni non ammettono artefatti esterni semplicemente perché sono utili; li ammettono solo quando l'utilità può essere convertita in una custodia scalata sull'autorità a un onere di governance accettabile.