Vulnérabilités connues, non corrigées.
L'article 21(2)(g) de la NIS 2 énumère les pratiques d'hygiène informatique de base parmi les mesures requises, et l'une des plus fondamentales consiste à maintenir les logiciels à jour contre les vulnérabilités connues. Lorsqu'un correctif existe pour un avis de sécurité publié et que vous ne l'appliquez pas, vous exécutez intentionnellement une faille connue. Cette décision est généralement prise dans un manifest, une image de base ou dans le code.
The shapes the same control failure takes.
L'hygiène informatique se dégrade lorsqu'un changement laisse une vulnérabilité connue et corrigible en place. Les formes récurrentes :
Une dépendance est maintenue à une version non corrigée
Une bibliothèque faisant l'objet d'un avis de sécurité est épinglée à la version affectée plutôt que mise à jour vers la version corrigée, pour éviter de retester.
Une image de base est figée et non maintenue
Une image de base est épinglée à une ancienne étiquette qui ne reçoit plus de mises à jour de sécurité, de sorte que ses vulnérabilités connues s'accumulent.
Un mécanisme de mise à jour automatique est désactivé
La mise à jour automatique des dépendances ou des images est désactivée ou ses pull requests sont systématiquement fermées, empêchant ainsi l'application des correctifs.
Un correctif de sécurité est annulé
Une mise à jour ayant corrigé une vulnérabilité est restaurée à une version antérieure car elle a causé des problèmes, rouvrant ainsi la faille.
Un logiciel en fin de vie est conservé
Un environnement d'exécution ou une bibliothèque en fin de vie, qui ne reçoit plus de correctifs, est conservé au lieu d'être migré.
Une dépendance épinglée à une version faisant l'objet d'un avis connu.
Une bibliothèque fait l'objet d'un avis de sécurité publié avec une version corrigée disponible. Appliquer le correctif signifierait retester une intégration, donc un changement la ramène à la version affectée. L'application continue de fonctionner, mais sur une version présentant une vulnérabilité connue et non corrigée.
"dependencies": {- "image-parser": "1.4.2"+ "image-parser": "1.3.0" }Épingler image-parser à la version 1.3.0 conserve une version faisant l'objet d'un avis connu alors qu'une version corrigée (1.4.2) est disponible. L'article 21(2)(g) (pratiques d'hygiène informatique de base) inclut le maintien des logiciels à jour contre les vulnérabilités connues. Appliquez la version corrigée et retestez, plutôt que de conserver la version affectée.
L'hygiène informatique est vérifiée en fonction de ce que vous exécutez encore.
Une inspection dans le cadre de la NIS 2 recherche des preuves d'hygiène de base : que les vulnérabilités connues sont suivies et corrigées dans un délai raisonnable, et que les logiciels restent supportés. Un changement qui épingle une dépendance à une version vulnérable, fige une image de base non maintenue ou désactive l'automatisation des mises à jour est le manquement concret derrière cela, et il est visible dans le diff du manifest, du lockfile ou de l'image.
Une revue, pas un scanner de vulnérabilités.
heygrc signale les changements qui concernent une mesure d'hygiène NIS 2 et cite le point afin que la correction ait lieu dans la pull request. Il n'exécute pas votre analyse de vulnérabilités ni votre pipeline de correctifs. Il détecte le moment où un changement laisse une vulnérabilité connue et corrigible en place, au niveau du diff.