Las denuncias de vulnerabilidades ya no son especiales

Escala y naturaleza del spam de reportes de vulnerabilidades

• Muchas empresas ahora reciben múltiples reportes no solicitados por semana/día, a menudo claramente generados por IA, de baja calidad o cercanos a la extorsión.
• Patrones comunes: problemas triviales de CSS/UI, hallazgos “críticos” mal clasificados, o reportar el comportamiento previsto como si fueran vulnerabilidades.
• Quienes mantienen y los equipos de seguridad informan agotamiento y consideran cerrar o endurecer los programas (por ejemplo, prohibir reportes escritos por IA, exigir PoC en video, añadir tokens ocultos estilo “turtle123”).

Bug Bounties, incentivos y riesgo legal

• Sugerencias para disuadir el spam: pequeñas tarifas por reporte (posiblemente no reembolsables), micro-muros de pago para formularios de contacto o reglas estrictas.
• Preocupaciones: incentivos desalineados (las empresas pueden rechazar bugs válidos para no pagar), complejidad contable/legal al conservar tarifas, y efectos disuasorios porque los pagos pueden desanonimizar a los investigadores y aumentar la percepción de riesgo de arresto.
• Algunos investigadores cuentan que fueron ignorados o mal recompensados incluso por problemas no triviales de tipo DoS/RCE.

Fatiga de CVE e infierno de dependencias

• Muchos se quejan de la sobrecarga de CVE, especialmente de calificaciones de alta gravedad para problemas de bajo impacto (por ejemplo, ReDoS en herramientas de build/dev, formatos de archivo oscuros).
• Dependabot y los escáneres generan grandes volúmenes de alertas, incluso para dependencias de desarrollo; los equipos luchan por separar el riesgo real del ruido.
• Contraargumento: las dependencias de desarrollo y build son vectores de ataque reales (por ejemplo, cadena de suministro, exfiltración desde sistemas de desarrollo/CI), especialmente en sectores regulados.
• Patrones resultantes: algunos fusionan automáticamente todas las actualizaciones; otros las agrupan o intentan minimizar los grafos de dependencias.

LLMs en seguridad: capacidad y limitaciones

• Consenso: los LLMs reducen enormemente el costo de encontrar muchos bugs superficiales o basados en patrones y también generan grandes volúmenes de reportes falsos o exagerados.
• Algunos ven a los LLMs como iguales o casi iguales a investigadores promedio de bajo esfuerzo para ciertas clases de bugs; otros consideran esa afirmación exagerada e insultante.
• Varias organizaciones ahora usan LLMs para clasificar reportes entrantes, categorizar la gravedad o filtrar spam; otras proponen herramientas agentivas para auditar automáticamente e incluso parchear código.
• Los escépticos subrayan una inteligencia “dentada”: los modelos pueden pasar por alto bugs difíciles, alucinar problemas y aún no pueden ofrecer un análisis fiable de impacto de última milla.

¿Siguen siendo especiales los reportes de vulnerabilidades?

• Un lado: las vulnerabilidades siguen siendo fundamentalmente distintas de los bugs ordinarios; la confidencialidad y la coordinación son aún más importantes ahora que los parches son más fáciles de convertir en armas.
• El otro lado: la correlación entre “reporte de seguridad” y “vulnerabilidad real e impactante” se ha derrumbado, haciendo que los reportes se sientan como simples tickets de bugs ruidosos.
• Muchos argumentan que el recurso escaso ya no es encontrar bugs, sino hacer una clasificación fiable y demostrar impacto en el mundo real.

Práctica de seguridad, métodos formales y cultura

• Algunos abogan por pasar a lenguajes seguros en memoria, métodos formales y un razonamiento más fuerte a nivel de especificación; otros señalan que la indecidibilidad y el alto costo limitan la verificación completa.
• Existe tensión entre “seguridad perfecta o fracaso” frente a la gestión pragmática del riesgo y la defensa en profundidad.
• Varios enfatizan el papel de las relaciones de confianza con investigadores conocidos, mejores incentivos y una interacción más profesional y menos adversarial entre seguridad e ingeniería.

Perspectiva futura (incierta y disputada)

• Una visión: la actual “vulnpocalypse” es temporal; los LLMs consumirán los bugs fáciles y luego se integrarán antes del lanzamiento, reduciendo los reportes externos.
• Contrapunto: los LLMs también amplificarán la creación de código inseguro, y muchas organizaciones nunca adoptarán un escaneo robusto previo al lanzamiento, por lo que el volumen y el ruido seguirán siendo altos.
• Algunos predicen que los programas públicos de recompensas se reducirá o cerrarán debido al slop, empujando el trabajo de seguridad hacia redes de confianza y programas internos o curados.