El dato que pocos conocen

La mayoría de los equipos de seguridad de aplicaciones conocen el OWASP Top 10, la lista estándar de los riesgos de seguridad de software más críticos. Pero pocos saben cuáles de esas categorías realmente corrigen. En conversaciones con equipos de seguridad, escucho la misma historia: "Priorizamos los críticos, así que lo importante se maneja". Los datos cuentan una historia diferente. Las tasas de corrección varían drásticamente según la clase de vulnerabilidad OWASP, y no de la manera que la mayoría espera.

Los datos provienen del informe de Semgrep "Remediation at Scale", que analizó patrones de corrección anonimizados en más de 50,000 repositorios y cientos de organizaciones durante 2025. La metodología es simple: se agrupan las organizaciones en dos cohortes según la tasa de corrección (el 15% superior como "líderes", el 85% restante como "campo") y se compara lo que cada grupo hace de manera diferente.

La brecha entre líderes y el campo no se debe a la calidad de la detección o a los marcos de priorización. Ambas cohortes aplican los mismos filtros de severidad y detectan los mismos hallazgos críticos. Lo que difiere es la ejecución. Una organización corrige el 63% de sus hallazgos críticos. Otra corrige el 13%. Mismas herramientas. Mismas alertas. Diferentes enfoques.

Las brechas de tasa de corrección que nadie menciona

Al desglosar las tasas de corrección de SAST (pruebas de seguridad de aplicaciones estáticas) por categoría OWASP, las mayores brechas entre equipos de alto rendimiento y el resto no se encuentran en las categorías que uno esperaría.

Las fallas de autenticación (A07) muestran la mayor brecha en el conjunto de datos: una diferencia de 48 puntos porcentuales entre líderes y el campo. Los líderes corrigen casi el 60%, mientras que el campo se sitúa en aproximadamente el 12%. Las fallas criptográficas (A02) les siguen con una brecha de 38 puntos.

Estas dos categorías comparten una característica que puede no ser evidente solo con la etiqueta OWASP: corregirlas requiere comprensión arquitectónica, no solo reemplazo de patrones.

Considere cómo es una corrección de autenticación. Por lo general, no se trata de agregar una verificación en la "línea 47". Se trata de rastrear la gestión de sesiones a través del middleware, comprender el ciclo de vida de los tokens, auditar la aplicación de la autenticación multifactor y determinar cómo funciona el almacenamiento de credenciales en todas las capas del servicio. Una corrección criptográfica puede implicar migrar de un algoritmo obsoleto a uno moderno en todos los sistemas que leen los datos cifrados. Por lo general, son proyectos complejos, no tareas rápidas.

SSRF (A10) es una de las únicas categorías donde el campo supera a los líderes, mostrando una brecha ligeramente negativa. Las correcciones de SSRF resisten patrones simples porque las listas blancas pueden ser eludidas mediante rebote de DNS, codificación de IP y endpoints de metadatos en la nube. Ambas cohortes las abordan con un esfuerzo especializado similar, aplanando la brecha observada en otras categorías.

Inyección (A03) se sitúa en el medio con una brecha de 23 puntos. La corrección en sí (consultas parametrizadas en lugar de concatenación de cadenas) es conceptualmente simple. El desafío es encontrar todos los puntos de inyección en una base de código grande, especialmente cuando la entrada no confiable fluye a través de múltiples archivos antes de llegar a un sumidero peligroso. Los desgloses más detallados del informe reflejan esto: cuando un escáner confirma un hallazgo rastreando el flujo de datos a través de archivos (análisis entre archivos), los líderes corrigen esos hallazgos en un 69% frente al 43% para hallazgos en un solo archivo. Esto significa que cuando los equipos ven la ruta completa desde la entrada del usuario hasta el sumidero peligroso, tienden a tratarlo como trabajo real, mientras que los hallazgos sin evidencia clara de flujo de datos se postergan.

El precipicio de los 90 días: cuando las vulnerabilidades se vuelven permanentes

Los datos también revelan algo que, especialmente para quienes gestionan grandes acumulaciones de trabajo, debería replantear cómo se piensa sobre los hallazgos de seguridad de código antiguos.

Los hallazgos abiertos durante más de 90 días se vuelven poco probables de ser corregidos. Entre los equipos de alto rendimiento, solo el 9% de las correcciones de SAST provienen de la acumulación de más de 90 días. Para el campo, es el 16%.

Anécdoticamente, muchos equipos mantienen un ojo en estos hallazgos trimestre tras trimestre, esperando un buen momento para abordarlos, y ese momento nunca llega. Si una vulnerabilidad ha estado en su acumulación durante tres meses, la trayectoria predeterminada es que se quede allí. Trate los 90 días como un punto de escalada, no un plazo sino una función de presión. En ese punto, cada hallazgo abierto necesita una de tres disposiciones: corregirlo con tiempo dedicado, aceptar formalmente el riesgo con justificación documentada, o silenciarlo como un falso positivo confirmado. Dejar los hallazgos indefinidamente sin una decisión no es gestión de riesgos.

Qué hacen diferente los equipos de alto rendimiento

Los patrones que separan a los líderes del campo generalmente implican algún tipo de configuración de flujo de trabajo, no solo selección de herramientas.

Si desglosamos las vulnerabilidades de código en vulnerabilidades de código propio (SAST) y vulnerabilidades introducidas por paquetes y dependencias (SCA), podemos ver varios hallazgos interesantes.

El escaneo a nivel de PR acelera la corrección en 9 veces, pero solo si el flujo de trabajo lo respalda. El 96% de los líderes y el 95% de las organizaciones del campo ya ejecutan escaneos SAST y SCA en pull requests (las revisiones de código que los desarrolladores abren antes de fusionar cambios). La adopción de escaneo de PR no es el diferenciador. Lo que difiere es si los hallazgos son procesables en el momento del PR. Los líderes resuelven los hallazgos de SAST detectados en PR en un promedio de 4.8 días; la misma clase de hallazgo de un escaneo completo toma 43 días. Entre las organizaciones líderes, el 63% de las correcciones detectadas en PR se realizan el mismo día. Esto tiene sentido cuando se piensa en la experiencia del desarrollador: ya están en el código, el contexto está fresco y la corrección se envía en el mismo PR sin necesidad de ticket o reasignación.

Las reglas de bloqueo generan el mayor aumento en la tasa de corrección del conjunto de datos. Las organizaciones que configuran reglas específicas de alta confianza para bloquear fusiones de PR ven resultados medibles: los líderes ganan una mejora de 12 puntos porcentuales en la tasa de corrección de SAST y SCA; el campo gana 5 puntos. ¿Por qué tal disparidad? La diferencia es que los líderes han construido el flujo de trabajo posterior para respaldar una fusión bloqueada: el desarrollador sabe qué corregir, la ruta de corrección no es ambigua y el bloqueo no se trata como ruido para anular. Restringen el bloqueo a reglas donde eso sea cierto (secretos codificados, inyección SQL mediante concatenación de cadenas, falta de autenticación en endpoints sensibles) y evitan bloquear reglas con altas tasas de falsos positivos.

El análisis de alcanzabilidad transforma la priorización de SCA. El conjunto de datos no solo incluye hallazgos de SAST, sino también hallazgos relacionados con paquetes de terceros gracias a Semgrep Supply Chain. Para vulnerabilidades de dependencias, saber que un paquete contiene un exploit versus saber si su base de código realmente llama a la función vulnerable dentro del paquete cambia el comportamiento. Los líderes corrigen hallazgos de SCA alcanzables en un 92% frente al 67% de los no alcanzables. Esta señal reduce la fatiga de alertas de dependencias al separar lo que está técnicamente presente de lo que realmente es explotable.

Por dónde empezar

Si está tratando de comparar su propio programa, el informe ofrece un diagnóstico simple: mire su tasa de corrección de SAST crítico. Si está por debajo del 50%, probablemente el problema no sea la calidad de la detección. Algo entre la detección y la corrección está roto. En mi experiencia, suele ser una de tres cosas: los hallazgos no llegan a los desarrolladores con suficiente contexto, no hay un propietario claro para cada hallazgo, o no hay una ruta de escalada para problemas antiguos.

El informe completo "Remediation at Scale" de Semgrep incluye análisis de tasas de corrección por CWE (Common Weakness Enumeration, una clasificación más detallada que OWASP), datos específicos de ecosistemas para varios gestores de paquetes y un conjunto priorizado de recomendaciones organizadas por cronograma de implementación.

Sobre el autor: Braden Riggs aporta una mirada de científico de datos al marketing de productos. Como Technical Product Marketing Manager en Semgrep, opera en la intersección de la IA, la seguridad y las herramientas que los desarrolladores realmente usan.