Todos los artículos

Blog

Formación en desarrollo seguro: la puntuación no mide la vigilancia

Formación en desarrollo seguro: PortSwigger, Juice Shop, Secure Code Warrior, presencial. Qué mide cada opción y qué no ve en la revisión de código.

  • Por Azziz ERRIME
  • 12 min de lectura
Formación en desarrollo seguro: mesa de revisión vista desde arriba, con una sola pila de hojas iluminada por una lámpara

TL;DR

  • Una formación en desarrollo seguro se juzga por lo que hacen los desarrolladores cuando nadie se lo pide, y ninguna de las opciones comparadas lo mide en revisiones reales.
  • En un experimento publicado en 2022, pedir a los revisores que se centraran en la seguridad multiplicaba por ocho la detección de vulnerabilidades.
  • Yo elegiría la plataforma por lo que enseña al equipo, y además mediría la vigilancia en las revisiones de código reales.

En un experimento publicado en 2022, unos investigadores piden a 150 desarrolladores que revisen un cambio de código vulnerable, y solo a algunos les piden que piensen en la seguridad. Esos encuentran las vulnerabilidades ocho veces más a menudo. Con este resultado tropieza cualquier formación en desarrollo seguro: mide lo que los desarrolladores saben hacer cuando se les pide.

Larissa Braz, Christian Aeberhard, Gül Çalikli y Alberto Bacchelli reclutan a 150 desarrolladores, de los que el 71 % declara al menos tres años de experiencia profesional. Cada uno recibe un cambio de código para revisar, como los que llegan a diario en un pull request, y ese cambio contiene vulnerabilidades. Algunos participantes leen una instrucción más, centrarse en la seguridad, y otros reciben además una lista de comprobación. Después, cada uno decide, solo frente al código, qué señala.

El resultado se presenta en la conferencia ICSE de 2022. Su artículo lo resume así: «simply asking reviewers to focus on security during the code review increases eight times the probability of vulnerability detection». La lista de comprobación, incluso adaptada al cambio revisado, no aporta nada significativo. Los autores recuerdan de paso que los desarrolladores «often miss even popular and easy-to-detect vulnerabilities during code review».

Los revisores sin instrucción no tenían ningún motivo para ser menos competentes que los demás. Sencillamente tenían la atención puesta en otra cosa, una situación que las formaciones comparadas más abajo no reproducen.

La atención del revisor pesa más que lo que sabe

Los autores hablan de la hipótesis de la «actitud mental»: el revisor encuentra lo que busca, y busca lo que le han pedido que busque. La revisión de código, ese momento en que un desarrollador revisa el cambio de un compañero antes de que se incorpore al código común, se ocupa primero de la lógica, los nombres y los tests. La seguridad entra en ella cuando alguien la pone sobre la mesa.

En la práctica, una vulnerabilidad de inyección en un pull request parece una línea cualquiera. Una variable pasa de un formulario a una consulta sin filtrar, y nada la delata ante el ojo que comprueba que la funcionalidad va bien. El revisor que sabe reconocer una inyección la deja pasar si no la está buscando. El atacante, en cambio, solo busca eso: localiza los campos que aceptan datos de entrada y sigue el dato hasta la base de datos.

Ahora bien, las plataformas comparadas más abajo hacen la pregunta en lugar del revisor: aquí tienes código, encuentra la vulnerabilidad. Es justo la instrucción que recibió una parte de los revisores del experimento. Una formación en desarrollo seguro puede, por tanto, hacer crecer el conocimiento sin decir nada de la atención.

Las plataformas de formación en desarrollo seguro miden sobre todo el rendimiento con aviso previo

En esta tabla de opciones de formación en seguridad de aplicaciones, solo recojo lo que publican los proveedores o la prensa especializada. La fila «presencial» describe el uso habitual, no a un proveedor concreto.

Opción Qué se hace Qué se mide y se informa ¿Sabe el desarrollador que lo están evaluando?
PortSwigger Web Security Academy Labs de ataque a aplicaciones web, por ejemplo 30 sobre cross-site scripting Labs resueltos, progreso, ranking Hall of Fame; la Academy es gratuita Sí
OWASP Juice Shop Retos sobre una aplicación vulnerable a propósito, gratuita y open source Marcador de retos Sí
Snyk Learn Lecciones y rutas, gratuitas Porcentaje completado Sí
Security Journey Rutas de formación en código seguro, con precio bajo presupuesto Evaluaciones, informes al LMS (SCORM, xAPI) Sí
Secure Code Warrior Retos sobre código Trust Score por desarrollador; Trust Agent: AI vincula los commits reales con las herramientas de IA utilizadas Sí en la formación, en parte en los commits monitorizados
Immersive (Developer AI Ranges) Pull requests y triaje de un backlog frente a agentes de código Lo que se detectó o se pasó por alto, con un veredicto de referencia Sí, el ejercicio se anuncia
Formación presencial Clases y prácticas con un formador Hoja de firmas, evaluación al final de la sesión Sí

Cada una tiene su punto fuerte: PortSwigger enseña la mecánica de los ataques web sin costar un euro. OWASP Juice Shop, gratuito y open source, sirve de terreno para talleres. Snyk Learn ofrece lecciones y rutas, también gratuitas. Security Journey conecta sus resultados con la herramienta de seguimiento de la formación de la empresa. Secure Code Warrior propone retos sobre código. La formación presencial permite hacer preguntas a un formador durante las prácticas.

Immersive es la que más se acerca a lo real. Desde el 29 de julio de 2026, sus Developer AI Ranges ponen a los desarrolladores frente a pull requests y agentes de código. Cada ejercicio termina con un veredicto de referencia sobre «what was caught or missed», lo que se detectó o se pasó por alto. Es el enfoque público más cercano a una revisión real que he encontrado. Aun así, el desarrollador sabe que está en un ejercicio. Solo Trust Agent: AI, de Secure Code Warrior, observa commits reales. Cruza el Trust Score y el uso de la IA con vulnerabilidades, pero no dice qué dejó pasar la revisión.

Si ninguna de estas mediciones observa la revisión en sí, ¿qué mira el auditor cuando comprueba la formación en seguridad de los desarrolladores?

Caseta de tiro de feria con las dianas acertadas en el centro y una diana volcada en la sombra

Las dianas anunciadas reciben los disparos en pleno centro. La del día a día espera en la sombra.

La auditoría valida la formación sin ver la revisión del lunes

Pongamos el caso de PCI DSS, la norma de seguridad de las tarjetas de pago. Su requisito 6.2.2 exige que los desarrolladores de software a medida reciban formación en seguridad al menos una vez cada 12 meses. Para comprobarlo, el evaluador sigue un procedimiento concreto, el 6.2.2.b: «Examine training records and interview personnel». Lee los registros y entrevista a los equipos.

El registro dice quién siguió qué formación, en qué fecha y con qué puntuación. Es precisamente lo que envían las plataformas de la tabla; Security Journey, por ejemplo, lo hace directamente a la herramienta de gestión de la formación. Nada en este circuito mira qué fue del último pull request que tocaba una consulta a la base de datos.

No le reprocho nada a este circuito, que demuestra que una formación ha tenido lugar, que es lo que se le pide. El riesgo está en lo que se deduce de él: una tasa de finalización del 100 % tranquiliza al comité de dirección sobre una competencia que nadie ha observado en una situación real. La brecha crece con la IA, que aumenta el volumen de código por revisar, como explicaba en un artículo anterior sobre la revisión de código.

Queda la objeción más sólida: algunas plataformas afirman, precisamente, medir un efecto sobre las vulnerabilidades, no solo la asistencia.

Un descenso de vulnerabilidades tras una formación en desarrollo seguro no dice de dónde viene la vigilancia

Secure Code Warrior publicó el 15 de octubre de 2024 un estudio, presentado por CyberScoop, basado en los datos de 600 clientes empresariales. En las organizaciones de más de 7 000 desarrolladores que siguen un mismo programa, el proveedor mide entre un 47 y un 53 % menos de vulnerabilidades.

Me lo tomo en serio, porque mide un resultado, las vulnerabilidades, donde muchos estudios sobre formación se quedan en la satisfacción. También es un estudio del proveedor, con datos de su propia plataforma, y los documentos públicos que he podido leer no detallan cómo se contaron las vulnerabilidades. Puede ser correcto y aun así no responder a la pregunta de este artículo.

Una bajada de vulnerabilidades en el código de una gran organización formada mezcla varias causas: mejores reflejos al escribir, herramientas de análisis mejor configuradas, revisiones más atentas. El estudio no permite decir cuál ha influido. Y la vigilancia en la revisión es justamente la parte que ninguna fila de la tabla observa en la propia revisión.

Por tanto, la formación en desarrollo seguro sigue siendo necesaria: sin ella, nadie sabe qué aspecto tiene una inyección en mitad de un pull request. Falta completarla con una medición de lo que ocurre fuera de los ejercicios.

La línea de seguridad en la plantilla de pull request es la medida más barata

Se aprende en la plataforma que mejor encaja con el stack tecnológico del equipo. Lo que la revisión deja pasar se mide en otra parte, en el trabajo real. Para un equipo, esto es lo que yo haría, en este orden:

  • empezar por los recursos gratuitos, PortSwigger, Juice Shop y Snyk Learn, para ver qué engancha al equipo antes de firmar un contrato;
  • elegir la plataforma de pago por tus lenguajes y tus frameworks, no por el tamaño de su catálogo;
  • preguntar al proveedor qué se puede exportar: una tasa de finalización o resultados por competencia que puedas cruzar con tus revisiones;
  • llevar aparte el seguimiento de lo que la revisión deja pasar, vinculando cada vulnerabilidad encontrada más tarde, en un test o en producción, con la revisión por la que pasó;
  • añadir a la plantilla de pull request una línea que pregunte si se ha revisado la seguridad.

Esta última línea es la medida más barata y la más cercana a la instrucción probada en 2022. Todavía no sé si conserva su efecto una vez que se vuelve rutina.

Lo aclaro: imparto formaciones y mido este tipo de brecha, lo que los desarrolladores dejan pasar cuando revisan código escrito por una IA. La formación les da el vocabulario. Quiero saber cuándo lo usan sin que nadie se lo pida.

Cabina de señalización ferroviaria vacía, con una palanca marcada con una cinta roja

El gesto que cuenta se hace en la cabina, en el momento en que pasa el tren.

El revisor sin instrucciones es tu equipo un lunes por la mañana

Vuelvo a los 150 desarrolladores del experimento. Los que no habían recibido instrucciones se parecen como dos gotas de agua a tus equipos un lunes por la mañana, con una cola de pull requests que vaciar antes de la reunión. Puede que hayan aprendido a reconocer una vulnerabilidad, pero nadie les ha pedido que la busquen en ese momento.

Una formación en desarrollo seguro bien elegida les enseña qué buscar. Ninguna garantiza que lo busquen. Por eso no elegiría una plataforma por su catálogo ni por la puntuación media que muestra. Frente a cada euro de formación, pondría una medición de lo que pasa la revisión real.

Me queda una duda: en cuanto un desarrollador sabe que se observan sus revisiones, revisa mejor. El código sale ganando y la medición sale perdiendo, porque vuelve a ser una instrucción. Todavía no he encontrado cómo observar la vigilancia sin cambiarla.

Preguntas frecuentes sobre la formación en desarrollo seguro

¿Qué es el secure coding?

El secure coding, o desarrollo seguro, agrupa las prácticas que evitan introducir vulnerabilidades al escribir el código: validar las entradas, controlar los accesos, elegir dependencias seguras. La norma PCI DSS lo convierte en materia de formación obligatoria para los desarrolladores de software a medida. Su requisito 6.2.2 exige una formación al menos cada 12 meses, que cubra en particular las «secure coding techniques».

¿Qué formación en ciberseguridad elegir para desarrolladores?

Para una primera formación en desarrollo seguro sin presupuesto, la Web Security Academy de PortSwigger es totalmente gratuita, como OWASP Juice Shop y Snyk Learn. Las plataformas de pago añaden, entre otras cosas, evaluaciones e informes para el seguimiento de la formación. En cualquier caso, mide aparte lo que pasa tus revisiones de código, donde una simple instrucción de seguridad cambia claramente la detección, según Braz y sus colegas.

¿Existe un curso de desarrollo seguro OWASP gratis?

Sí, OWASP Juice Shop, proyecto de la fundación OWASP publicado con licencia MIT, es una aplicación vulnerable a propósito cuyos retos se siguen en un marcador. Para una ruta más guiada, la Web Security Academy de PortSwigger, también gratuita, cubre las grandes familias de vulnerabilidades web.

¿Qué es Secure Code Warrior?

Secure Code Warrior es una plataforma de formación en código seguro que asigna a cada desarrollador un Trust Score. Desde marzo de 2026, su módulo Trust Agent: AI vincula los commits con las herramientas de IA que han influido en ellos, según Help Net Security. Un estudio del proveedor publicado en octubre de 2024 reivindica entre un 47 y un 53 % menos de vulnerabilidades en las grandes organizaciones formadas.

Fuentes