Cuando un incidente de seguridad ocurre en producción, cada minuto cuenta. Sin un runbook claro, tu equipo pierde tiempo decidiendo qué hacer, quién lo hace y cómo documentarlo. En este artículo te comparto cómo construir un runbook DevSecOps que realmente funcione para tu equipo, basado en lo que hemos visto funcionar en proyectos reales.
¿Qué es un runbook DevSecOps y por qué lo necesitas?
Un runbook es un conjunto de procedimientos documentados que cubre desde la respuesta a incidentes hasta tareas rutinarias de seguridad. Para un equipo DevSecOps, el runbook debe integrar controles de seguridad en cada etapa del pipeline CI/CD: escaneo de vulnerabilidades, revisión de dependencias, hardening de imágenes, y respuesta a alertas.
Sin un runbook, la probabilidad de errores humanos aumenta, los tiempos de respuesta se alargan y el conocimiento se queda en la cabeza de una sola persona. Con un runbook bien diseñado, cualquier miembro del equipo puede ejecutar las tareas críticas de forma consistente.
Elementos esenciales de un runbook DevSecOps
- Inventario de activos y responsables: Lista de servicios, repositorios, claves de API, y quién es el dueño de cada uno.
- Procedimientos de respuesta a incidentes: Pasos concretos para cada tipo de alerta (ejemplo: dependencia con CVE crítica, fuga de secretos, ataque DDoS).
- Checklist de verificación de seguridad: Lista de comprobaciones que se ejecutan antes de un despliegue a producción.
- Guías de escalamiento: Cuándo y cómo contactar al equipo de seguridad o al CISO.
- Referencias a herramientas: Enlaces directos a dashboards de monitoreo, logs, y scripts de automatización.
Checklist de verificación de seguridad (prueba concreta)
Aquí tienes un checklist que puedes adaptar a tu pipeline. Cada elemento debe estar automatizado o documentado en tu runbook:
- Análisis SAST ejecutado sin fallos críticos.
- Análisis SCA de dependencias sin vulnerabilidades conocidas.
- Escaneo de secretos en el código (no hay tokens ni contraseñas en texto plano).
- Imagen Docker escaneada con herramienta de vulnerabilidades (Trivy, Clair, etc.).
- Pruebas de penetración automatizadas (DAST) en entorno staging.
- Revisión manual de cambios de alto riesgo (code review con checklist de seguridad).
- Logs de auditoría habilitados y centralizados.
- Backups verificados de bases de datos y configuraciones.
- Prueba de restauración de backups ejecutada en los últimos 30 días.
- Políticas de red aplicadas (firewall, WAF, segmentación).
Este checklist debe estar versionado en tu repositorio de runbooks y revisarse al menos cada trimestre.
Cómo mantener tu runbook vivo
Un runbook no es un documento estático. Recomiendo:
- Alojarlo en un wiki o repositorio Git (Markdown) para que sea fácil de actualizar.
- Asignar un responsable de revisión mensual.
- Incluir enlaces a dashboards y scripts para que la ejecución sea rápida.
- Realizar simulacros de incidentes (tabletop exercises) para probar los procedimientos.
Para profundizar en la integración de seguridad en tus pipelines, visita nuestro hub de DevSecOps y entrega segura. Si necesitas ayuda para diseñar o implementar estos procesos, nuestro equipo de servicios DevOps puede acompañarte.
Preguntas frecuentes
¿Con qué frecuencia debo actualizar el runbook? Recomiendo una revisión trimestral y una actualización inmediata cada vez que cambie una herramienta, un proceso o se descubra una nueva amenaza relevante.
¿El runbook debe ser público o privado? Depende de tu política de seguridad. Generalmente, los procedimientos operativos son internos, pero puedes publicar versiones anonimizadas para compartir buenas prácticas con la comunidad.
¿Qué herramientas usar para documentar el runbook? GitHub Wiki, Confluence, Notion o incluso un repositorio con archivos Markdown. Lo importante es que sea accesible, versionado y fácil de actualizar.