Los laboratorios de seguridad enseñan a atacar y nadie evalúa el arreglo

En PortSwigger, Hack The Box, TryHackMe y cualquier CTF, el ejercicio termina cuando el exploit funciona o se captura la bandera. Nadie pide el diff. Ese formato produce gente entrenada para encontrar fallos y no para arreglarlos, y varios informes señalan el mismo cuello de botella: el arreglo.

El diseño se ve en cómo se puntúa. En PortSwigger Web Security Academy el laboratorio queda resuelto en cuanto se alcanza el objetivo: se abre el panel de administración, aparece el dato del otro usuario, salta la alerta. En las máquinas de Hack The Box y las salas de TryHackMe, cuando se envía la bandera. La lectura adjunta suele traer una sección de prevención, pero lo que se califica es el ataque. No es mala fe: el CTF nació para formar a pentesters, y para ese público que el payload funcione es el trabajo. El problema es quién acabó usándolo: desarrolladores, estudiantes y gente que cambia de carrera, cuyo empleo real será detener el payload, no lanzarlo.

Los datos

El Linux Foundation y OpenSSF encuestaron a unos 400 profesionales del desarrollo en 2024. Casi uno de cada tres dijo no estar familiarizado con las prácticas de desarrollo seguro. El 69% aprendió en el trabajo, y el informe calcula que hacen falta unos cinco años por esa vía para alcanzar un nivel mínimo de soltura; los obstáculos más citados fueron la falta de tiempo (58%) y la falta de formación y concienciación (50%).

Secure Code Warrior analizó nueve años de datos de 600 clientes corporativos: las organizaciones con más de 7.000 desarrolladores formados en prácticas secure-by-design introdujeron entre un 47% y un 53% menos de vulnerabilidades, y en las menores el rango iba del 20% al 80%. El mismo análisis estima que solo alrededor del 4% de los desarrolladores del mundo aplica las prácticas secure-by-design de CISA.

Gasiba y sus colegas partían de una encuesta a más de 4.000 desarrolladores en la que menos de la mitad detectaba un agujero de seguridad, y propusieron retos de escritura de código validados por un entrenador automático. La idea venía de antes: el concurso Build It, Break It, Fix It añadió en 2016 una fase de reparar lo que otros equipos habían roto.

Veracode, en su informe de deuda de seguridad de 2026, dice que el 82% de las organizaciones arrastra deuda —un 11% más que el año anterior— y que el 60% la tiene clasificada como crítica; el 49% de las aplicaciones acumula fallos sin arreglar desde hace más de un año. En HackerOne los envíos crecieron un 76% hasta marzo de 2026, los resueltos al mes cayeron cerca de un 46% y el backlog de hallazgos validados sin arreglar se multiplicó por más de veinte. curl cerró su programa de recompensas por lo que su mantenedor describió como informes basura y mal investigados.

La IA no creó esto: automatizó la primera mitad. Genera un payload plausible y un párrafo verosímil sobre el impacto a coste casi nulo, pero no una causa raíz verificada, que es la parte que siempre escaseó.

Qué cambia puntuar el arreglo

Un laboratorio que acaba en la bandera enseña dónde va el payload; uno que acaba en un test en verde enseña dónde vive la decisión. El formato: se explota el fallo para que el error sea concreto, se entrega el handler vulnerable —la función real, no una descripción— y el alumno lo modifica. El servidor relanza el exploit original y una pequeña suite de regresión contra su versión. Verde significa que el exploit ya no funciona y que el comportamiento legítimo sigue en pie. De ahí sale conocimiento concreto: que una consulta parametrizada es una frontera y no un truco de cadenas, o que una lista blanca va en el sink y no en el formulario.

Queda por ver si las plataformas cambian el criterio de evaluación. Con el 82% de las organizaciones cargando deuda y una cola que no deja de crecer, enseñar a arreglar sale más barato que seguir triando hallazgos.