Las denuncias de vulnerabilidades ya no son especiales
Los reportes de vulnerabilidades de seguridad están siendo inundados por envíos generados por IA y de baja calidad, saturando a quienes mantienen y a las empresas que antes trataban esos reportes como eventos raros y de alta señal. Los participantes describen programas de bug bounty y divulgación ahogados por spam, CVEs triviales y afirmaciones cercanas a la extorsión, lo que dificulta detectar y priorizar fallos realmente explotables y erosiona los incentivos para la divulgación responsable. Muchos ven esto como una fuerza que empuja hacia una mejor clasificación inicial (a menudo usando la propia IA), relaciones de confianza más fuertes con investigadores probados y un renovado enfoque en prácticas de ingeniería que previenen clases enteras de bugs en lugar de reaccionar a alertas interminables.
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.