Triage de vulnerabilidades en equipos AppSec: cómo estructurar el proceso
Por Kike Gandia · Co-Fundador y CEO, OSCP
Los equipos AppSec son el cuello de botella más común en la gestión de vulnerabilidades. Reciben reportes de múltiples fuentes — escáneres automáticos, pentesters, bug bounty, investigadores externos, SAST/DAST — y tienen que decidir qué parchear primero con recursos limitados. Un proceso de triage bien diseñado transforma ese caos en un flujo de trabajo predecible.
Por qué el triage es el proceso más crítico de AppSec
Sin triage, el backlog crece más rápido de lo que el equipo puede remediar. Las cuatro fuentes de ruido principales son: falsos positivos de escáneres SAST/DAST, duplicados de múltiples herramientas, reportes sin contexto de explotabilidad, y vulnerabilidades en dependencias que no afectan a tu configuración. Los equipos con triage estructurado reducen el MTTR entre un 40% y un 60% — no porque parchearan más rápido, sino porque el equipo de desarrollo trabaja sobre vulnerabilidades bien contextualizadas.
Las cinco fases del proceso de triage AppSec
Un proceso de triage maduro tiene cinco fases:
1. Ingesta y deduplicación: recepción centralizada de todas las fuentes, deduplicación y asignación de identificador único.
2. Validación técnica: reproducción en entorno controlado, confirmación de que el hallazgo es real.
3. Evaluación de severidad y contexto: CVSS 4.0 ajustado a tu exposición real + EPSS.
4. Priorización y asignación: SLAs por severidad, tickets de remediación con contexto completo.
5. Seguimiento y cierre: verificación del parche, documentación y comunicación al reportador.
Herramientas para automatizar el triage AppSec
Herramientas como Defect Dojo, Nucleus Security, PlexTrac o Vulcan Cyber centralizan los hallazgos de múltiples fuentes y automatizan la deduplicación. La integración con Jira, GitHub Issues o Azure DevOps asegura que los tickets de vulnerabilidades siguen el mismo flujo de trabajo que el resto del desarrollo. Ninguna herramienta reemplaza el criterio técnico humano, pero sí automatizan las partes mecánicas.
Cuándo externalizar el triage
El triage externo tiene sentido si: el equipo AppSec tiene menos de 3 personas, gestionáis más de 50 nuevas vulnerabilidades al mes, el MTTR supera los 60 días para vulnerabilidades altas, o la ratio de falsos positivos supera el 30% de los reportes que llegan al equipo de desarrollo.
FAQ
¿Cuánto tiempo debería dedicar un equipo AppSec al triage cada semana?
Depende del volumen de reportes. Como referencia, un equipo de 3 personas gestionando 100 reportes al mes debería dedicar entre 20-30% de su tiempo al triage si el proceso es eficiente. Sin proceso estructurado, ese porcentaje puede subir al 50-60%, dejando poco tiempo para trabajo proactivo de seguridad.
¿SAST y DAST reemplazan el triage manual?
No. SAST y DAST son herramientas de detección, no de triage. Generan listas de posibles vulnerabilidades (con muchos falsos positivos) pero no pueden evaluar el contexto de negocio, la explotabilidad real en tu configuración específica ni la prioridad relativa entre hallazgos. El triage manual es necesario para convertir el output de los escáneres en acciones priorizadas.
¿Cómo medimos si nuestro proceso de triage AppSec es eficiente?
Métricas clave: ratio de falsos positivos que llegan al equipo de desarrollo (objetivo <10%), tiempo desde detección hasta asignación de ticket (objetivo <48h para críticos), MTTR por severidad, porcentaje de vulnerabilidades dentro de SLA. Si no mides estas métricas, no puedes mejorar el proceso.
Servicio relacionado
servicio de triage de vulnerabilidades
Contenido relacionado
- Proceso de triage de vulnerabilidades paso a paso
- Cómo priorizar el backlog de vulnerabilidades
- Servicio de triage de vulnerabilidades
Fuentes
- OWASP Top 10 — los riesgos más críticos en aplicaciones web
- OWASP Web Security Testing Guide (WSTG) — metodología oficial de referencia
Auditamos y optimizamos el proceso de triage de vulnerabilidades de tu equipo