Nella registrazione degli incidenti nello sviluppo software si tratta di due cose diverse che spesso si confondono: una vulnerabilità o un malfunzionamento nel software che costruisce e fornisce, e un incidente nella propria linea di sviluppo — l'ambiente in cui realizza quel software. Ciò che documenta, chi deve saperlo e quale azione successiva ne consegue, varia a seconda del tipo. Chi non fa questa distinzione spesso manca l'incidente che più conta: una contaminazione nella pipeline di build che si diffonde attraverso il codice a tutti i clienti che lo utilizzano.
Una vulnerabilità nel codice fornito colpisce direttamente il cliente: usa il software, quindi corre il rischio. Un incidente nella linea di sviluppo — una chiave di accesso rubata, un account di build compromesso, una perdita nel repository del codice sorgente — vi colpisce inizialmente, ma può estendersi a ogni cliente che lavora con quel codice. Per entrambi vale che un questionario di sicurezza o un revisore non chiede se qualcosa sia mai andato male, ma se riesce a mostrare ciò che ne ha documentato e imparato.
Ciò che documenta in caso di incidente nel codice
Nel caso di una vulnerabilità o un malfunzionamento nel software fornito si tratta di: quando è stato scoperto, da chi o da cosa (test interno, segnalazione del cliente, scansione, ricercatore esterno), quale parte del software colpisce, quale potrebbe essere l'effetto, quale azione è stata intrapresa e in quale data, e chi nella sua organizzazione è responsabile del follow-up. Una buona registrazione rende anche visibile se una correzione è stata implementata presso tutti i clienti che utilizzano la versione interessata, oppure solo presso chi l'ha segnalato. Quest'ultimo è esattamente ciò che un fornitore chiede in un questionario: non se ha mai avuto una vulnerabilità, ma se il suo processo garantisce che tutti coloro che ne sono colpiti lo vengano a sapere.
Ciò che documenta in caso di incidente nella linea di sviluppo
Un incidente nel suo ambiente di sviluppo — un account compromesso con accesso al codice sorgente, un server di build che reagisce diversamente dal previsto, una dipendenza che successivamente si rivela dannosa — richiede una registrazione leggermente diversa. Qui si tratta di: quale sistema o account era interessato, chi aveva accesso nel periodo in cui si è verificato, se vi sono tracce che il codice è stato modificato o consultato, e quali clienti eventualmente utilizzano software costruito o fornito in quel periodo. Questo è il tipo di incidente in cui la gestione dell'accesso nella linea di sviluppo ha un impatto diretto: senza una panoramica aggiornata di chi può accedere a cosa, rispondere a questa domanda investigativa in caso di incidente è considerevolmente più difficile.
Chi informa e chi no
Se lei stesso rientra nell'obbligo di protezione della Cyberbeveiligingswet determina chi informa in caso di incidente. Le entità che sono state designate come essenziali o importanti hanno l'obbligo di segnalare all'autorità di vigilanza; ciò che esattamente deve fare e entro quale termine è descritto nella direttiva e nella legge nazionale, e varia a seconda della situazione. Un'azienda di software colpita attraverso la catena — quindi non è direttamente soggetta agli obblighi, ma fornisce a un cliente che lo è — non ha tale obbligo di segnalazione all'autorità di vigilanza, ma di solito ha un accordo contrattuale per informare il cliente. Questo non rende meno importante la registrazione interna: un cliente che chiede se ha mai avuto un incidente vuole una risposta concreta, non una valutazione retroattiva.
Un registro dinamico, non un archivio
La registrazione degli incidenti funziona al meglio come documento vivo: un elenco in cui si trovano lo stato, la prova e il responsabile per ogni incidente, invece di un rapporto isolato che scompare in una cartella dopo la risoluzione. Ciò si allinea con il modo in cui l'obbligo di diligenza più ampio è strutturato, con dieci misure che ciascuna richiede uno stato e un responsabile. Chi vuole vedere come la registrazione degli incidenti si relaziona alle altre nove misure trova tale panoramica su la pagina con tutti gli argomenti per situazione.
Se la vostra organizzazione rientra direttamente nell'obbligo di diligenza, viene colpita attraverso la catena di approvvigionamento, o nessuno dei due, è possibile verificarlo con poche domande tramite la verifica NIS2 che fornisce un'indicazione in poche domande. Chi vuole sapere esattamente da dove provengono le informazioni su secria.eu e come vengono gestite, le legge su la pagina su come funziona. E chi dopo la lettura vuole sapere cosa aggiunge un abbonamento a ciò che è disponibile gratuitamente qui, lo trova chiaramente elencato su l'elenco di ciò che è incluso.
Questo testo è una spiegazione generale e non costituisce una consulenza legale sulla vostra situazione specifica. Per un parere sul vostro specifico processo di incidente o obbligo di segnalazione, potete rivolgervi a un avvocato o all'autorità di vigilanza competente per il vostro settore.