Si has descubierto una vulnerabilidad y quieres enviarla a la empresa para que la validen y solucionen, debes escribir un reporte.
Típicamente los reportes serán revisados primero por el equipo de triaje de Secur0 y después por el equipo técnico de la empresa.
Si tu reporte es a un programa con la etiqueta “CVE” entonces el reporte también será revisado una tercera vez, en concreto por el equipo de triaje de Secur0 en función de CNA. Para más información sobre esto puedes consultar nuestro faq sobre CVEs.
Para redactar un reporte correctamente debes tener en cuenta 5 cuestiones:
- Qué categoría de fallo quieres describir
- Dónde se ha producido el fallo
- Cómo se ha producido el fallo
- Qué impacto se ha demostrado
- Qué impacto no se ha demostrado pero es posible que exista Si tu reporte responde correctamente a todas estas cuestiones tu experiencia en el proceso de triaje será sencilla y rápida.
A continuación veremos una por una cómo redactar estas categorías:
Qué categoría de fallo se quiere describir
Los informes deben tener siempre un informe ejecutivo y técnico que describan a grandes rasgos la vulnerabilidad por tipo taxonómico (por ejemplo XSS reflejado, IDOR…) y bajo qué condiciones ha ocurrido. No es necesario explayarse excesivamente.
Dónde se ha producido el fallo
Todos los formularios de reporte de Secur0 te preguntarán por un endpoint y dominio. Debes añadirlos para que el equipo de triaje pueda validar la vulnerabilidad rápidamente.
Cómo se ha producido el fallo
Todos los reportes deben contener una prueba de concepto. Las pruebas de concepto tienen un formato relativamente estricto: deben ser una lista de pasos simples numerados. No te preocupes por qué constituye un paso o dos, simplemente no entregues un párrafo narrativo en lugar de prueba de concepto.
Adicionalmente contamos con un campo de payload que te permite comunicar en texto plano payloads exactas, scripts de PoC o peticiones HTTP.
Qué impacto se ha demostrado
Necesitamos conocer el impacto tanto de forma textual como en un formato estándar. En Secur0 empleamos el CVSS 4.0; rellenarlo en los informes es opcional pero muy recomendable.
Adicionalmente publicamos (y permitimos disputar públicamente) nuestra interpretación del estándar, con lo que podrás consultar casos pasados y saber qué criticidad le asignaremos a un fallo en rasgos generales.
Puedes leer este registro en nuestra página de Docs de EGAD!
Qué impacto es posible que exista
En Secur0 calcularemos la criticidad únicamente mediante el impacto demostrado o inmediatamente obvio escalable (por ejemplo compromiso de Wordpress admin -> RCE en la mayoría de los casos).
Sin embargo es importante que describas el impacto potencial, ya que así la empresa podrá conocer correctamente su situación y, en caso de riesgo extremo, podrá comunicar al equipo de triaje que suba la criticidad.
Cómo no actuar en un reporte
Existe una serie de conductas que no son recomendables, ya sea porque degradan el funcionamiento de todos o porque impiden la realización de tareas de triaje y corrección correctamente. Todas estas situaciones pueden ser reprendidas en el caso adecuado.
Normas fijas
Se encuentran publicadas aquí.
Contactar a la empresa por vías externas
Todas las organizaciones han confirmado un acuerdo de VDP o BBP con Secur0. En el caso de desarrolladores de FOSS es posible que no respondan con rapidez. Eso jamás será una excusa para tratar de comunicarse con empresas y organizaciones o presionarlas por vías externas.
Pings excesivos en reportes
Todas las partes tratamos de trabajar lo más rápido posible, y entendemos que los investigadores quieran su reconocimiento con velocidad. Es por esto que aceptamos pings o tickets de Discord solicitando actualizaciones, pero se debe respetar el tiempo de dos semanas o 14 días laborales entre solicitudes de actualización.
Incumplimiento de cualquier norma de convivencia
Acoso, doxxeo, ataques por identidad personal, etc., entre cualquier parte está terminantemente prohibido y será respondido con baneos integrales de la plataforma de Secur0.
Recomendación
Uso de IA Slop
Entendemos que generar argumentos con LLMs es tentador cuando un encargado de triaje da menos puntuación de CVSS 4.0 de lo que esperábamos, pero se debe tener en cuenta la naturaleza aduladora de las LLMs, que siempre tratarán de dar la razón a la parte que interactúa con ellas.
Aunque os invitamos a debatir con el triaje si creéis que la puntuación es incorrecta, os solicitamos que confiéis en nuestra experiencia en seguridad de aplicaciones y gestión de vulnerabilidades.
Aunque no entraremos en argumentos metacognitivos como si “realmente no se puede detectar la escritura con LLM”, el equipo de triaje se reserva su capacidad para cesar de responder a debates técnicos si los argumentos se han vuelto cíclicos, excesivos en densidad y/o nulos de validez técnica.
Descriptores excesivos (estilo “Claudish”)
Entendemos que la descripción de vulnerabilidades en entornos de análisis de código es compleja, y que muchos de los investigadores trabajan o bien asistidos por LLMs o empleándolos como agentes autónomos.
Se debe tener en cuenta que el proceso de triaje incluye una lectura humana del reporte, y aunque contamos con herramientas LLM, no aceptamos jamás un reporte únicamente por su inferencia.
Reportes que contienen trazas con código verbose excesivo en párrafos de texto narrativos son claros ejemplos de descripciones de estilo “Claudish”.
Aunque las trazas son necesarias para el triaje, os solicitamos que se mantengan únicamente en los campos de prueba de concepto y/o payload.