Desarrollo seguro según NIS2, ISO 27001 y CRA. Qué se exige, qué demuestra un escaneo continuo.
Cuatro marcos normativos hablan de la seguridad de tu propio código. Ninguno prescribe un producto de escaneo. Esta página muestra dónde está cada requisito, dice abiertamente dónde no existe una obligación expresa y ordena qué evidencia aporta para cada uno un escaneo en cada commit.
A quien en una auditoría le preguntan cómo trata las vulnerabilidades de su propio código le hacen falta dos cosas: la referencia correcta en la norma y una prueba fechada. Lo primero lo ofrece esta página. Lo segundo nace del escaneo continuo, con hallazgo, medida y fecha.
Dónde está realmente el desarrollo seguro.
Dos son catálogos de obligaciones, uno se aplica solo a fabricantes y uno ni siquiera es una ley. La diferencia decide qué tienes que presentar en una auditoría.
Seguridad en la adquisición, el desarrollo y el mantenimiento
El catálogo de medidas de la directiva dedica una letra propia al tratamiento de los sistemas a lo largo de su ciclo de vida: adquirir, desarrollar, mantener, gestionar y divulgar vulnerabilidades. Alemania lo ha traspuesto en el artículo 30, apartado 2, número 5 del BSIG (ley alemana de seguridad informática). Quien opera su propio código entra en esa letra con cada fallo que contenga. Cómo los encuentra, el legislador lo deja abierto.
Ciclo de vida de desarrollo seguro
La revisión de 2022 separó el desarrollo seguro en controles que un auditor repasa hoy uno a uno: A.8.25 cubre cómo se organiza el ciclo de vida del desarrollo, A.8.26 los requisitos de seguridad que debe cumplir una aplicación, A.8.28 la codificación segura en sí y A.8.8, transversal a los tres, cómo se tratan técnicamente las vulnerabilidades conocidas. Cada uno de los cuatro pide su propia evidencia.
Obligaciones para productos con elementos digitales
Donde NIS2 se dirige a los operadores, el CRA se dirige a quien pone en el mercado software o un dispositivo conectado, y su responsabilidad dura mientras el producto esté en uso. Las fechas van escalonadas: en vigor desde el 10 de diciembre de 2024, el deber de notificar vulnerabilidades explotadas activamente vigente desde el 11 de septiembre de 2026, todo lo demás a partir del 11 de diciembre de 2027. Una empresa que solo usa software de puertas adentro no es fabricante y no está en la lista.
El marco de referencia técnico
El Top 10 es una clasificación, no una regla: las diez clases de riesgo que con más frecuencia provocan incidentes en aplicaciones, reordenadas cada pocos años. En la edición de 2025 encabeza la lista el control de acceso deficiente, y la cadena de suministro de software entra por primera vez entre los tres primeros. Usamos la lista como orden para evaluar los hallazgos. Quien la vende como certificado no la ha leído.
Para dejarlo claro antes de que alguien lea aquí una obligación de compra: en ninguno de los cuatro textos se prescribe un escáner. Lo que se exige es un resultado, a saber, conocer, evaluar y corregir vulnerabilidades, no un producto. Y el CRA solo se aplica a fabricantes. Lo que aporta un escaneo continuo es la documentación de ese resultado con fecha. No afirmamos nada más.
Qué prueba encaja con qué referencia.
Una auditoría rara vez pregunta por la herramienta. Pregunta si un requisito está implantado y con qué lo demuestras. Así queda la correspondencia.
- Gestión de vulnerabilidades
Artículo 30 del BSIG, ISO A.8.8
Todas las dependencias se comprueban contra vulnerabilidades conocidas. Cuando se actualiza una biblioteca, el hallazgo, la medida y la fecha quedan en la documentación.
- Codificación segura
ISO A.8.28
Los patrones inseguros como entradas sin validar, llamadas peligrosas al sistema y controles de acceso ausentes se detectan en cada commit, no una vez al año en la fecha de la auditoría.
- Gestión de credenciales
Artículo 30 del BSIG, ISO A.8.28
Las contraseñas, claves y tokens escritos en el código se encuentran, también en el historial del repositorio, y los secretos críticos se rotan en lugar de solo notificarse.
- Ciclo de vida del desarrollo
ISO A.8.25, A.8.26
Cada cambio se evalúa en el contexto de la base de código antes de que el código siga adelante. Esa es la prueba de que la seguridad está en el proceso y no solo en el informe anual.
Tres cosas que un escaneo no hace. Y que no afirmamos.
No sustituye a una prueba de penetración.
El escaneo trabaja en un solo sitio: en el código, en cada cambio, contra patrones conocidos. Una prueba de penetración parte desde fuera e intenta superar el sistema en funcionamiento como un todo, incluidos red, configuración y personas. Tener uno no te da el otro. Lo que debe aportar una prueba y lo que ocurre después del informe está en nuestra página sobre el test de penetración.
No encuentra errores de lógica de negocio.
Si un administrativo puede ver las facturas de otro departamento no está escrito en ningún patrón, sino en las reglas del negocio. Ningún análisis automático detecta esos errores en la lógica de autorización, y una evidencia que fingiera lo contrario sería falsa. No la escribimos.
No es un certificado.
El escaneo genera pruebas para controles concretos. Un sistema de gestión, una certificación o la evaluación de eficacia del artículo 30 del BSIG siguen siendo pasos propios que apoya, pero no asume.
De la conexión al expediente fechado.
Conexión
Se conectan los repositorios y el inventario se escanea por primera vez en busca de secretos, dependencias vulnerables y patrones inseguros.
Primer hallazgo
Un informe claro: qué hallazgos son reales y críticos, cuáles pueden esperar y qué debe ocurrir primero.
Limpieza
Secretos críticos rotados, bibliotecas vulnerables actualizadas, patrones peligrosos neutralizados. Cada medida con fecha.
Demostrar
A partir de ahora, en cada commit. Los nuevos hallazgos críticos se tratan de inmediato y la documentación crece con el trabajo en lugar de recopilarse antes de la auditoría.
Preguntas sobre seguridad del código y cumplimiento
¿Es obligatorio un escáner de código según NIS2?
No. Lo que se prescribe es el resultado: poder conocer, tratar y divulgar las vulnerabilidades de los propios sistemas, artículo 30 del BSIG. Cómo lo consigue una empresa es decisión suya. La razón por la que aun así recomendamos el escaneo es la evidencia: deja tras cada hallazgo una fecha y una medida, y eso es exactamente lo que pregunta una autoridad supervisora.
¿Se aplica el Cyber Resilience Act a nuestra empresa?
La cuestión es si vendéis algo con software dentro: una máquina con su control, un dispositivo con app, un producto de software. Entonces sois fabricantes en el sentido del reglamento, y los plazos corren, desde el 11 de septiembre de 2026 para la notificación de vulnerabilidades explotadas, a partir del 11 de diciembre de 2027 para el resto. Si solo usáis software vosotros mismos, el CRA no os afecta, aunque NIS2 posiblemente sí.
¿Basta el escaneo como evidencia para ISO 27001?
Respalda los controles A.8.25, A.8.26 y A.8.28 sobre desarrollo seguro y A.8.8 sobre gestión de vulnerabilidades con hallazgos y medidas fechados. Un sistema de gestión y la propia certificación siguen siendo pasos propios que el escaneo apoya, pero no sustituye.
¿Qué contiene concretamente la evidencia?
Para cada hallazgo, la clasificación según el riesgo real, la medida aplicada y la fecha: secreto rotado, biblioteca actualizada, patrón neutralizado. Los falsos positivos se descartan antes de llegar al expediente.
¿Esto sustituye a una prueba de penetración?
No. Las dos comprobaciones responden a preguntas distintas: el escaneo, si hay clases de fallos conocidas en el código; la prueba, si un atacante entra desde fuera. Un auditor que quiere ver una prueba de penetración no acepta un informe de escaneo como sustituto, y viceversa.
¿Qué evidencias te faltan hoy para el artículo 30 del BSIG o A.8.28?
Análisis de código gratuito, resultado claro, sin compromiso.