Proceso de triage de vulnerabilidades: cómo analizamos cada reporte de seguridad

Por Kike Gandia · Co-Fundador y CEO, OSCP · Última actualización: septiembre de 2026

El triage de vulnerabilidades no es un proceso de lectura rápida. Cada reporte pasa por una serie de pasos técnicos que permiten confirmar que la vulnerabilidad es real, evaluar su impacto y entregar la información necesaria para que el equipo de remediación pueda actuar sin investigación adicional. Transparencia sobre cómo trabajamos.

Paso 1: Recepción y clasificación inicial

Cuando llega un reporte, lo primero es una lectura técnica completa. En esta fase determinamos:

¿Está dentro del scope definido? Si está fuera, la respuesta al investigador es inmediata con explicación detallada.
¿Es un duplicado? Cruzamos con el histórico de reportes activos y cerrados del programa.
¿Qué tipo de vulnerabilidad describe? IDOR, XSS, SQLi, lógica de negocio, exposición de información, autenticación…
¿Cuál es el nivel de detalle del reporte? ¿Incluye PoC, pasos reproducibles, capturas?

Esta clasificación inicial nos permite priorizar: los reportes que parecen críticos o altos van primero.

Paso 2: Reproducción técnica del ataque

La reproducción es el núcleo del triage. Intentamos replicar el ataque descrito por el investigador:

Seguimos los pasos del investigador tal cual los describe.
Si los pasos son ambiguos, pedimos aclaraciones antes de asumir que no es reproducible.
Si el ataque requiere condiciones específicas (usuario autenticado, datos previos), las creamos en el entorno de pruebas.

Si la vulnerabilidad no es reproducible con los pasos proporcionados, no rechazamos de inmediato: solicitamos más información y damos un plazo al investigador para responder. Solo cerramos como "no reproducible" si después de un intercambio razonado seguimos sin poder verificar el hallazgo.

Paso 3: Análisis de impacto contextualizado

Reproducir el ataque confirma que el fallo existe, pero no determina su impacto real. En este paso evaluamos:

¿Qué puede hacer un atacante que explote esta vulnerabilidad? ¿Acceder a datos de otros usuarios? ¿Modificar registros? ¿Escalar privilegios?
¿El sistema afectado procesa datos sensibles (personales, financieros, de salud)?
¿Hay compensating controls (WAF, rate limiting, monitorización) que reducen el riesgo real?
¿Qué tan difícil es explotar esto de forma masiva vs. de forma individual?

Esta evaluación de impacto contextualizado puede cambiar significativamente la puntuación final respecto al CVSS base.

Paso 4: Scoring y entrega al equipo de remediación

Con la reproducción confirmada y el impacto evaluado, calculamos el CVSS 4.0 (base y ambiental si tenemos suficiente contexto del entorno) y consultamos el EPSS para la CVE si aplica.

La entrega al equipo de remediación incluye:
• Descripción clara del hallazgo en términos técnicos.
• PoC documentada: pasos exactos para reproducir el ataque.
• CVSS 4.0 calculado con justificación de cada métrica.
• EPSS y contexto de explotación activa en la naturaleza.
• Recomendación de remediación específica para el stack tecnológico del cliente.
• Priorización respecto al backlog activo: qué debe parchearse antes.

FAQ

¿Cuánto tiempo lleva triagar un reporte de media?

Depende de la complejidad. Un reporte bien documentado de XSS o IDOR puede triarse en 1-2 horas. Un reporte de lógica de negocio compleja, una cadena de vulnerabilidades o un hallazgo en infraestructura puede requerir 4-8 horas. La reproducción es la fase más variable en tiempo.

¿Qué herramientas usáis para triagar?

Las mismas que usamos para pentesting: Burp Suite Pro para análisis web, herramientas de análisis de APIs, entornos de sandbox para pruebas controladas, y acceso a plataformas de threat intelligence para consultar EPSS y contexto de explotación activa. El triage no es solo leer: implica atacar.

¿Podéis triagar reportes de todos los tipos de vulnerabilidad?

Sí. Nuestro equipo tiene experiencia en vulnerabilidades web (OWASP Top 10 y más allá), APIs, aplicaciones móviles, infraestructura, cloud, Active Directory y lógica de negocio. Para tipos de vulnerabilidad muy especializados (hardware, firmware, OT/ICS), lo evaluamos caso a caso.