Come si presenta una catena di fornitura di fornitori di intelligenza artificiale di livello bancario (angolo DORA)

Perché la filiera del software è una questione DORA¶

DORA è stata adottata il 14 dicembre 2022 e si applica alle entità finanziarie dell'UE dal 17 gennaio 2025. Il suo capitolo V, "Gestione del rischio ICT di terze parti", regola il modo in cui un'entità finanziaria stipula contratti per tecnologia esterna. Le definizioni fanno il lavoro iniziale. L'articolo 3(19) definisce un fornitore di servizi ICT di terze parti come "un'impresa che fornisce servizi ICT", una definizione sufficientemente ampia da coprire essenzialmente tutti i fornitori di IA. L'articolo 3(22) definisce una funzione essenziale o importante come quella la cui interruzione, o il cui adempimento interrotto, difettoso o mancato, comprometterebbe materialmente la performance finanziaria dell'entità, la solidità o la continuità dei suoi servizi, o il suo continuo rispetto delle condizioni della sua autorizzazione. Un sistema di intelligenza artificiale che esamina le transazioni, valuta gli avvisi antiriciclaggio o rilascia i pagamenti gate supporterà spesso tale funzione una volta che la banca esegue l’autovalutazione documentata.

Questa classificazione alza il livello dell’intero impegno. L'articolo 28(4) impone all'entità finanziaria, prima di stipulare il contratto, di identificare e valutare tutti i rischi rilevanti e di intraprendere ogni due diligence sul potenziale fornitore. L’articolo 28(5) consente di stipulare contratti solo con fornitori che rispettano adeguati standard di sicurezza delle informazioni e richiede, per funzioni critiche o importanti, la dovuta considerazione dell’utilizzo da parte del fornitore degli standard di sicurezza delle informazioni più aggiornati e di altissima qualità. L’articolo 30(3)(c) obbliga poi il contratto stesso, laddove siano supportate funzioni essenziali o importanti, a richiedere al fornitore di dotarsi di misure, strumenti e politiche di sicurezza ICT in linea con il quadro normativo dell’ente.

Una pipeline di build del fornitore compromessa o non verificabile è una via diretta verso i danni a cui mirano tali disposizioni. Se il fornitore non è in grado di indicare quale esatto elemento viene eseguito in produzione, la banca non può rispondere ai propri obblighi di gestione delle modifiche e di patch ai sensi dell'articolo 9(4)(e) e (f) per la funzione esternalizzata, non può definire l'ambito di una segnalazione di incidenti gravi ai sensi dell'articolo 19 alle versioni interessate e non può onorare i diritti di audit che l'articolo 30(3)(e) richiede che il contratto conceda. Le prove della catena di fornitura sono quindi materiale di valutazione per il file dell’articolo 28 della banca piuttosto che per il marketing del fornitore.

Build riproducibili: la stessa fonte produce lo stesso digest¶

Una build è riproducibile quando una ricostruzione indipendente della stessa revisione di origine produce un artefatto identico in bit, che per le immagini contenitore significa lo stesso digest dell'immagine. La riproducibilità converte il concetto di "fiducia nella nostra pipeline" in una proprietà che chiunque può testare. Se una ricostruzione dall'origine pubblicata produce il digest in esecuzione, non è stato inserito nulla tra la revisione dell'origine e la produzione e all'interno dell'artefatto non si trova alcun flag del compilatore non revisionato, deriva delle dipendenze o patch manuale.

L'ingegneria dietro di esso è specifica e verificabile. I timestamp della build sono fissati alla revisione del sorgente anziché all'orologio a muro, quindi due build dello stesso commit incorporano gli stessi orari. Il builder stesso è bloccato dal digest, quindi la toolchain non può spostarsi silenziosamente. I timestamp dei livelli vengono riscritti sul valore bloccato. Le dipendenze vengono risolte da un file di blocco e la build rifiuta gli input non bloccati. Nella pipeline di rilascio di KLA, un gate di riproducibilità esegue due ricostruzioni pulite di ciascuna immagine del servizio di prima parte coperta con le cache disabilitate e fallisce il rilascio quando i digest differiscono e il digest di rilascio deve essere uguale al digest ricostruito prima della promozione.

Per un revisore DORA, la riproducibilità è alla base del diritto di audit dell'articolo 28(6) con qualcosa di più forte delle prove dell'intervista: l'audit può rieseguire la build. Fornisce inoltre contenuto reale all'Articolo 30(2)(a) della descrizione del servizio, perché "il software che forniamo" si risolve in un digest invece che in una stringa di versione digitata da un essere umano.

• Prova da richiedere: l'output del controllo di riproducibilità per una versione recente che mostra il digest di ricostruzione è uguale al digest di rilascio.
• Prova da richiedere: la configurazione della pipeline che dimostri timestamp di build bloccati, builder bloccati digest e dipendenze bloccate.
• Prova da richiedere: la dichiarazione dell'ambito: quali immagini sono coperte dal cancello di riproducibilità e qual è il piano per il resto.
• Bandiera rossa: un fornitore che non può nominare il digest attualmente in esecuzione per il proprio servizio.

Immagini firmate, verificate dove conta: all'ammissione¶

Una firma su un'immagine del contenitore associa l'artefatto a un'identità. Cosign di Sigstore è diventato lo strumento comune: la pipeline firma il digest dell'immagine dopo la creazione e la verifica controlla sia la firma che l'identità del firmatario. La firma senza chiave rafforza la rivendicazione dell'identità, poiché il certificato viene emesso rispetto all'identità OIDC del sistema CI per un repository e un flusso di lavoro specifici, quindi la firma afferma "costruito da questa pipeline su questo ramo" anziché "firmato da chiunque detenga un file di chiave".

La sola firma è decorativa a meno che qualcosa non si rifiuti di eseguire artefatti non firmati. Il punto di applicazione che conta è l’ammissione al cluster. Un controller di ammissione Kubernetes, Kyverno nella distribuzione di KLA, verifica la firma su ogni immagine di prima parte prima che il pod venga ammesso, risolve i tag in digest immutabili, quindi ciò che è stato verificato è ciò che viene eseguito e fallisce chiuso in produzione: quando la policy non può essere valutata, il carico di lavoro non viene avviato. L'implementazione avviene in più fasi, con l'osservazione in modalità di controllo in fase di sviluppo prima dell'applicazione negli spazi dei nomi di produzione.

Questo è il controllo che un team bancario dovrebbe approfondire più attentamente, perché converte l'intera storia della firma dal processo alla fisica. Inoltre si mappa in modo pulito sul linguaggio DORA: l'articolo 9(4)(e) richiede controlli documentati di gestione delle modifiche che garantiscano che le modifiche ai sistemi ICT siano registrate, testate, valutate, approvate, implementate e verificate in modo controllato, e la verifica del momento di ammissione è il passaggio "verificato" reso meccanico. Per il contratto si tratta di una misura di sicurezza concreta (Articolo 30(3)(c) la cui configurazione può essere letta da un revisore dei conti.

I percorsi negativi meritano uguale attenzione. Chiedi cosa succede quando la verifica fallisce, quando il registro di trasparenza della firma non è raggiungibile e quando qualcuno tenta di distribuire un'immagine creata al di fuori della pipeline sanzionata. Una risposta di livello bancario mostra un evento di ammissione bloccato e un avviso e il fornitore dovrebbe essere in grado di dimostrare il blocco su richiesta. L'avviso sulla policy di verifica stessa, in modo che una policy disabilitata silenziosamente avvisi qualcuno, chiude il ciclo.

Provenienza e SBOM: cos'è e da dove proviene¶

La provenienza è un'attestazione firmata che registra come è stato costruito un artefatto: la revisione della fonte, il costruttore, il flusso di lavoro e i parametri di costruzione. Il framework SLSA standardizza il formato e definisce i livelli di integrità per la pipeline che lo produce. Una distinta base software (SBOM) elenca i componenti all'interno dell'artefatto in un formato leggibile dalla macchina come SPDX o CycloneDX. La provenienza risponde "chi ha costruito questo da cosa"; la SBOM risponde "cosa c'è dentro". Un fornitore serio genera entrambi nella pipeline in fase di creazione, li allega all'immagine e li firma, in modo da condividere le garanzie di integrità dell'artefatto invece di vivere in un wiki.

Per la banca, l’SBOM è ciò che trasforma la divulgazione di una vulnerabilità in una questione limitata. Quando il successivo CVE critico arriva in una libreria comune, la banca può chiedere al fornitore quali versioni distribuite contengono il componente interessato e aspettarsi una risposta derivata dalle SBOM dei digest in esecuzione, entro poche ore. Questa capacità alimenta le politiche di patch e aggiornamento dell’Articolo 9(4)(f) della banca per la funzione esternalizzata, e alimenta la segnalazione degli incidenti secondo l’Articolo 19, in cui il rapporto deve definire quali servizi e versioni sono stati interessati. La provenienza serve al diritto di monitoraggio dell'Articolo 30(3)(e): un revisore in possesso dell'attestazione può confermare in modo indipendente che l'artefatto funzionante è stato costruito dalla pipeline sanzionata dalla revisione dichiarata.

Due domande di follow-up separano i fornitori esperti da quelli ambiziosi. Innanzitutto, la copertura: vengono prodotte attestazioni per ogni artefatto di rilascio o solo per l'immagine di punta? In secondo luogo, la verifica: qualcosa consuma le attestazioni, oppure vengono prodotte e mai controllate? Produrre una provenienza che nulla verifica ha comunque valore per l'analisi forense degli incidenti e un fornitore che afferma onestamente tale confine è più credibile di uno che implica controlli che non esistono.

Un percorso di rilascio controllato: nessuna porta laterale¶

La domanda rimanente è se i controlli di cui sopra possano essere aggirati. Un percorso di rilascio controllato significa che il percorso dall'origine unita al traffico di produzione è chiuso: a ogni immagine di runtime viene fatto riferimento da un digest immutabile anziché da un tag modificabile, lo stato di distribuzione è dichiarato nella configurazione controllata dalla versione (GitOps) in modo che le modifiche del cluster vengano tracciate nei commit esaminati e le dipendenze della pipeline CI, comprese le azioni CI di terze parti, sono fissate alle revisioni esatte in modo che il sistema di compilazione non possa essere modificato a monte della firma.

Il blocco del digest merita un controllo separato perché è il punto in cui le buone condutture perdono silenziosamente. Un tag come v1.4 può essere reimpostato nel registro dopo la revisione; un riassunto non può. La pipeline di KLA verifica che i manifest di runtime facciano riferimento alle immagini tramite digest e mantengano vuoto l'elenco delle eccezioni; le immagini di terze parti che devono essere eseguite nel cluster vengono specchiate, scansionate e firmate con la stessa identità delle immagini di prima parte, quindi la politica di ammissione vale per tutto.

Questo è anche il luogo in cui il fattore umano viene messo alla prova. Chiedi chi può passare direttamente alla produzione, in base a quale procedura di rottura del vetro e quale record lascia una distribuzione di rottura del vetro. L’articolo 30(3)(b) prevede che il contratto preveda obblighi di preavviso e di reporting per sviluppi che incidono materialmente sulla capacità di consegna del fornitore; un rilascio di emergenza al di fuori del percorso standard è esattamente uno sviluppo di questo tipo, e un fornitore di livello bancario può mostrare la procedura, il percorso di approvazione che produce e come l'artefatto viene comunque firmato e verificato anche in caso di emergenza.

La lista di controllo dell'acquirente: domande e come si presenta una buona risposta¶

La tabella seguente rappresenta la risorsa sollevamento e utilizzo. Metti le domande di fronte a qualsiasi fornitore di intelligenza artificiale, registra le risposte nel file di valutazione dell'articolo 28(4) e considera la colonna "risposta buona" come ancoraggio del punteggio. Ogni buona risposta condivide una proprietà: punta a un artefatto o a una dimostrazione piuttosto che a un PDF politico.

Leggere le risposte: punteggio e rispetto del contratto¶

Il punteggio è semplice. Una risposta supportata da un artefatto la banca può verificare il punteggio pieno. Una risposta che descrive un controllo reale senza prove indipendenti ottiene un punteggio parziale e genera una richiesta di prova. Una risposta che reindirizza a una certificazione ottiene un punteggio pari a zero per questa lista di controllo: un rapporto SOC 2 attesta il periodo di audit e i controlli nell'ambito, e raramente dimostra la riproducibilità, l'applicazione dell'ammissione o la provenienza per l'oggetto specifico che la banca gestirà. Le certificazioni completano le prove a livello di artefatto; non lo sostituiscono.

Dichiarazioni di confine oneste dovrebbero ottenere risultati, e questo taglia in entrambe le direzioni. KLA pubblica i propri confini sul Trust Center, compresi quali controlli vengono applicati oggi e quali sono graduali, perché un fornitore che afferma una pipeline perfetta sta descrivendo una pipeline che nessuno ha ispezionato. Aspettatevi lacune di copertura; giudica se il venditore sa dove si trovano, li monitora e sequenzia la chiusura.

Quindi trasferisci i risultati nel contratto. L'articolo 30(1) richiede il contratto completo in un unico documento scritto; L'articolo 30(2)(b) impone i luoghi di trattamento e conservazione previa comunicazione delle modifiche; L'articolo 30(3)(e) richiede diritti di accesso, ispezione e audit illimitati per funzioni critiche o importanti. Le pratiche della catena di fornitura verificate durante la due diligence diventano il contenuto concreto della clausola sulle misure di sicurezza dell'articolo 30(3)(c), e i comandi di verifica diventano il meccanismo attraverso il quale la banca esercita i suoi diritti di monitoraggio senza programmare una chiamata al fornitore. L'articolo 28(8) richiede strategie di uscita; le build riproducibili e le SBOM complete riducono sostanzialmente il rischio di uscita, perché la banca sa esattamente cosa stava eseguendo quando se ne va.

Per i team che valutano specificamente KLA: le affermazioni permanenti della catena di fornitura si trovano nella pagina Sicurezza, le pre-risposte di revisione e le informative dei sub-responsabili nel Trust Center e il contesto bancario in Soluzioni per servizi finanziari.