Vulnerabilidades conocidas, sin parchear.
El Art. 21(2)(g) de NIS 2 enumera las prácticas básicas de higiene cibernética entre las medidas obligatorias, y una de las más fundamentales es mantener el software actualizado frente a vulnerabilidades conocidas. Cuando existe una corrección para un aviso publicado y no se aplica, se está ejecutando deliberadamente un agujero de seguridad conocido. Esa decisión suele tomarse en un manifiesto, una imagen base o en el código.
The shapes the same control failure takes.
La higiene cibernética se deteriora cuando un cambio deja una vulnerabilidad conocida y corregible sin solucionar. Las formas recurrentes:
Una dependencia se retiene sin su corrección
Una biblioteca con un aviso publicado se fija a la versión afectada en lugar de actualizarse a la versión parcheada, para evitar volver a probar.
Una imagen base está congelada y sin mantenimiento
Una imagen base se fija a una etiqueta antigua que ya no recibe actualizaciones de seguridad, por lo que sus vulnerabilidades conocidas se acumulan.
Un mecanismo de actualización automática está desactivado
La automatización de actualización de dependencias o imágenes está desactivada o sus pull requests se cierran sistemáticamente, por lo que las correcciones dejan de aplicarse.
Un parche de seguridad se revierte
Una actualización que cerró una vulnerabilidad se revierte porque causó fricción, reabriendo el agujero.
Se mantiene software en fin de vida útil
Un entorno de ejecución o biblioteca en fin de vida útil, que ya no recibe correcciones, se conserva en lugar de migrar.
Una dependencia fijada a una versión con un aviso conocido.
Una biblioteca tiene un aviso de seguridad publicado con una versión corregida disponible. Aplicar la corrección implicaría volver a probar una integración, por lo que un cambio la fija a la versión afectada. La aplicación sigue funcionando, pero en una versión con una vulnerabilidad conocida y sin parchear.
"dependencies": {- "image-parser": "1.4.2"+ "image-parser": "1.3.0" }Fijar image-parser a la versión 1.3.0 mantiene una versión con un aviso conocido y publicado cuando existe una versión corregida (1.4.2). El Art. 21(2)(g) (prácticas básicas de higiene cibernética) incluye mantener el software parcheado frente a vulnerabilidades conocidas. Aplique la versión parcheada y vuelva a probar, en lugar de mantener la afectada.
La higiene cibernética se verifica según lo que aún se está ejecutando.
Una inspección bajo NIS 2 busca pruebas de higiene básica: que las vulnerabilidades conocidas se rastrean y parchean en un plazo razonable, y que el software se mantiene con soporte. Un cambio que fija una dependencia a una versión vulnerable, congela una imagen base sin mantenimiento o desactiva la automatización de actualizaciones es el fallo concreto detrás de esto, y es visible en el diff del manifiesto, lockfile o imagen.
Una revisión, no un escáner de vulnerabilidades.
heygrc marca los cambios que afectan a una medida de higiene de NIS 2 y cita el punto para que la corrección se realice en la pull request. No ejecuta el escaneo de vulnerabilidades ni el pipeline de parches. Detecta el momento en que un cambio deja una vulnerabilidad conocida y corregible sin solucionar, en el diff.