NIS 2 (Directiva (UE) 2022/2555) enumera diez medidas de gestión de riesgos de ciberseguridad en el Art. 21(2), y la mayoría de los documentos de cumplimiento las abordan como política y proceso: una política de seguridad de la información, un procedimiento de gestión de incidentes, un plan de continuidad del negocio. Esto es preciso para la mayoría de la lista. Es incompleto para la medida que depende de lo que un equipo envía realmente: el Art. 21(2)(e), seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluyendo la gestión y divulgación de vulnerabilidades.
Esta guía es para desarrolladores cuya organización está dentro del ámbito de NIS 2, ya sea como entidad esencial o importante según la directiva, o como proveedor que alimenta a una de ellas, y que desean saber qué parte de esa medida puede detectar realmente una revisión de pull request, distinta de las medidas de cadena de suministro e higiene cibernética que ya cubre el centro del marco.
A quién va dirigida esta guía y la regla de tamaño
NIS 2 se aplica a entidades medianas y grandes según la regla de tamaño (en términos generales, 50 o más empleados, o volumen de negocios anual y total de balance anual ambos superiores a 10 millones de EUR) que operan en los sectores listados en los Anexos I y II de la directiva: energía, transporte, banca, salud y infraestructura digital, entre otros en el Anexo I; servicios postales, productos químicos, alimentación y fabricación, entre otros en el Anexo II. El sector por sí solo no determina si una entidad es esencial o importante: dentro del Anexo I, una entidad grande que cumple la regla de tamaño se clasifica generalmente como 'esencial' y una mediana como 'importante'; una entidad del Anexo II que cumple la regla de tamaño se clasifica generalmente como 'importante', ya sea mediana o grande, y el tamaño no la divide más como ocurre en el Anexo I; y un conjunto más pequeño de entidades (ciertos proveedores de infraestructura digital, administración pública y algunas otras categorías especiales) se incluyen en el ámbito, y a veces se clasifican como esenciales, independientemente del tamaño, por nombre en lugar de por la regla de tamaño. Si tu organización, o el cliente para el que desarrollas software, es esencial, importante o está fuera del ámbito, es una cuestión de clasificación legal que debe resolver tu equipo de cumplimiento o legal, no algo que decida una revisión de código. Si esa conversación no ha ocurrido, tenla antes de tratar esta guía como un programa de cumplimiento.
Esta guía asume que la cuestión de clasificación ya está resuelta y que la organización está dentro del ámbito. No es un sustituto del marco de gestión de riesgos que exige la directiva, ni de la gestión de incidentes que requieren el Art. 21(2)(b) y el Art. 23, ni de la responsabilidad del órgano de dirección que asigna el Art. 20. Se centra en la única medida del Art. 21(2) que puede erosionarse en un diff.
La medida que realmente aparece en un diff: Art. 21(2)(e)
Dos de las diez medidas del Art. 21(2) ya tienen sus propias páginas de control en código en este sitio: seguridad de la cadena de suministro (Art. 21(2)(d), una dependencia no fijada o no verificada) e higiene cibernética básica (Art. 21(2)(g), una vulnerabilidad conocida sin parchear). El punto (e), seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, es un aspecto diferente: cubre cómo se construye el software y cómo se encuentran y divulgan las vulnerabilidades en él, no qué dependencias se incorporan o qué parches se aplican después.
En la práctica, esto se traduce en dos hábitos de ingeniería. Primero, las pruebas de seguridad que un proceso de desarrollo ejecuta antes de que un cambio se envíe: una puerta de análisis estático, un paso de revisión de seguridad obligatorio, una verificación de dependencias o fuzz que debe aprobarse. Segundo, una ruta de divulgación de vulnerabilidades funcional para el software una vez que está en ejecución: un contacto de seguridad, un punto de recepción publicado para informes externos, una vía para que alguien que encuentre una vulnerabilidad pueda informarte. Ambos pueden erosionarse en una sola pull request: una puerta se desactiva para desbloquear una versión, o una nueva superficie accesible externamente se envía sin una ruta de divulgación asociada.
Ejemplo práctico: la puerta desactivada para cumplir un plazo
Un equipo está bajo presión para enviar un nuevo endpoint de API accesible al público, el primer punto de contacto con el cliente de la empresa accesible desde internet abierto. La pull request que añade el endpoint también incluye un cambio de una línea no relacionado: la puerta de seguridad de análisis estático obligatorio del repositorio, que normalmente debe aprobarse antes de la fusión, se marca como no bloqueante con un comentario que hace referencia a un ticket de seguimiento. El endpoint en sí está bien construido, con validación de entrada y comprobaciones de autenticación que pasan una revisión humana. El ticket de seguimiento mencionado en el comentario no existe, y nada en la PR restaura la puerta a bloqueante una vez que se envía la versión. Además, la empresa no tiene contacto de seguridad, `security.txt` ni punto de recepción publicado para informes de vulnerabilidades en ningún lugar: las herramientas internas eran lo único expuesto antes, por lo que nadie lo ha necesitado.
Revisado solo como una función, esta PR está bien: el endpoint funciona, las pruebas pasan, el plazo se cumple. Revisado frente al Art. 21(2)(e), es dos cosas a la vez. Debilita las pruebas de seguridad que el proceso de desarrollo debe ejecutar antes de enviar el código, sin una excepción con alcance o una ruta de restauración, lo que es exactamente la parte de adquisición y desarrollo de la medida. Y es el momento en que la falta de ruta de divulgación de vulnerabilidades de la empresa deja de ser una brecha en el papel y se convierte en una real: ahora hay una superficie en vivo accesible externamente y no hay ruta para que alguien que encuentre una vulnerabilidad en ella pueda informar a la empresa, lo que corresponde a la parte de divulgación. Ninguno de los problemas se refiere a si el código del endpoint es correcto. Ambos se refieren a si el proceso y la organización aún cumplen la medida que asumía que la puerta seguiría activa y que existiría una ruta de divulgación en algún lugar.
Un hallazgo que cite el Art. 21(2)(e) no decide si la puerta debía desactivarse por una razón real, redactar la política de divulgación o ejecutar la prueba de seguridad en sí. Hace que el cambio sea visible mientras la PR sigue abierta, para que el autor o un revisor puedan restaurar la puerta con una excepción real rastreada y señalar que la organización necesita un canal de divulgación antes de que este endpoint sea la puerta principal para un informe sin destino. Si ya existía una ruta de divulgación a nivel de organización, esta segunda parte no aplicaría: la brecha es real solo porque no existe ninguna.
Qué buscar en la revisión sin convertirse en un experto legal de NIS 2
Cuando una pull request modifica la configuración de CI, pregunta si desactiva, debilita o elude un paso de prueba de seguridad obligatorio, y si es así, si la misma PR (o una vinculada) documenta por qué y cuándo se restaurará. Una puerta desactivada sin ruta de restauración es la señal del Art. 21(2)(e). Cuando una pull request añade un nuevo endpoint, servicio o integración accesible externamente, pregunta si ya existe una ruta de divulgación de vulnerabilidades para ello a nivel de organización; si existe, la nueva superficie la hereda y no se necesita nada más; si no existe, es una brecha que vale la pena señalar, aunque sea una solución organizativa puntual en lugar de una por PR.
Esto es una solicitud más estrecha que la medida completa. No cubre si la documentación del ciclo de vida de desarrollo está completa o si el proceso de gestión de vulnerabilidades cumple todos los elementos que describe la directiva; esas son preguntas de proceso para quien sea responsable del programa de NIS 2 de tu organización. Cubre los dos lugares donde una pull request puede deshacer silenciosamente el trabajo que ese programa ya ha realizado.
Dónde encaja heygrc y el límite de la honestidad
heygrc está diseñado para leer cada pull request frente a los marcos que hayas seleccionado, incluyendo NIS 2 cuando esté activado, y para identificar el punto que un cambio parece tocar, por ejemplo, el Art. 21(2)(e) en una puerta de seguridad desactivada o un nuevo endpoint sin ruta de divulgación visible, el Art. 21(2)(d) en una dependencia no fijada, el Art. 21(2)(g) en un parche retenido. El hallazgo es un comentario de revisión con la cláusula adjunta, para que el autor y el revisor decidan con toda la información. No certifica el cumplimiento de NIS 2, redacta tu política de divulgación de vulnerabilidades, ejecuta tus pruebas de seguridad, clasifica tu entidad ni presenta los informes de incidentes que requiere el Art. 23. Esas siguen siendo obligaciones humanas y organizativas.
Si tu equipo ya ejecuta una herramienta de SAST o de calidad de código en la misma pull request, manténla. Esa herramienta pregunta si el código en sí es correcto y seguro. El Art. 21(2)(e) pregunta si el proceso alrededor del código, la puerta que debía ejecutarse y la ruta que alguien usa para informar sobre una vulnerabilidad, sigue vigente. El endpoint mencionado anteriormente puede aprobar todas las comprobaciones de calidad y, sin embargo, dejar la medida más débil de lo que estaba. Ejecuta ambas capas; ninguna reemplaza a la otra.