La lección de DevSecOps cerró con una idea incómoda: ningún pipeline sustituye al criterio de quien escribe el código y aprueba los pull requests. Un escáner SAST detecta un patrón conocido, pero es un desarrollador quien decide validar una entrada, quien reconoce que un precio no debe venir del cliente, quien escribe una prueba para una amenaza del threat model. La seguridad, en última instancia, la producen personas. Por eso el factor humano no es un complemento del programa de seguridad: es su cimiento. En esta lección diseñamos la capacitación y concienciación de BazarNube, con security champions, formación en secure coding y gamificación, y lo enmarcamos en la práctica de Education & Guidance de SAMM.

1. Por qué el factor humano es decisivo
2. Formación en secure coding para desarrolladores
3. Security champions: seguridad distribuida
4. Gamificación: aprender atacando (Juice Shop, CTFs)
5. Concienciación general y phishing awareness
6. Métricas de un programa de concienciación
7. El programa de concienciación de BazarNube
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

La mayoría de las vulnerabilidades del Top Ten nacen de una decisión humana: concatenar SQL en lugar de parametrizar, olvidar una comprobación de autorización, confiar en un dato del cliente. Las herramientas ayudan a atrapar patrones, pero no todas las decisiones son un patrón detectable. Un fallo de lógica de negocio o de diseño (A04) rara vez lo encuentra un escáner; lo evita un desarrollador que ha aprendido a pensar como un atacante.

Además, la concienciación es lo que hace que el resto del programa funcione. Un pipeline DevSecOps con gates presupone un equipo que entiende por qué existen y no los sabotea; un threat model presupone gente capaz de imaginar amenazas. Sin cultura, las herramientas se convierten en obstáculos que la gente aprende a esquivar.

La formación genérica de "concienciación en seguridad" (no pinches enlaces raros) es necesaria para todos, pero insuficiente para quien construye software. Los desarrolladores necesitan secure coding: aprender a escribir código que resiste ataques, con ejemplos en su propio stack.

Características de una formación de secure coding eficaz:

• Específica del stack: ejemplos en React, Node/Express y Java/Spring —lo que el equipo usa de verdad—, no diapositivas genéricas.
• Basada en el Top Ten y ASVS: enseña a prevenir los riesgos reales y a cumplir requisitos verificables.
• Práctica, no solo teórica: se aprende corrigiendo código vulnerable, no escuchando.
• Continua: una sesión anual se olvida; mejor píldoras frecuentes ligadas a hallazgos reales del backlog.
• Contextual (just-in-time): el mejor momento para enseñar sobre inyección es cuando el SAST marca una en el PR de esa persona.

Una buena fuente de contenido son las OWASP Cheat Sheets (guías concisas por tema) y la WSTG, que veremos catalogadas en 07-05.

Un equipo de seguridad central nunca escala a decenas de equipos de desarrollo. La solución que promueven tanto OWASP como SAMM son los security champions: desarrolladores dentro de cada equipo que asumen un rol adicional de referente de seguridad.

Un security champion:

• No es un experto en seguridad a tiempo completo, sino un desarrollador con interés y algo de formación extra.
• Es el puente entre su equipo y el equipo de seguridad central.
• Ayuda a revisar PRs con foco de seguridad, facilita el threat modeling de su equipo (recordemos quién revisó el modelo del checkout en 07-02) y triaja los hallazgos del pipeline.
• Difunde la cultura desde dentro, con la credibilidad de un igual.

El programa de champions es una de las inversiones de mayor retorno para elevar la madurez, precisamente porque escala la cultura.

Se aprende mucho más rompiendo un sistema que leyendo sobre cómo se rompe. La gamificación convierte el aprendizaje en un reto atractivo:

• OWASP Juice Shop: aplicación web deliberadamente vulnerable, moderna (JavaScript), con decenas de retos que cubren todo el Top Ten. El alumno explota vulnerabilidades reales en un entorno seguro y gana puntos. Ideal para talleres internos.
• CTF (Capture The Flag): competiciones donde los equipos resuelven retos de seguridad para capturar "banderas". Fomentan el aprendizaje colaborativo y la sana competición.
• Entornos vulnerables: WebGoat (también de OWASP), DVWA y similares, para practicar técnicas concretas.

La gamificación tiene un beneficio cultural extra: al ponerse en el lado del atacante, el desarrollador interioriza por qué importan las defensas que antes veía como burocracia.

Más allá de quien programa, toda la organización maneja información y accesos. La concienciación general cubre a todos, incluidos roles no técnicos (product, ventas, dirección):

• Higiene básica: gestión de contraseñas, MFA, bloqueo de equipos, no reutilizar credenciales.
• Phishing awareness: el phishing sigue siendo una de las principales vías de entrada. A alto nivel, un programa incluye formación sobre cómo reconocer correos sospechosos y simulaciones de phishing controladas para medir y mejorar. La simulación debe usarse para educar, nunca para castigar o avergonzar: una cultura punitiva hace que la gente oculte los errores en lugar de reportarlos.
• Reporte fácil: un canal claro y sin fricción para avisar de algo sospechoso; reportar debe ser fácil y bien recibido.

Lo que no se mide no se puede mejorar. Un programa serio define métricas, evitando las puramente vanidosas (número de horas de formación) en favor de las que reflejan cambio de comportamiento y reducción de riesgo.

Las métricas de resultado (¿bajan los fallos reales?) valen más que las de actividad (¿cuánta formación dimos?). El objetivo último es que la tendencia de vulnerabilidades reintroducidas baje con el tiempo.

En BazarNube la seguridad la llevaba de facto Lucía en sus ratos libres. El programa formaliza y distribuye esa responsabilidad, enmarcado explícitamente en la práctica Education & Guidance del dominio Gobierno de SAMM.

Estructura de security champions:

Plan de formación (primer año):

El programa no es un curso puntual, sino un ciclo que se retroalimenta con las métricas y con los hallazgos reales, subiendo el nivel de madurez año a año.

• Formación genérica y anual. Una charla de una hora al año no cambia comportamientos. Prioriza formación específica del stack, continua y contextual (just-in-time sobre hallazgos reales).
• Phishing punitivo. Usar las simulaciones para señalar culpables destruye la confianza y hace que la gente oculte incidentes. Úsalas para educar y para medir la tendencia, no para castigar.
• Champions sin tiempo ni apoyo. Nombrar champions y no darles horas, formación ni reconocimiento condena el programa. El rol necesita respaldo explícito de dirección.
• Medir solo actividad. "Dimos 200 horas de formación" no dice si el equipo es más seguro. Mide resultados: ¿bajan los fallos reintroducidos?, ¿mejora el tiempo de corrección?
• Consejo: aprovecha la curiosidad. Un taller de Juice Shop donde la gente "hackea" de verdad genera más aprendizaje y entusiasmo que diez presentaciones. El engagement es el mejor multiplicador de la formación.

Ejercicio 1. BazarNube tiene un equipo central de dos personas y seis equipos de desarrollo. Propón un mecanismo para escalar la cultura de seguridad sin contratar y explica su lógica.

Ejercicio 2. Clasifica cada métrica como de actividad o de resultado e indica cuál es más valiosa: (a) horas de formación impartidas, (b) tendencia de vulnerabilidades de inyección por trimestre, (c) tasa de clics en simulaciones de phishing.

Ejercicio 3. El SAST marca una inyección SQL en el PR de un desarrollador junior. Describe cómo aprovechar ese momento como oportunidad de formación just-in-time.

Solución 1. Un programa de security champions: un desarrollador por equipo (seis en total) recibe formación extra y actúa de referente y puente con el equipo central. Su lógica es que un equipo central no escala a seis equipos, pero sí puede habilitar a seis champions que difunden la cultura desde dentro, con la credibilidad de un igual y el conocimiento profundo de su propio producto. Multiplica el alcance sin multiplicar la plantilla y es la práctica que SAMM recomienda.

Solución 2.

• (a) Actividad. (b) Resultado. (c) Resultado.
• La más valiosa es (b): mide si la formación realmente reduce la reintroducción del fallo, que es el objetivo final. (a) solo mide esfuerzo, no efecto.

Solución 3. En lugar de solo rechazar el PR, el security champion o un revisor comenta el hallazgo explicando por qué es vulnerable, enlaza la Cheat Sheet de prevención de inyección, muestra la corrección con consulta parametrizada y, si procede, pide una prueba que cubra el caso. Así el aprendizaje ocurre en el contexto real, sobre el código de esa persona y en el momento en que es más memorable, en vez de en una charla abstracta meses después.

El factor humano es el cimiento de todo el programa: las herramientas atrapan patrones, pero son las personas quienes toman las decisiones de diseño y quienes hacen que gates, threat models y pipelines funcionen en lugar de estorbar. Hemos diseñado el programa de BazarNube con secure coding específico del stack, security champions que escalan la cultura, gamificación con Juice Shop y CTFs, y métricas de resultado, todo enmarcado en la práctica Education & Guidance de SAMM. A lo largo de estas lecciones han aparecido muchas herramientas y recursos por su nombre. En la última lección del módulo, 07-05, los reunimos en un panorama ordenado por categorías y definimos el stack de seguridad recomendado para BazarNube, cerrando así las buenas prácticas antes de pasar a ponerlas en juego.