Security Champions en el desarrollo de software

Un Security Champion es un miembro del equipo de desarrollo que actúa como enlace entre la seguridad de la información y el desarrollo; según OWASP SAMM, puede ser un desarrollador de software, un tester o un product manager. Entre sus tareas típicas figuran la investigación, verificación y priorización de defectos relevantes para la seguridad, la participación en evaluaciones de riesgos, threat modeling y arquitectura, así como revisiones periódicas centradas en la seguridad dentro de su propio equipo. También el NIST Secure Software Development Framework (SP 800-218, versión 1.1) menciona a los Security Champions en sus ejemplos de implementación: como rol del SDLC a definir (PO.2.1) y como destinatarios preferentes de las formaciones en threat modeling (PW.1.1). Los champions no sustituyen a un equipo central de AppSec, sino que escalan su impacto a toda la organización.

La OWASP Developer Guide desaconseja los nombramientos arbitrarios: el rol presupone un interés genuino por la seguridad de las aplicaciones, por lo que los miembros del equipo motivados deberían presentarse voluntariamente; no es casualidad que el primer principio del manifiesto de OWASP sea «Be passionate about security». Dado que los champions conservan su función original, esta tarea adicional requiere un presupuesto de tiempo garantizado formalmente; OWASP SAMM prevé expresamente un número fijo de horas semanales para actividades de seguridad, sin prescribir un valor concreto. Han dado buenos resultados un champion por equipo de desarrollo y una dirección de programa dedicada («captain») responsable de la visión, el onboarding y la coordinación. Sin un apoyo visible de la dirección («Secure management support»), la experiencia demuestra que el presupuesto de tiempo es lo primero que se sacrifica bajo la presión de los proyectos.

Los champions generan un efecto duradero cuando no trabajan aislados, sino dentro de una comunidad de práctica: los principios «Create a community» y «Promote knowledge sharing» de la guía OWASP recomiendan encuentros periódicos, canales de comunicación compartidos y talleres internos que trasciendan los límites de los equipos. En cuanto a los incentivos rige «Reward responsibility»: reconocimiento formal (por ejemplo, distinciones o insignias), presupuesto para formaciones y conferencias, itinerarios de carrera y mandatos ampliados, como la participación en comités de seguridad, ajustados —según recomienda la guía— a las motivaciones individuales de cada champion. Lo decisivo es que la responsabilidad adicional se recompense de forma visible; de lo contrario, la motivación de los voluntarios se erosiona con el tiempo.

La OWASP Security Champions Guide (actualmente proyecto incubador de OWASP) es una obra de referencia abierta y neutral respecto a fabricantes, basada en entrevistas con responsables de AppSec, coordinadores de programas y champions de distintos sectores y tamaños de empresa. Su núcleo es el Security Champions Manifesto con diez principios: desde «Be passionate about security», pasando por «Start with a clear vision for your program», «Nominate a dedicated captain» y «Trust your champions», hasta «Anticipate personnel changes». La guía se concibe expresamente como una caja de herramientas: no existe un modelo válido para todas las organizaciones; para cada principio ofrece explicaciones y artefactos adaptables al propio programa.

En el OWASP Software Assurance Maturity Model (SAMM, versión actual del modelo 2.2.0, de julio de 2025), los Security Champions están anclados en el stream «Organization and Culture» de la práctica Education & Guidance (función de negocio Governance). El nivel de madurez 1 exige identificar un champion en cada equipo de desarrollo y concederle un contingente fijo de horas semanales; el nivel 2 añade un Secure Software Center of Excellence formado por arquitectos y desarrolladores sénior de distintas áreas de negocio; el nivel 3 establece plataformas de intercambio de conocimiento a escala de toda la organización. Un programa de champions no solo puede construirse, sino también posicionarse objetivamente en el marco de una evaluación SAMM y desarrollarse paso a paso.

La guía OWASP recomienda respaldar la visión del programa con objetivos medibles y cita como ejemplos las horas dedicadas a la seguridad por champion, los objetivos de formación alcanzados, el número de encuentros de champions y la reducción del riesgo de seguridad; como complemento resultan útiles el grado de cobertura de los equipos y las vulnerabilidades detectadas en fases tempranas del proceso de desarrollo. Los errores más frecuentes son el reflejo inverso de los principios: champions como mera fachada sin mandato, un presupuesto de tiempo inexistente o solo informal, nombramientos por orden jerárquica en lugar de voluntariedad, una comunidad que se apaga tras el kick-off y la falta de planificación de la sucesión ante cambios de personal. SAFECode subraya expresamente que la mera designación de un champion, sin un programa formalizado y respaldado por la dirección, suele toparse con resistencias o fracasar por completo.