Artículo 30 del BSIG y tu propio código: las evidencias fechadas que genera un escaneo en cada commit

Qué exige realmente el artículo 30 del BSIG

El texto es más corto de lo que muchos proveedores cuentan. El apartado 1 obliga a las entidades esenciales e importantes a adoptar medidas técnicas y organizativas adecuadas, proporcionadas y eficaces, y cierra con una frase que marca el tono de cualquier auditoría: el cumplimiento de esta obligación debe documentarse. El apartado 2 enumera después qué deben cubrir como mínimo esas medidas. El número 5 dice: medidas de seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas, componentes y procesos informáticos, incluidas la gestión y la divulgación de vulnerabilidades. El número 6 añade conceptos y procedimientos para evaluar la eficacia de esas medidas.

En ese texto faltan dos cosas, y faltan a propósito. No hay ningún producto y no hay ningún procedimiento. El legislador describe un resultado, a saber, poder conocer, tratar y divulgar vulnerabilidades, y deja el camino en manos de la entidad. Quien afirma que existe una obligación de comprar un escáner lee algo que no está escrito. Así lo dejamos por escrito en nuestra página sobre seguridad del código y cumplimiento, y así lo mantenemos aquí.

Por qué tu propio código cae bajo el número 5

El número 5 habla de sistemas, componentes y procesos, no de software en sentido estricto. En la práctica, sin embargo, las vulnerabilidades que un atacante encuentra primero están exactamente ahí: en una clave API subida hace tres años que sigue en el historial del repositorio, en una biblioteca de código abierto con un fallo público desde hace meses, o en una entrada que se pasa sin comprobar a una base de datos. Las tres son vulnerabilidades en el sentido de la ley. Las tres surgen durante el desarrollo o el mantenimiento. Y las tres solo pueden gestionarse si alguien las busca con regularidad.

Justo ahí es donde fracasa una comprobación anual. Un hallazgo de marzo no dice nada sobre el commit de junio. El número 5 no exige una fecha, pero el deber de documentación del apartado 1 sí, y un auditor que lee el expediente pregunta primero cuán actual es.

Qué deja un escaneo en cada commit como prueba

Un escaneo continuo genera cuatro datos por hallazgo, y son exactamente los cuatro que pertenecen a un expediente. Primero, el hallazgo en sí: contraseña escrita en el código, dependencia vulnerable, patrón inseguro. Segundo, la clasificación según el riesgo real, después de que una persona haya comprobado si el hallazgo es siquiera explotable en el contexto de la base de código. Tercero, la medida: secreto rotado, biblioteca actualizada, patrón neutralizado. Cuarto, la fecha en que se aplicó la medida.

A lo largo de semanas, esos cuatro puntos se convierten en una documentación que no hay que recopilar antes de la auditoría porque nace mientras se trabaja. Cómo funciona eso para el resto de deberes de NIS2 lo explicamos en nuestro artículo sobre cómo demostrar la conformidad NIS2 en el día a día. Para el código rige el mismo principio, solo cambia la herramienta.

Al expediente pertenece también lo que no está en él: los falsos positivos se descartan antes de llegar al informe. Un auditor que ve 400 resultados de los que 380 no eran explotables no aprende nada sobre la seguridad, solo algo sobre el escáner.

Cómo no debería ser una evidencia

Tres formas aparecen una y otra vez en las pymes, y ninguna resiste una pregunta de seguimiento. La lista en bruto de un escáner sin clasificación: demuestra que una herramienta se ejecutó, no que alguien actuó. La captura de pantalla de final de año: demuestra un día, no un proceso. Y la autodeclaración en un cuestionario de que se desarrolla de forma segura: demuestra que alguien marcó una casilla.

El número 6 del apartado 2 lo deja aún más claro. Quien debe evaluar la eficacia de sus medidas necesita datos sobre si la medida ha funcionado a lo largo del tiempo, algo que una instantánea aislada no puede mostrar y una serie fechada sí.

De dónde sale la prueba, paso a paso

El día 0 se conectan los repositorios y el inventario se revisa por primera vez en busca de secretos, dependencias vulnerables y patrones inseguros. A las 48 horas está el primer hallazgo: qué es real y crítico, qué puede esperar, qué debe ocurrir primero. Durante la primera semana se rotan los secretos críticos, se actualizan bibliotecas, se neutralizan patrones peligrosos, y cada una de esas medidas recibe una fecha. A partir de ahí la comprobación continúa en cada commit, y el expediente crece con el código y no antes de la fecha de auditoría.

El punto de entrada es el análisis de código gratuito: conexión, escaneo del inventario y hallazgo priorizado, sin compromiso, en tu propio entorno si lo prefieres.

Preguntas frecuentes