Ir al contenido principal

Guía

NIS2 Artículo 21: dónde encaja realmente un escaneo SAST

NIS2 es una directiva de la UE, no una checklist de producto — ninguna herramienta "le hace cumplir NIS2". El Artículo 21(2) enumera 10 categorías de medidas técnicas y organizativas. El análisis estático genuinamente produce evidencia para dos de ellas. Aquí está exactamente cuáles, por qué las otras ocho necesitan algo más, y qué genera StaticCodeAudit para cada una.

NIS2 en un párrafo

La Directiva NIS2 (UE 2022/2555) extiende las obligaciones de ciberseguridad de la UE a aproximadamente 160.000 organizaciones en 18 sectores — energía, transporte, banca, sanidad, infraestructura digital, fabricación de productos críticos, y más — clasificadas en entidades "esenciales" e "importantes" según sector y tamaño (a grandes rasgos: 250+ empleados o €50M+ de facturación en sectores del Anexo I para estatus esencial; 50–249 empleados o €10–50M de facturación para estatus importante, con algunas excepciones bajo umbral para proveedores DNS, registros de TLD y similares). Cada Estado miembro la transpone a su derecho nacional, por lo que los plazos exactos de aplicación y las autoridades supervisoras varían por país — esta página describe la directiva en sí, no ninguna transposición nacional en particular.

Artículo 21(2): las 10 categorías de medidas

El Artículo 21(2) exige a las entidades implementar medidas que cubran al menos estas diez categorías — citadas directamente del texto de la directiva:

§ Medida
(a) Políticas de análisis de riesgos y seguridad de los sistemas de información
(b) Gestión de incidentes
(c) Continuidad de negocio, como gestión de copias de seguridad y recuperación ante desastres, y gestión de crisis
(d) Seguridad de la cadena de suministro, incluyendo aspectos de seguridad relativos a las relaciones con proveedores o prestadores de servicios directos
(e) Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluyendo gestión y divulgación de vulnerabilidades
(f) Políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad
(g) Prácticas básicas de higiene cibernética y formación en ciberseguridad
(h) Políticas y procedimientos relativos al uso de criptografía y, cuando proceda, cifrado
(i) Seguridad de recursos humanos, políticas de control de acceso y gestión de activos
(j) Autenticación multifactor o continua, comunicaciones de voz/vídeo/texto seguras y sistemas de comunicación de emergencia seguros

Las filas resaltadas son las dos categorías para las que un escaneo de código fuente puede producir evidencia genuina. Las otras ocho son medidas organizativas, procedimentales o de infraestructura — ninguna herramienta de análisis estático las toca.

Dónde encaja realmente StaticCodeAudit

(e) Gestión y divulgación de vulnerabilidades

Una exportación SARIF 2.1.0 es exactamente el tipo de registro de vulnerabilidades estructurado y legible por máquina que pide esta categoría: un escaneo ejecutado sobre un commit dado, con la regla, severidad, archivo y línea de cada hallazgo — evidencia de que la gestión de vulnerabilidades ocurrió en un punto específico del ciclo de desarrollo, no solo la afirmación de que ocurre.

./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-high
Guía completa: exportación SARIF y GitHub Code Scanning →

(d) Seguridad de la cadena de suministro

Un SBOM CycloneDX 1.5 lista cada dependencia que incorpora un código — nombre, versión, Package URL. Combinado con los hallazgos SARIF del mismo escaneo, es el tipo de artefacto sobre el que un revisor de procurement o un auditor puede actuar al evaluar "la calidad general de los productos y prácticas de ciberseguridad" de un proveedor, una de las subconsideraciones que NIS2 vincula a esta categoría.

./staticcodeaudit-linux-x86_64 /path/to/project --sbom
Guía completa: exportación SBOM e inventario de dependencias →

Un punto secundario que merece explicitarse

El Artículo 21(2)(d) también pide a las entidades sopesar las prácticas de ciberseguridad de sus propios proveedores — incluyendo si las herramientas de esos proveedores introducen nuevos flujos de datos. Un escáner sin conexión que nunca sube el código fuente a ningún sitio no añade una nueva dependencia SaaS a la huella de riesgo de cadena de suministro del propio código, a diferencia de un proveedor SAST en la nube que un equipo de seguridad tendría que evaluar también.

Qué no cubre esto — la lista honesta

Ocho de las diez categorías están fuera de lo que un escáner de código fuente puede evidenciar, y ningún volumen de escaneo cambia eso:

  • (a) Análisis de riesgos y políticas de seguridad — un proceso organizativo, no un artefacto de código.
  • (b) Gestión de incidentes — requiere un proceso de respuesta y un equipo, no un escaneo.
  • (c) Continuidad de negocio y recuperación ante desastres — infraestructura y proceso, sin relación con el código fuente.
  • (f) Políticas de evaluación de eficacia — una actividad de gobernanza.
  • (g) Formación en higiene cibernética — una actividad humana.
  • (h) Política de criptografía — una política escrita; un escaneo puede señalar un algoritmo débil en el código (contribuyendo al capítulo V11 de ASVS) pero no puede redactar ni aprobar la política en sí.
  • (i) Seguridad de RRHH y política de control de acceso — organizativo, no a nivel de código.
  • (j) MFA y comunicaciones seguras — una decisión de infraestructura/despliegue, no una propiedad del código fuente.

Preguntas frecuentes

¿Usar StaticCodeAudit hace que mi organización cumpla con NIS2?

Ninguna herramienta por sí sola lo hace. El cumplimiento de NIS2 es una obligación organizativa que cubre las diez categorías del Artículo 21(2), la mayoría de las cuales son política y proceso, no software. StaticCodeAudit produce evidencia utilizable para dos de ellas — (d) y (e) — como parte de un programa de cumplimiento más amplio, no como sustituto de uno.

¿Estoy siquiera dentro del alcance de NIS2?

El alcance depende de su sector (uno de los 18 listados en el Anexo I o II de la directiva) y de su tamaño (a grandes rasgos 50+ empleados o €10M+ de facturación, con umbrales precisos y algunas excepciones bajo umbral). Esta es una determinación legal que debe hacer el consejo o el responsable de cumplimiento de su organización, no algo que la salida de un escáner pueda responder.

¿La salida SARIF/SBOM referencia NIS2 directamente?

No — las exportaciones son formatos estándar (OASIS SARIF 2.1.0, OWASP CycloneDX 1.5) sin campos específicos de NIS2. La conexión con el Artículo 21(2) está en cómo su proceso de cumplimiento usa la evidencia, no en algo codificado en el propio archivo.

¿Cómo se relaciona esto con las matrices ISO 27001 y ASVS de la página de estándares?

NIS2 no exige un estándar técnico específico, pero los Estados miembros y autoridades supervisoras suelen referenciar ISO/IEC 27001 y marcos similares como evidencia de medidas "de última generación". Las matrices de cumplimiento generadas por cada escaneo (ISO 27001 Anexo A, ASVS, NIST CSF) pueden servir como material de apoyo en esa conversación más amplia, en los mismos términos honestos: cobertura parcial, solo visible en el código.

Vea la evidencia real que produce un escaneo

Abra el informe de demostración en vivo — sin instalación, sin registro — y observe directamente las exportaciones SARIF/SBOM y las matrices de cumplimiento.

Abrir el informe en vivo Más información en la página de sectores regulados