El Security Champion en desarrollo y DevOps
En el Módulo 2, implementó victorias rápidas: gestores de contraseñas, MFA, seguridad del correo electrónico. Estas protegen el perímetro. El Módulo 3 trata de proteger lo que usted construye.
La mayoría de las vulnerabilidades de seguridad nacen en el código. La inyección SQL, XSS, la autenticación rota, los endpoints de API inseguros — estos no son errores de configuración, son errores de desarrollo. Y son extremadamente comunes porque los desarrolladores no reciben formación en seguridad, los equipos de seguridad no entienden el desarrollo, y ambos grupos rara vez se comunican.
El Security Champion cierra esta brecha. Usted es un desarrollador (o ingeniero DevOps) que entiende ambos mundos. Puede revisar el código en busca de problemas de seguridad, explicar por qué ciertas prácticas importan e integrar controles de seguridad en el flujo de trabajo de desarrollo sin ralentizar todo.
Este capítulo define su rol en el proceso de desarrollo: dónde encaja, qué hace y cómo trabajar eficazmente con su equipo.
Por qué el desarrollo necesita un Security Champion
El problema de la desconexión
La seguridad tradicional funciona así:
- Los desarrolladores construyen funcionalidades
- El equipo de seguridad las revisa al final (o nunca)
- Seguridad encuentra problemas
- Los desarrolladores tienen que volver y corregir las cosas
- Todos están frustrados
Esto falla por varias razones:
Timing: Para cuando se realizan las revisiones de seguridad, la funcionalidad ya está terminada. Las correcciones son costosas. Los plazos se incumplen. La presión aumenta para lanzar de todos modos.
Conocimiento: Los equipos de seguridad no conocen el código base. Señalan problemas sin entender el contexto. Los desarrolladores no entienden la seguridad. Descartan los hallazgos como teóricos.
Comunicación: Seguridad habla en CVEs y categorías OWASP. Los desarrolladores hablan en funciones y pull requests. Ninguno de los dos lado traduce bien.
Escalabilidad: Un equipo de seguridad de 2 personas no puede revisar el código de 50 desarrolladores. La mayoría del código se lanza sin ninguna revisión de seguridad.
La solución del Security Champion
Usted está integrado en el equipo de desarrollo. Escribe código. Entiende la arquitectura. Sabe qué partes son apresuradas y cuáles son sólidas. Asiste a los standups y ve lo que se está construyendo.
Esto significa:
- La aportación de seguridad ocurre durante el diseño, no después
- Puede explicar por qué algo es riesgoso, no solo que es riesgoso
- Los desarrolladores confían en usted porque es uno de ellos
- Puede priorizar en función del riesgo real, no de preocupaciones teóricas
No está reemplazando a un equipo de seguridad. Está extendiendo la seguridad al trabajo de desarrollo diario.
Dónde encaja en el proceso de desarrollo
El modelo shift-left
"Shift left" significa mover la seguridad más temprano en el proceso de desarrollo. Cuanto más a la izquierda (más temprano), más baratas y fáciles son las correcciones.
Tradicional:
Design → Develop → Test → Deploy → Security Review → Fix
↑
(expensive fixes)
Shift-left:
Design → Develop → Test → Deploy
↓ ↓ ↓ ↓
Security Security SAST Security
input review DAST config
↑
(cheap fixes)
Sus puntos de contacto en el SDLC
1. Planificación y diseño
Aquí es donde tiene el mayor impacto con el menor esfuerzo.
- Asistir a las reuniones de planificación de funcionalidades
- Revisar los diseños técnicos en busca de implicaciones de seguridad
- Identificar qué requisitos ASVS aplican a las nuevas funcionalidades
- Señalar las funcionalidades que necesitan modelado de amenazas
- Agregar criterios de aceptación de seguridad a los tickets
Qué hace:
- "Esta funcionalidad gestiona la carga de archivos del usuario — necesitamos los requisitos V12"
- "Si vamos a almacenar tarjetas de crédito, necesitamos discutir el alcance PCI"
- "Esta API será pública, planifiquemos el rate limiting y la autenticación"
2. Desarrollo
Estar disponible sin convertirse en un cuello de botella.
- Responder preguntas de seguridad de los desarrolladores
- Revisar cambios de código sensibles en materia de seguridad
- Trabajar en pareja en implementaciones de seguridad complejas
- Mantener guías de codificación segura
- Mantener una biblioteca de patrones de código seguro
Qué hace:
- "Así es como implementar tokens CSRF en nuestro framework"
- "Revisaré el flujo de autenticación antes de que haga el merge"
- "Déjeme mostrarle cómo el código existente gestiona la validación de entrada"
3. Revisión de código
No cada PR necesita su revisión. Concéntrese en las áreas de alto riesgo.
- Autenticación y gestión de sesiones
- Autorización y control de acceso
- Validación de datos y codificación de salida
- Operaciones criptográficas
- Cambios de configuración (especialmente secretos)
- Nuevas dependencias
Qué hace:
- Agregarse como revisor obligatorio para las rutas relacionadas con la autenticación
- Crear una lista de verificación para la revisión de código relevante para la seguridad
- Revisar los PRs que afectan áreas sensibles
- Proporcionar retroalimentación que eduque, no solo que bloquee
4. Pruebas
Integrar la seguridad en los procesos de prueba existentes.
- Escribir casos de prueba de seguridad
- Configurar y mantener herramientas SAST/DAST
- Revisar los hallazgos de las herramientas y clasificar los falsos positivos
- Verificar que los requisitos de seguridad están siendo probados
Qué hace:
- "Agreguemos una prueba que verifique que los usuarios no pueden acceder a los datos de otros usuarios"
- "Configuraré Semgrep para que se ejecute en cada PR"
- "Este hallazgo SAST es un falso positivo — aquí está el porqué"
5. Despliegue
La seguridad no se detiene cuando el código se lanza.
- Revisar las configuraciones de despliegue
- Verificar las cabeceras de seguridad y TLS
- Comprobar si hay secretos expuestos o endpoints de depuración
- Monitorear errores relevantes para la seguridad
Qué hace:
- "Asegurémonos de que staging tenga la misma configuración de seguridad que producción"
- "Verificaré que la cabecera CSP esté configurada correctamente después del despliegue"
- "Estos registros de error muestran fallos de autenticación — déjeme investigar"
Trabajando con los desarrolladores
Construyendo confianza
Los desarrolladores han visto la seguridad mal gestionada. Esperan que usted bloquee su trabajo con preocupaciones teóricas. Demuéstreles que están equivocados.
Sea útil, no solo crítico:
- No diga simplemente "esto es inseguro"
- Diga "esto es vulnerable a X porque Y, así es cómo corregirlo"
- Mejor aún: "aquí hay un PR que lo corrige"
Entienda las restricciones:
- Los plazos son reales
- La deuda técnica existe
- No todo puede corregirse inmediatamente
Elija sus batallas:
- Problemas críticos: bloquear el lanzamiento
- Problemas medios: corregir en el próximo sprint
- Problemas bajos: registrar para más adelante
Comparta el porqué:
- No diga "porque OWASP lo dice"
- Diga "esto es lo que un atacante podría hacer, aquí hay un ejemplo real"
Esté disponible:
- Responda las preguntas rápidamente
- Trabaje en pareja en implementaciones de seguridad
- No haga que la gente le espere
Comunicando problemas de seguridad
Mala comunicación:
"Este código es vulnerable a inyección SQL. OWASP A03. Corríjalo."
Esto no dice nada útil a los desarrolladores. Suena a que está marcando casillas.
Buena comunicación:
"La entrada del usuario en la línea 45 va directamente a la consulta SQL. Un atacante podría introducir
'; DROP TABLE users; --y eliminar la tabla de usuarios. Así es cómo las consultas parametrizadas evitan esto. ¿Quiere que le muestre cómo nuestro ORM gestiona esto de forma segura?"
Esto explica el riesgo, muestra el impacto y ofrece ayuda.
Horas de oficina de seguridad
Establezca un tiempo regular en el que los desarrolladores puedan hacer preguntas de seguridad:
- 30-60 minutos, la misma hora cada semana
- Formato de entrada libre — sin cita previa
- Las preguntas pueden ser sobre el trabajo actual o curiosidad general
- No hay pregunta demasiado básica
Esto crea una forma sin presión de discutir la seguridad sin procesos formales de revisión.
Security Champions en cada equipo (escalando)
En organizaciones más grandes, puede entrenar a Security Champions adicionales en cada equipo:
El modelo hub-and-spoke:
┌──────────┐
│ You │
│ (Lead SC)│
└────┬─────┘
│
┌───────────┼───────────┐
│ │ │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│ SC in │ │ SC in │ │ SC in │
│ Team A│ │ Team B│ │ Team C│
└───────┘ └───────┘ └───────┘
Cada equipo tiene a alguien que:
- Gestiona las preguntas de seguridad del día a día
- Realiza revisiones de código de primer nivel
- Escala los problemas complejos a usted
- Asiste a la sincronización mensual de Security Champions
Esto escala la seguridad a través de múltiples equipos sin contratar personal de seguridad dedicado.
Trabajando con DevOps
DevOps controla el pipeline y la infraestructura. Son socios críticos.
Qué le importa a DevOps
- Fiabilidad: ¿Este cambio de seguridad romperá producción?
- Velocidad: ¿Esto ralentizará los despliegues?
- Simplicidad: ¿Es esta otra herramienta que mantener?
- Visibilidad: ¿Podemos ver lo que está pasando?
Enmarque la seguridad en estos términos.
Áreas comunes de colaboración
Escaneo de seguridad en CI/CD:
Usted quiere controles de seguridad en el pipeline. DevOps controla el pipeline.
Su enfoque:
- Empiece con escaneos no bloqueantes (solo informes)
- Demuestre que la herramienta funciona y que la tasa de falsos positivos es baja
- Luego discuta el bloqueo en hallazgos críticos
- Ofrezca clasificar los hallazgos y reducir el ruido
Conversación de ejemplo:
"Me gustaría agregar Trivy para escanear nuestras imágenes Docker. Se ejecuta en unos 30 segundos. ¿Podemos agregarlo como paso de informe primero? Revisaré los hallazgos durante unas semanas y luego decidiremos si bloquear en CVEs críticos."
Gestión de secretos:
Usted quiere sacar los secretos del código. DevOps gestiona la infraestructura.
Su enfoque:
- Entienda su manejo actual de secretos
- Proponga soluciones que se adapten a su flujo de trabajo
- Ayude con la migración
Conversación de ejemplo:
"Noté que tenemos algunas claves API en archivos de entorno. Me preocupa la rotación y el control de acceso. Ya usamos AWS — ¿qué tal si movemos estos a Secrets Manager? Puedo ayudar a actualizar el código de la aplicación para que las lea desde allí."
Seguridad de infraestructura:
Usted quiere una configuración de nube segura. DevOps la construye y mantiene.
Su enfoque:
- No audite y les descargue los hallazgos
- Ofrezca ejecutar escaneos de seguridad juntos
- Priorice los hallazgos por riesgo real
- Ayude a corregir, no solo a encontrar
Conversación de ejemplo:
"Ejecuté Prowler contra nuestra cuenta de AWS y encontré algunas cosas. La mayoría están bien, pero hay dos buckets S3 que podrían estar demasiado abiertos. ¿Podemos revisarlos juntos? Quiero asegurarme de entender el patrón de acceso previsto."
Construyendo una relación de seguridad-DevOps
Aprenda sus herramientas:
- Entienda el pipeline CI/CD
- Conozca la infraestructura (AWS/GCP/Azure)
- Aprenda Terraform/Kubernetes básico
Asista a sus reuniones:
- Revisiones de incidentes
- Planificación de infraestructura
- Evaluaciones de herramientas
Comparta información útil:
- Nuevas vulnerabilidades en las herramientas que usan
- Funcionalidades de seguridad en las plataformas que gestionan
- Incidentes de la industria relevantes para su trabajo
Sea el puente hacia el desarrollo:
- Traduzca las necesidades de los desarrolladores a requisitos de infraestructura
- Explique por qué ciertas configuraciones importan para la seguridad de las aplicaciones
Su ritmo semanal
Así es como podría verse el trabajo de desarrollo de un Security Champion:
Diariamente
- Verificar los resultados de las herramientas de seguridad (SAST, escaneos de dependencias)
- Estar disponible para preguntas rápidas
- Revisar los PRs relevantes para la seguridad
- Monitorear registros/alertas relacionados con la seguridad
Semanalmente
- Asistir a 1-2 reuniones de planificación de nuevas funcionalidades
- Horas de oficina de seguridad (30-60 min)
- Revisar las nuevas dependencias agregadas a los proyectos
- Clasificar cualquier nuevo hallazgo de seguridad
Mensualmente
- Revisar la cobertura de requisitos de seguridad
- Actualizar las guías de codificación segura
- Sincronización de seguridad con DevOps
- Sesión de formación o almuerzo de aprendizaje
Trimestralmente
- Revisión completa de la línea base de requisitos de seguridad
- Actualizar los modelos de amenazas para las funcionalidades principales
- Revisar y actualizar las herramientas de seguridad
- Informar las métricas de seguridad al liderazgo
Herramientas que usará
Herramientas de seguridad para el desarrollo
| Herramienta | Propósito | Cuándo |
|---|---|---|
| Semgrep | SAST (análisis estático) | Cada PR |
| Snyk | Escaneo de dependencias | Cada build |
| Gitleaks | Detección de secretos | Cada commit |
| Trivy | Escaneo de contenedores | Cada build de imagen |
| OWASP ZAP | DAST (pruebas dinámicas) | Despliegues en staging |
| Checkov | Escaneo de IaC | Cada cambio de Terraform |
Comunicación y seguimiento
| Herramienta | Propósito |
|---|---|
| Slack/Teams channels | Preguntas rápidas, alertas |
| Jira/Linear | Seguimiento de requisitos de seguridad |
| Confluence/Notion | Guías de seguridad, runbooks |
| GitHub/GitLab | Revisión de código, comentarios en PR |
Su panel de seguridad
Configure visibilidad del estado de seguridad:
## Security Champion Dashboard
### This week
- [ ] PRs reviewed: X
- [ ] Security questions answered: X
- [ ] Planning meetings attended: X
- [ ] Tool findings triaged: X
### Metrics
- Open critical security issues: X
- Average time to resolve critical: X days
- SAST findings this month: X (Y false positives)
- Dependencies with known vulns: X
### Upcoming
- Feature X design review: [Date]
- Security office hours: [Day/Time]
- DevOps security sync: [Date]
Desafíos comunes
"No tenemos tiempo para la seguridad"
Esto ocurre cuando la seguridad se percibe como trabajo extra.
Su respuesta:
- Mueva la seguridad más temprano para que no sea trabajo de último minuto
- Automatice lo que pueda (SAST, escaneos de dependencias)
- Concéntrese en victorias de alto impacto y bajo esfuerzo
- Muestre cómo los problemas de seguridad encontrados tarde cuestan más tiempo
"Nos está ralentizando"
Esto ocurre cuando la seguridad bloquea los lanzamientos.
Su respuesta:
- Haga que los hallazgos no críticos no sean bloqueantes
- Sea rápido en sus revisiones
- Proporcione sugerencias de corrección, no solo hallazgos
- Reserve el bloqueo para problemas verdaderamente críticos
"Eso no es un riesgo real"
Esto ocurre cuando los desarrolladores descartan los hallazgos.
Su respuesta:
- Muestre ejemplos del mundo real de explotación
- Explique la metodología del atacante
- Demuestre la vulnerabilidad si es posible
- Acepte que a veces será superado — documente y continúe
"Ya tenemos un equipo de seguridad"
Esto ocurre en empresas con personal de seguridad dedicado.
Su respuesta:
- Usted amplía su alcance, no los reemplaza
- Usted gestiona el día a día, ellos el trabajo especializado
- Usted es el traductor entre seguridad y desarrollo
- Ellos pueden centrarse en respuesta a incidentes, pentests, arquitectura
Midiendo su impacto
Haga seguimiento de estos para mostrar valor:
Métricas de proceso:
- Cobertura de requisitos de seguridad para nuevas funcionalidades
- Tiempo desde el hallazgo de seguridad hasta la corrección
- Porcentaje de PRs con revisión de seguridad
- Participación de desarrolladores en la formación de seguridad
Métricas de resultado:
- Vulnerabilidades encontradas en desarrollo vs. producción
- Incidentes de producción relacionados con la seguridad
- Hallazgos de pentests externos (menos es mejor)
- Tiempo de respuesta a cuestionarios de seguridad de clientes
Métricas de participación:
- Preguntas hechas en las horas de oficina de seguridad
- Desarrolladores que voluntariamente agregan pruebas de seguridad
- Seguridad discutida en reuniones de planificación sin su presencia
Autocomprobación
Antes de adentrarse en las prácticas de codificación segura, verifique que entiende su rol:
Integración en el equipo
- Asiste a las reuniones de planificación de funcionalidades
- Los desarrolladores saben incluirle en los PRs sensibles a la seguridad
- Tiene acceso al código base y al CI/CD
- DevOps le conoce a usted y a su rol
Comunicación
- Horas de oficina de seguridad programadas
- Canal de Slack/Teams para preguntas de seguridad
- Se ha presentado al equipo de desarrollo
- Tiene sincronización regular con DevOps
Herramientas
- Tiene acceso para ejecutar escaneos de seguridad
- Puede ver los resultados del pipeline CI/CD
- Tiene acceso a los registros relevantes para la seguridad
- Panel o seguimiento para las métricas de seguridad
Proceso
- Los requisitos de seguridad están registrados en algún lugar
- El proceso de revisión de PR incluye rutas sensibles a la seguridad
- Las nuevas funcionalidades reciben aportación de seguridad durante la planificación
- Los hallazgos de seguridad tienen un flujo de trabajo de corrección claro
Marque al menos 10 de estos 12 elementos antes de pasar a los fundamentos de codificación segura.
Qué sigue
Entiende su rol en desarrollo y DevOps. Los próximos capítulos cubren las habilidades técnicas que necesita:
- Fundamentos de codificación segura — las vulnerabilidades que buscará y cómo prevenirlas
- Gestión de requisitos de seguridad — cómo definir y hacer seguimiento de los requisitos de seguridad
- Gestión de secretos — mantener las credenciales fuera del código
- Seguridad en CI/CD — integrar la seguridad en el pipeline
- Seguridad de contenedores y nube — asegurar la infraestructura
Empecemos por el código en sí.