Conformità DORA per sviluppatori: cosa finisce in una pull request

A chi è rivolta questa guida (e a chi no)

Fai parte del pubblico di riferimento se il tuo codice supporta un'entità finanziaria coperta da DORA, o se il tuo prodotto è un servizio ICT utilizzato in produzione da queste entità (che tu sia un fornitore terzo di servizi ICT critici designato soggetto a supervisione diretta, o un fornitore vincolato principalmente tramite contratti con i clienti). L'ambito di applicazione e la designazione ai sensi del regolamento sono questioni legali e di classificazione delle entità, non decisioni che spetta a una code review prendere. Se il tuo team di conformità o legale ti ha già comunicato che DORA si applica (direttamente o per contratto), questa guida riguarda la parte ingegneristica di quell'obbligo. Se non sei sicuro di rientrare nell'ambito di applicazione, fermati qui e chiedi a loro: la risposta sbagliata comporta o un sottodimensionamento di un obbligo reale o un adattamento eccessivo di un regolamento che non si applica.

Questa guida non sostituisce un framework di gestione del rischio ICT, un programma di test di resilienza, un processo di segnalazione degli incidenti, un registro dei fornitori terzi o le clausole contrattuali chiave con i fornitori ICT. heygrc non gestisce nessuno di questi aspetti. È progettato per evidenziare il momento in cui una modifica in una pull request indebolisce o introduce un controllo rilevante per la resilienza che questi programmi presuppongono ancora esista.

Gli articoli che compaiono effettivamente in un diff

La maggior parte di DORA non comparirà mai come riga di codice applicativo. Ciò che tende a finire in una pull request si concentra in un breve elenco di articoli. Art. 9 (protezione e prevenzione): una modifica indebolisce il controllo degli accessi, la crittografia, la segmentazione di rete o un'altra misura che mantiene una funzione ICT critica isolata. Art. 10 (rilevamento): la registrazione, gli allarmi o il rilevamento delle anomalie su cui un'entità fa affidamento per notare prontamente un problema ICT viene rimosso o disabilitato. Art. 11 (risposta e recupero): un retry, un circuit breaker, un failover, un timeout o un percorso di recupero che manteneva attiva una funzione critica durante un'interruzione viene eliminato come pulizia. Art. 12 (backup e ripristino): l'ambito, la frequenza o gli strumenti di ripristino dei backup vengono ridotti, oppure un nuovo archivio critico viene distribuito senza un percorso di backup. Artt. 17-19 (gestione, classificazione e segnalazione degli incidenti ICT): una modifica rimuove l'identificazione, il tracciamento, la registrazione o la segnalazione degli incidenti ICT (Art. 17), oppure elimina i campi e i segnali su cui si basano il processo di classificazione (Art. 18) e il percorso di segnalazione degli incidenti gravi (Art. 19). Art. 28 (principi generali per la gestione del rischio dei fornitori terzi ICT), compreso il registro delle informazioni di cui all'Art. 28(3): un nuovo accordo contrattuale per un servizio ICT viene integrato in produzione senza essere registrato nel registro che dovrebbe coprire tutti questi accordi. Art. 30 (clausole contrattuali chiave): l'accordo viene trattato come "un altro cliente SaaS" senza alcun riferimento al capitolo sulle clausole contrattuali per i servizi ICT, che è un obbligo separato rispetto al registro e al lavoro di governance di cui all'Art. 28.

Queste spiegazioni sono riassunti in linguaggio semplice per gli ingegneri, non il testo del regolamento. L'analisi approfondita del framework all'indirizzo /frameworks/dora esamina gli articoli sulla resilienza con le forme di modifica che li attivano. Le pagine sui controlli nel codice per l'Art. 9 (protezione e prevenzione) e l'Art. 11 (risposta e recupero) mostrano diff pratici per la segmentazione appiattita e un circuit breaker rimosso. Questa guida si concentra sul gruppo di articoli che più spesso sorprende gli ingegneri di prodotto: Art. 28 e Art. 30, quando una comoda chiamata SaaS diventa una dipendenza ICT di produzione.

Esempio pratico: un client pulito che diventa un fornitore terzo ICT non tracciato

Un team di pagamenti vuole decisioni antifrode più rapide. Uno sviluppatore apre una pull request che sostituisce un percorso lento di regole interne con un client HTTP tipizzato per una nuova API esterna "FraudScore". Il client ha timeout, retry con backoff, mappatura strutturata degli errori e un feature flag. I test coprono il percorso felice e gli errori 5xx. I commenti di revisione riguardano tutti i budget di latenza e se il flag è attivato o disattivato di default. Nulla nel diff sembra sbagliato come software: è un'integrazione ben formata.

Ciò che la PR non include è alcun aggiornamento al registro delle informazioni sugli accordi contrattuali per i servizi ICT (Art. 28(3)), né alcun riferimento alle clausole contrattuali chiave di cui all'Art. 30 che si applicano generalmente agli accordi per i servizi ICT (Art. 30(1) e (2)). Nessuno dei due aspetta che qualcuno decida se la chiamata è "critica". Inoltre, se questo controllo antifrode si trova sul percorso che autorizza i pagamenti, l'accordo potrebbe supportare una funzione critica o importante, il che può attivare ulteriori obblighi, inclusi i requisiti di strategia di uscita di cui all'Art. 28 e la valutazione del rischio di concentrazione di cui all'Art. 29, nonché le clausole contrattuali potenziate di cui all'Art. 30(3). Distribuire il client prima e registrare l'entrata nel registro "in seguito" è il modo in cui una dipendenza di produzione diventa invisibile al programma che dovrebbe tracciare ogni accordo per servizi ICT.

Questa è la forma che una revisione consapevole della conformità è progettata per rilevare: non "il client HTTP è corretto", ma "questa modifica ha introdotto o sostituito un servizio ICT di un fornitore terzo il cui accordo contrattuale l'Art. 28(3) si aspetta nel registro". Un riscontro che cita l'Art. 28 / Art. 28(3) (e l'Art. 30 dove le clausole contrattuali rappresentano il problema) non approva il fornitore, non redige il contratto, non classifica la criticità, né decide il rischio di concentrazione. Rende visibile l'obbligo nei confronti del fornitore terzo mentre l'autore ha ancora la PR aperta, in modo che i passaggi di registrazione, classificazione e contratto possano procedere insieme al codice invece che settimane dopo che il traffico di produzione dipende dal nuovo fornitore.

Cosa cercare in una revisione senza diventare un esperto di DORA

Quando una modifica aggiunge o sostituisce una dipendenza in uscita che verrà eseguita in produzione per una funzione finanziaria, poni tre domande di ingegneria: l'accordo contrattuale per questo servizio ICT è già registrato nel nostro registro delle informazioni (Art. 28(3)), inclusa la classificazione del servizio e se supporta una funzione critica o importante; un'interruzione di questa chiamata degrada un servizio finanziario a tal punto che potrebbero applicarsi lavori di criticità e piano di uscita; e la stessa PR (o una modifica collegata) aggiorna l'elenco di controllo interno o il ticket che il tuo team di rischio utilizza quando un nuovo accordo ICT viene integrato, inclusi i lavori sulle clausole contrattuali di cui all'Art. 30 se è così che la tua organizzazione li traccia. Se la risposta sul registro è "no" o "sconosciuto", la funzionalità è incompleta dal punto di vista DORA per i fornitori terzi, anche se è completa come codice. La criticità determina quanta ulteriore attività segue; non decide se l'accordo appartiene al registro.

Per i controlli di resilienza già di tua competenza, l'indicazione è diversa: una PR il cui riassunto è "pulizia", "rimuovi codice morto" o "riduci i costi" che elimina retry, failover, backup, regole di isolamento o hook di rilevamento su un percorso critico. Chiediti se il sistema soddisfa ancora la proprietà di resilienza che quel controllo forniva. Gli Artt. 9, 10, 11, 12 e il gruppo di gestione degli incidenti negli Artt. 17-19 sono le citazioni usuali quando la risposta è no. Non è necessario citare il regolamento. È necessario nominare la proprietà e rifiutare il merge finché qualcuno non si assume la responsabilità di ripristinare il controllo o documentare una modifica accettata tramite il proprio processo di cambiamento reale.

Dove si inserisce heygrc e il limite dell'onestà

heygrc è progettato per analizzare ogni pull request rispetto ai framework selezionati, incluso DORA quando è abilitato, e per indicare l'articolo che una modifica sembra interessare (ad esempio Art. 28(3) per un nuovo accordo per servizi ICT mancante dal registro, Art. 11 per un percorso di recupero rimosso). Il riscontro è un commento di revisione con l'articolo allegato, in modo che l'autore e il revisore possano decidere con tutte le informazioni necessarie. Non certifica la conformità DORA, non sostituisce il framework di rischio ICT, non esegue i test di resilienza, non invia le segnalazioni di incidenti, non mantiene il registro dei fornitori terzi, né redige le clausole contrattuali di cui all'Art. 30. Questi rimangono compiti umani e organizzativi. Una revisione verde di heygrc non è un'approvazione di vigilanza; è un segnale precoce, basato sugli articoli, che una modifica ha interessato qualcosa di cui questi programmi si occupano.

Se il tuo team utilizza già un revisore di bug o di qualità sulla stessa pull request, mantienilo. Questi strumenti verificano se il codice è corretto e sicuro. Le domande su DORA riguardano la resilienza operativa e gli obblighi nei confronti dei fornitori terzi ICT. Il client FraudScore menzionato in precedenza può essere pulito, tipizzato e ben testato e comunque lasciare l'Art. 28(3) incompleto. Esegui entrambi i livelli; nessuno sostituisce l'altro.