NIS 2 (Direttiva (UE) 2022/2555) elenca dieci misure di gestione del rischio cyber all'Art. 21(2), e la maggior parte delle documentazioni di conformità le tratta come politica e processo: una politica di sicurezza delle informazioni, una procedura di gestione degli incidenti, un piano di continuità operativa. Questo è accurato per la maggior parte dell'elenco. Non è completo per la misura decisa da ciò che un team distribuisce effettivamente: l'Art. 21(2)(e), sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi di rete e informativi, inclusa la gestione e la segnalazione delle vulnerabilità.
Questa guida è rivolta agli sviluppatori la cui organizzazione è soggetta a NIS 2, un'entità essenziale o importante ai sensi della direttiva, o un fornitore che rifornisce una di queste, e che vogliono sapere quale parte di tale misura una revisione di pull request può effettivamente rilevare, distinta dalle misure di sicurezza della catena di fornitura e igiene cyber che l'hub del framework copre già.
A chi è rivolta questa guida e la regola del limite dimensionale
NIS 2 si applica alle entità medie e grandi ai sensi della regola del limite dimensionale (in generale, 50 o più dipendenti, o fatturato annuo e totale dello stato patrimoniale annuo entrambi superiori a 10 milioni di EUR) che operano nei settori elencati nell'Allegato I e nell'Allegato II della direttiva: energia, trasporti, banche, sanità e infrastrutture digitali tra gli altri nell'Allegato I; servizi postali, prodotti chimici, alimentari e manifatturiero tra gli altri nell'Allegato II. Il settore da solo non decide se un'entità è essenziale o importante: all'interno dell'Allegato I, un'entità grande che soddisfa il limite dimensionale è generalmente classificata come 'essenziale' e un'entità media generalmente come 'importante'; un'entità dell'Allegato II che soddisfa il limite dimensionale è generalmente classificata come 'importante' indipendentemente dal fatto che sia media o grande, la dimensione non la suddivide ulteriormente come avviene nell'Allegato I; e un insieme più ristretto di entità (alcuni fornitori di infrastrutture digitali, amministrazione pubblica e alcune altre categorie speciali) sono incluse nell'ambito di applicazione, e talvolta classificate come essenziali, indipendentemente dalla dimensione, per nome piuttosto che in base alla regola del limite dimensionale. Se la tua organizzazione, o il cliente per cui sviluppi software, è essenziale, importante o fuori dall'ambito di applicazione è una questione di classificazione giuridica che spetta al team di conformità o legale, non qualcosa che una revisione del codice decide. Se questa discussione non è ancora avvenuta, affrontala prima di considerare questa guida come un programma di conformità.
Questa guida presuppone che la domanda di classificazione sia già stata risolta e che l'organizzazione sia soggetta a NIS 2. Non sostituisce il framework di gestione del rischio richiesto dalla direttiva, la gestione degli incidenti prevista dall'Art. 21(2)(b) e la segnalazione degli incidenti prevista dall'Art. 23, o la responsabilità dell'organo di gestione assegnata dall'Art. 20. Riguarda la misura dell'Art. 21(2) che può essere compromessa in una diff.
La misura che appare effettivamente in una diff: Art. 21(2)(e)
Due delle dieci misure dell'Art. 21(2) hanno già pagine dedicate di controllo nel codice su questo sito: sicurezza della catena di fornitura (Art. 21(2)(d), una dipendenza non fissata o non verificata) e igiene cyber di base (Art. 21(2)(g), una vulnerabilità nota non corretta). Il punto (e), sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi di rete e informativi, è un aspetto diverso: copre come viene sviluppato il software e come le vulnerabilità vengono individuate e segnalate, non quali dipendenze si includono o quali patch si applicano in seguito.
In pratica, questo si traduce in due abitudini ingegneristiche. Prima, i test di sicurezza che un processo di sviluppo esegue prima che una modifica venga distribuita: un gate di analisi statica, un passaggio di revisione di sicurezza obbligatorio, un controllo delle dipendenze o di fuzzing che deve superare. Seconda, un percorso di segnalazione delle vulnerabilità funzionante per il software una volta in esecuzione: un contatto di sicurezza, un punto di ricezione pubblicato per una segnalazione esterna, un canale per chi trova una vulnerabilità per comunicarla. Entrambi possono essere compromessi in una singola pull request: un gate viene disabilitato per sbloccare una release, o una nuova superficie accessibile esternamente viene distribuita senza un percorso di segnalazione associato.
Esempio pratico: il gate disabilitato per rispettare una scadenza
Un team è sotto pressione per distribuire un nuovo endpoint API accessibile al pubblico, la prima superficie dell'azienda rivolta ai clienti e accessibile da internet aperto. La pull request che aggiunge l'endpoint include anche una modifica non correlata in una riga: il gate di sicurezza di analisi statica obbligatorio del repository, che normalmente deve superare il test prima del merge, viene contrassegnato come non bloccante con un commento che fa riferimento a un ticket di follow-up. L'endpoint stesso è ben costruito, con validazione degli input e controlli di autenticazione che superano una revisione umana. Il ticket di follow-up citato nel commento non esiste e nulla nella PR ripristina il gate come bloccante una volta distribuita la release. Separatamente, l'azienda non ha un contatto di sicurezza, un file `security.txt` o un punto di ricezione pubblicato per la segnalazione delle vulnerabilità: gli strumenti interni erano le uniche cose esposte in precedenza, quindi nessuno ne aveva bisogno.
Se revisionata solo come funzionalità, questa PR è valida: l'endpoint funziona, i test passano, la scadenza viene rispettata. Se revisionata rispetto all'Art. 21(2)(e), è due cose contemporaneamente. Indebolisce i test di sicurezza che il processo di sviluppo dovrebbe eseguire prima che il codice venga distribuito, senza un'eccezione limitata o un percorso di ripristino, il che corrisponde esattamente alla parte di acquisizione e sviluppo della misura. E rappresenta il momento in cui la mancanza di un percorso di segnalazione delle vulnerabilità dell'azienda smette di essere un vuoto cartaceo e diventa reale: ora esiste una superficie attiva e accessibile esternamente, ma non c'è un canale per chi trova una vulnerabilità per segnalarla all'azienda, il che corrisponde alla parte di segnalazione. Nessuno dei due problemi riguarda la correttezza del codice dell'endpoint. Entrambi riguardano se il processo e l'organizzazione soddisfano ancora la misura che assumeva che il gate rimanesse attivo e che un percorso di segnalazione esistesse da qualche parte.
Un riscontro che cita l'Art. 21(2)(e) non decide se il gate avrebbe dovuto essere disabilitato per un motivo reale, se redigere la politica di segnalazione o eseguire il test di sicurezza stesso. Rende la modifica visibile mentre la PR è ancora aperta, in modo che l'autore o un revisore possano ripristinare il gate con un'eccezione tracciata reale e segnalare che l'organizzazione ha bisogno di un canale di segnalazione prima che questo endpoint diventi la porta principale per una segnalazione senza un luogo dove atterrare. Se un percorso di segnalazione esisteva già a livello organizzativo, questa seconda parte non si applicherebbe: il vuoto è reale solo se non esiste.
Cosa cercare in una revisione senza diventare un esperto di NIS 2
Quando una pull request modifica la configurazione CI, chiedi se disabilita, indebolisce o bypassa un passaggio di test di sicurezza obbligatorio e, in tal caso, se la stessa PR (o una collegata) documenta il motivo e quando verrà ripristinato. Un gate disabilitato senza un percorso di ripristino è il segnale dell'Art. 21(2)(e). Quando una pull request aggiunge un nuovo endpoint, servizio o integrazione accessibile esternamente, chiedi se esiste già un percorso di segnalazione delle vulnerabilità a livello organizzativo; se esiste, la nuova superficie lo eredita e non è necessario nulla altro; se non esiste, è un vuoto che vale la pena segnalare, anche se si tratta di una soluzione organizzativa una tantum piuttosto che di una soluzione per PR.
Questa è una richiesta più limitata rispetto alla misura completa. Non copre se la documentazione del ciclo di vita dello sviluppo è completa o se il processo di gestione delle vulnerabilità soddisfa tutti gli elementi descritti dalla direttiva; queste sono domande di processo per chi gestisce il programma NIS 2. Copre i due punti in cui una pull request può silenziosamente annullare il lavoro che il programma ha già svolto.
Dove si inserisce heygrc e il limite dell'onestà
heygrc è progettato per analizzare ogni pull request rispetto ai framework selezionati, inclusa NIS 2 quando abilitata, e per indicare il punto che una modifica sembra toccare, ad esempio l'Art. 21(2)(e) su un gate di sicurezza disabilitato o un nuovo endpoint senza un percorso di segnalazione visibile, l'Art. 21(2)(d) su una dipendenza non fissata, l'Art. 21(2)(g) su una patch trattenuta. Il riscontro è un commento di revisione con la clausola allegata, in modo che l'autore e il revisore decidano con informazioni complete. Non certifica la conformità a NIS 2, non redige la politica di segnalazione delle vulnerabilità, non esegue i test di sicurezza, non classifica l'entità né invia le segnalazioni degli incidenti richieste dall'Art. 23. Questi rimangono compiti umani e organizzativi.
Se il tuo team esegue già uno strumento SAST o di qualità del codice sulla stessa pull request, mantienilo. Quello strumento verifica se il codice stesso è corretto e sicuro. L'Art. 21(2)(e) verifica se il processo intorno al codice, il gate che avrebbe dovuto essere eseguito e il percorso che qualcuno usa per segnalare una vulnerabilità, è ancora valido. L'endpoint sopra può superare tutti i controlli di qualità e comunque lasciare la misura più debole di quanto non fosse. Esegui entrambi i livelli; nessuno sostituisce l'altro.