Vulnerabilità note, lasciate senza patch.
L'Art. 21(2)(g) della NIS 2 elenca tra le misure obbligatorie le pratiche di base di igiene informatica, e una delle più fondamentali è mantenere il software aggiornato contro vulnerabilità note. Quando esiste una correzione per un avviso pubblicato e non la si applica, si sta deliberatamente eseguendo un sistema con una falla nota. Questa decisione viene solitamente presa in un file manifest, in un'immagine base o nel codice.
The shapes the same control failure takes.
L'igiene informatica si deteriora quando una modifica lascia in essere una vulnerabilità nota e risolvibile. Le forme ricorrenti:
Una dipendenza è bloccata alla versione vulnerabile
Una libreria con un avviso di sicurezza pubblicato viene fissata alla versione interessata invece che aggiornata a quella corretta, per evitare di ritestare l'integrazione.
Un'immagine base è bloccata e non più mantenuta
Un'immagine base è fissata a un tag vecchio che non riceve più aggiornamenti di sicurezza, quindi le vulnerabilità note si accumulano.
Un meccanismo di aggiornamento automatico è disabilitato
L'automazione per l'aggiornamento delle dipendenze o delle immagini è disattivata o le sue pull request vengono sistematicamente chiuse, quindi le correzioni smettono di essere applicate.
Una patch di sicurezza viene annullata
Un aggiornamento che ha risolto una vulnerabilità viene riportato alla versione precedente perché ha causato problemi, riaprendo la falla.
Software a fine vita viene mantenuto in uso
Un runtime o una libreria oltre il fine vita, che non riceve più correzioni, viene mantenuto invece di essere migrato.
Una dipendenza fissata a una versione con un avviso noto.
Una libreria ha un avviso di sicurezza pubblicato con una versione corretta disponibile. Applicare la correzione comporterebbe ritestare un'integrazione, quindi una modifica la fissa alla versione vulnerabile. L'applicazione continua a funzionare, ma su una versione con una vulnerabilità nota e non corretta.
"dependencies": {- "image-parser": "1.4.2"+ "image-parser": "1.3.0" }Fissare image-parser alla versione 1.3.0 mantiene una versione con un avviso noto e pubblicato quando una versione corretta (1.4.2) è disponibile. L'Art. 21(2)(g) (pratiche di base di igiene informatica) include il mantenimento del software aggiornato contro vulnerabilità note. Applicare la versione corretta e ritestare, invece di mantenere quella vulnerabile.
L'igiene informatica viene verificata in base a ciò che è ancora in esecuzione.
Un'ispezione ai sensi della NIS 2 cerca prove di igiene di base: che le vulnerabilità note vengano tracciate e corrette in un tempo ragionevole e che il software rimanga supportato. Una modifica che fissa una dipendenza a una versione vulnerabile, blocca un'immagine base non mantenuta o disabilita l'automazione degli aggiornamenti è la concreta mancanza dietro questo, ed è visibile nel diff del file manifest, lockfile o immagine.
Una revisione, non uno scanner di vulnerabilità.
heygrc segnalerà le modifiche che interessano una misura di igiene NIS 2 e citerà il punto in modo che la correzione avvenga nella pull request. Non esegue la scansione delle vulnerabilità né la pipeline di patch. Intercetta il momento in cui una modifica lascia in essere una vulnerabilità nota e risolvibile, direttamente nel diff.