La remediación de vulnerabilidades es el trabajo de corregir la causa de una falla de seguridad para que ya no pueda ser explotada, y después demostrar que la corrección funcionó. Es una de las tres opciones de tratamiento, junto a la mitigación y la aceptación, y la única que elimina la debilidad en lugar de administrarla.
La segunda mitad de esa definición es donde se rompen los programas. En el Reporte de ataques 2026 de Fluid Attacks, la tasa de remediación de los sistemas evaluados cerró 2025 en 62,2 %, y los sistemas cuyos desarrolladores usaron los plugins de IDE de Fluid Attacks alcanzaron una tasa media de remediación de 55,4 %, frente al 28,1 % de los sistemas que no los usaron. Dónde se escribe un arreglo cambia si llega a escribirse.
Esta página cubre qué es y qué no es la remediación de vulnerabilidades, en qué se diferencia de la mitigación y la aceptación, cómo se construyen los arreglos para el código, las vulnerabilidades en dependencias y la infraestructura, cómo verificar que una falla desapareció de verdad, qué hacer cuando no hay parche y qué métricas muestran si el proceso de remediación de vulnerabilidades funciona.
¿Qué es la remediación de vulnerabilidades?
La remediación de vulnerabilidades es la corrección de una debilidad de seguridad en su origen, confirmada con una nueva prueba. Abarca tres tipos de cambio: arreglar tu propio código fuente, actualizar o reemplazar un componente de terceros vulnerable y corregir una configuración insegura en infraestructura o servicios en la nube.
No es un estado en un ticket. Un issue cerrado registra que alguien creyó que el problema estaba resuelto; no es evidencia de que la debilidad desapareció. Tampoco es sinónimo de parchar. Parchar es un camino hacia el arreglo, y la Publicación Especial 800-40 Revisión 4 del NIST, Guide to Enterprise Patch Management Planning (2022), define el patch management empresarial como identificar, priorizar, adquirir, instalar y verificar la instalación de parches, y lo plantea sobre todo como mantenimiento preventivo, no como una reacción a cada aviso.
La remediación de vulnerabilidades vive dentro del ciclo más amplio de la gestión de vulnerabilidades. La detección, el triaje y la priorización deciden qué arreglar y en qué orden. El proceso de remediación de vulnerabilidades es lo que viene después, y la verificación del arreglo es lo que lo cierra.
Por qué importa la remediación de vulnerabilidades
La remediación de vulnerabilidades importa porque la exposición dura exactamente lo que dura la debilidad. La detección por sí sola no cambia nada: una falla reportada que nadie arregla es la misma ruta de ataque que era antes del escaneo, ahora documentada en dos lugares.
Nuestros datos de remediación de vulnerabilidades de 2025 muestran lo desigual que es el trabajo. En el Reporte de ataques 2026, la mediana del tiempo de remediación fue de 14 días para las vulnerabilidades de severidad crítica, pero de 40 días para las de severidad alta, mientras que el tiempo medio de remediación llegó a 36 días para las críticas y 60 días para las altas. Las fallas críticas reciben atención; el nivel inmediatamente inferior espera más que cualquier otro en la fila, incluidos los hallazgos de severidad baja, con una mediana de 28 días.
La remediación de vulnerabilidades también es lo que piden los auditores, porque una lista de hallazgos no es un control. Fluid Attacks fija sus propios plazos de remediación por severidad por esa razón, siguiendo las recomendaciones de marcos como PCI DSS y NIST.
La remediación de vulnerabilidades en Fluid Attacks
Fluid Attacks opera la remediación de vulnerabilidades como un ciclo cerrado. La IA, los escáneres propios y los pentesters reportan una vulnerabilidad con su ubicación exacta y su evidencia de explotación; la plataforma ofrece una ruta de arreglo dentro del editor del desarrollador; y una nueva prueba confirma si el arreglo funcionó antes de que el hallazgo pueda cerrarse.
Qué arreglamos y bajo qué reglas
Nuestro soporte de remediación de vulnerabilidades cubre los tres objetivos que evaluamos. Para el código fuente, la plataforma muestra las líneas vulnerables y el patrón seguro de ese lenguaje. Para los componentes, Software Composition Analysis (SCA) devuelve rutas de actualización para dependencias directas y transitivas. Para la infraestructura, los hallazgos llegan con la configuración corregida del proveedor de nube o la plataforma de contenedores involucrada.
Nada se cierra por afirmación. Un desarrollador marca el trabajo como terminado al solicitar una nueva prueba, no al cambiar un estado. Nuestro motor o nuestros pentesters deciden el resultado.
Cómo se ve en la práctica
Cada ruta de remediación de vulnerabilidades deja un tipo distinto de evidencia:
Ruta de arreglo | Qué recibe el desarrollador | Qué cierra el hallazgo |
|---|---|---|
Custom Fix | Una guía paso a paso generada para el código vulnerable en el IDE | Nueva prueba |
Autofix | Un cambio sugerido aplicado directamente en el archivo | Nueva prueba |
Actualización de dependencia | Tres versiones para elegir: arreglo mínimo, actualización segura, arreglo completo | Nueva prueba después de que el escáner vuelve a correr |
Sesión con pentester | Una llamada de 30 minutos con el pentester que reportó el problema | Nueva prueba manual |
El catálogo público de soluciones de Fluid Attacks: 2.044 arreglos documentados que cubren 326 debilidades en 23 lenguajes de programación.
Dónde ocurre la remediación cambia si ocurre
El patrón más fuerte de nuestros datos de 2025 no es sobre la calidad de las herramientas. Es sobre la distancia entre un hallazgo y la persona que puede corregirlo. Estas comparaciones son observacionales, así que muestran asociación, no causa:
Práctica en 2025 | Sistemas o clientes que la usaron | Los que no |
|---|---|---|
Plugins de IDE | 55,4 % de tasa media de remediación | 28,1 % |
Servidor MCP | 49,7 % de tasa media de remediación | 24,1 % |
CI Gate | 72,2 % de tasa de remediación; mediana de 22 días | 58 %; mediana de 30 días |
Fuente: Fluid Attacks, Reporte de ataques 2026. Las cifras de plugins de IDE cubren al 23 % de los clientes que los usaron desde marzo de 2025; las del servidor MCP, al 41 % que lo usó desde junio de 2025.
Qué hace bien la remediación con GenAI
La IA generativa se gana su lugar en la mitad rutinaria del trabajo. En el Reporte de ataques 2026, Autofix y Custom Fix se usaron en 53,6 % de los sistemas, y Custom Fix representó el 93 % de esos sistemas. El patrón es claro: los equipos recurren mucho más a una guía que explica el arreglo que a un parche aplicado en su nombre.
Esa preferencia está bien puesta, y nuestra propia documentación lo dice sin rodeos: la IA generativa puede producir código vulnerable, así que cada paso generado debe examinarse antes de aceptarlo. La remediación asistida por IA acorta la distancia entre un hallazgo y un arreglo que funciona. No elimina la revisión, las pruebas ni la nueva prueba.
Las reglas que aplicamos a nuestro propio código
Fluid Attacks aplica su solución completa a su propio stack tecnológico, bajo plazos publicados de remediación de vulnerabilidades por severidad:
Puntaje CVSS v4.0 | Tiempo de remediación |
|---|---|
9.0 – 10.0 (Crítica) | ≤ 7 días |
7.0 – 8.9 (Alta) | ≤ 15 días |
4.0 – 6.9 (Media) | ≤ 30 días |
0.1 – 3.9 (Baja) | ≤ 60 días o según prioridad |
Nuestro equipo de ingeniería puede aceptar una vulnerabilidad temporalmente mientras construye el parche: un máximo de dos veces, 30 días cada una, 60 días en total. La meta de porcentaje de remediación está por encima del 99 %. Este es nuestro acuerdo de nivel de servicio interno de remediación, publicado en nuestra documentación de transparencia, no un estándar que toda organización deba copiar.
Remediación, mitigación y aceptación del riesgo no son alternativas
La remediación de vulnerabilidades, la mitigación y la aceptación del riesgo responden preguntas distintas, y tratarlas como un menú es como el riesgo residual se acumula en silencio. La remediación elimina la debilidad. La mitigación de vulnerabilidades reduce la probabilidad o el impacto de la explotación mientras la debilidad sigue ahí. La aceptación es una decisión documentada de convivir con ella.
Tratamiento | Qué cambia | Qué queda | Cuándo aplica |
|---|---|---|---|
Remediación de vulnerabilidades | La debilidad se corrige en su origen | Nada, una vez verificada | Siempre la opción por defecto |
Mitigación | La exposición o el impacto se reducen con un control compensatorio | La falla de fondo y el costo del propio control | Todavía no hay arreglo, o el arreglo necesita una ventana de despliegue |
Aceptación | Nada técnico | La exposición completa, ahora documentada y con dueño | Riesgo bajo, o costo de remediación mayor que la pérdida esperada |
Dos reglas mantienen esto honesto. La mitigación necesita fecha de vencimiento, porque un control temporal que nadie revisa se vuelve arquitectura permanente. La aceptación necesita dueño y fecha de revisión, porque una aceptación sin ninguno de los dos es una vulnerabilidad sin arreglar con mejor papeleo. En los sistemas que evaluamos en 2025, la aceptación permanente cubrió el 0,1 % de las vulnerabilidades de severidad alta y el 0,3 % de las críticas: en un proceso maduro de remediación de vulnerabilidades sigue siendo una excepción, no una válvula de escape.
Cómo se construyen los arreglos de vulnerabilidades
La remediación de vulnerabilidades toma tres formas distintas según dónde viva la debilidad, y confundirlas es la razón por la que se atrasan los planes de remediación.
Tu propio código. La remediación de vulnerabilidades aquí cambia la lógica de la aplicación: añadir la verificación de autorización, parametrizar la consulta, reemplazar el algoritmo débil. Estas correcciones están por completo bajo tu control, y son las que un security champion o un asistente de IA puede entregarle a un desarrollador como un diff concreto.
Tus dependencias. Rara vez parchas código de terceros; cambias versiones. Nuestra plataforma devuelve tres opciones para cada componente vulnerable, de modo que los equipos puedan elegir entre seguridad y estabilidad. Cada opción es un balance distinto de remediación de vulnerabilidades, y la plataforma dice cuál es:
Opción | Qué hace | Costo |
|---|---|---|
Arreglo mínimo | Corrige la vulnerabilidad reportada | Puede introducir nuevas |
Actualización segura | Corrige la vulnerabilidad reportada sin añadir nuevas | Suele ser un salto de versión mayor |
Arreglo completo | Actualiza a la última versión libre de vulnerabilidades conocidas | Mayor probabilidad de cambios que rompan |
Las dependencias transitivas son el caso difícil del trabajo con vulnerabilidades en dependencias, porque no controlas su versión de forma directa. La plataforma identifica el paquete directo que arrastra el código vulnerable y entrega las tres versiones de remediación para él, así el equipo puede confirmar la compatibilidad o llevar el paquete padre a su versión mínima soportada.
Tu infraestructura. Aquí la remediación de vulnerabilidades significa corregir una configuración: cerrar un bucket público, forzar TLS, quitar una política de IAM con permisos de más. Estos arreglos suelen ser los más rápidos de aplicar y los más fáciles de revertir sin querer, y por eso pertenecen a la infraestructura como código y no a una consola.
Arregla la debilidad, no el CVE
Un CVE es una instancia de una falla en un producto; una debilidad es la clase detrás de muchas instancias. Fluid Attacks escribe sus guías de remediación de vulnerabilidades para la clase, y por eso un solo patrón de arreglo sirve para cada CVE que la comparte, en distintos lenguajes y frameworks.
Nuestro catálogo público de soluciones tiene 2.044 arreglos documentados que cubren 326 debilidades en 23 lenguajes de programación, mapeados desde más de 340.000 registros de vulnerabilidades. Cada entrada presenta el código no conforme junto al código seguro y nombra el requisito de seguridad que el cambio satisface, como explica en detalle nuestro artículo sobre la base de datos. Ese mapeo es lo que hace reutilizable la remediación de vulnerabilidades entre tecnologías y frameworks.
Cada entrada de debilidad también trae un tiempo estimado de remediación, lo que convierte la remediación de vulnerabilidades en algo que un equipo puede planear en un sprint en lugar de estimar a ojo. La debilidad 022, uso de un canal inseguro, indica 15 minutos y se asocia al requisito 181, transmitir datos usando protocolos seguros; la debilidad 005, escalada de privilegios, indica 60 minutos y se asocia al requisito 035.
Entrada 022 del catálogo de Fluid Attacks: impacto, recomendación, requisito asociado y tiempo estimado de remediación.
Cómo verificar que una vulnerabilidad fue remediada
La verificación del arreglo es el paso que separa la remediación de vulnerabilidades de un cambio de estado, y existe porque una corrección puede fallar de dos maneras: puede no resolver la debilidad original, o puede introducir una nueva. Nuestra documentación lo dice así, y es la razón por la que ninguna remediación de vulnerabilidades se cierra sin una nueva prueba.
En Fluid Attacks, la reevaluación de la remediación de vulnerabilidades se llama reattack. Tras sincronizar el repositorio corregido, el desarrollador selecciona la ubicación donde aplicó el arreglo y la solicita. Las nuevas pruebas automatizadas las corre la herramienta; las manuales, el pentester que reportó el hallazgo. Si la debilidad sobrevive, la columna Reattack de la vulnerabilidad muestra Verified (vulnerable) y un comentario explica qué sigue funcionando.
La respuesta está acotada por un acuerdo de nivel de servicio: al menos el 90 % de estas solicitudes recibe una primera respuesta en una mediana de menos de ocho horas de oficina. Un desarrollador que pide una nueva prueba en la mañana suele saber antes del final del día si la corrección aguantó.
Las nuevas pruebas confirman la remediación de vulnerabilidades después del hecho. El CI Gate opera en la dirección contraria: rompe la compilación cuando un despliegue lleva vulnerabilidades que violan la política de la organización. Los dos controles sirven a la misma regla: ningún hallazgo se cierra por una afirmación que nadie probó. Un arreglo que pasa una nueva prueba se convierte en un patrón de remediación de vulnerabilidades que el equipo puede reutilizar; uno que falla se convierte en una lección antes de llegar a producción.
Cuando no hay parche disponible
A veces la remediación de vulnerabilidades no está disponible en el plazo que el riesgo exige: el proveedor no ha publicado un arreglo, el componente está sin mantenimiento o la actualización rompe una dependencia en producción. La respuesta es una mitigación documentada con fecha de cierre, tratada como una etapa de la remediación de vulnerabilidades y no como su sustituto.
Situación | Medida provisional | Qué debe ocurrir igual |
|---|---|---|
Aún no hay parche del proveedor | Restringir el acceso de red, desactivar la funcionalidad afectada | Seguir el aviso y aplicar el arreglo cuando salga |
El arreglo rompe compatibilidad | Aislar el componente, añadir validación de entradas aguas arriba | Programar la actualización en una ventana de despliegue |
Componente sin mantenimiento | Reemplazarlo, o bifurcarlo y parcharlo | Tratar el reemplazo como la remediación |
Riesgo menor que el costo de arreglar | Documentar la aceptación con dueño y fecha de revisión | Reevaluar cuando cambien la exposición o los datos de explotación |
Los datos de explotación deciden el plazo. El catálogo KEV de CISA lista fallas con explotación confirmada en el mundo real, y la Directiva Operativa Vinculante 26-04 de CISA, Prioritizing Security Updates Based on Risk, emitida en junio de 2026, exige a las agencias civiles federales de Estados Unidos actuar sobre las entradas del catálogo dentro de los plazos que cada entrada trae, algunos de pocos días. Aparecer en el catálogo KEV de CISA mueve un hallazgo al frente de la fila de remediación de vulnerabilidades, diga lo que diga su puntaje base.
Cómo medir la remediación de vulnerabilidades
Un programa de remediación de vulnerabilidades se mide por lo que se cerró y cuánto tiempo estuvo abierto, no por cuántos hallazgos se reportaron. Cuatro métricas lo cubren.
Tasa de remediación de vulnerabilidades. La proporción de vulnerabilidades reportadas que se arreglaron. La nuestra, en los sistemas evaluados, llegó a 62,2 % al cierre de 2025.
Tiempo medio y mediana de remediación. Reporta los dos y sepáralos por severidad, porque un promedio esconde la cola larga y un agregado esconde qué nivel se está descuidando:
Severidad | Tiempo medio de remediación | Mediana de remediación |
|---|---|---|
Crítica | 36 días | 14 días |
Alta | 60 días | 40 días |
Media | 51 días | 30 días |
Baja | 56 días | 28 días |
Fuente: Fluid Attacks, Reporte de ataques 2026, sobre vulnerabilidades remediadas durante 2025.
Nuevas pruebas fallidas. La proporción de arreglos que no sobrevivieron a la verificación. Es la única métrica de esta lista que mide la calidad de la remediación de vulnerabilidades y no su velocidad, y una cifra en aumento es razón para revisar cómo se revisan los arreglos antes de enviarlos.
Exposición al riesgo residual. Ponderada por severidad en lugar de contada, para que un hallazgo crítico no desaparezca detrás de cien bajos. Para eso usamos el CVSSF.
Conclusiones
La remediación de vulnerabilidades es el único tratamiento que elimina una debilidad, y termina cuando alguien distinto del autor confirma que la debilidad desapareció. La mitigación y la aceptación son opciones legítimas, pero las dos dejan un riesgo residual que necesita dueño y fecha.
Las palancas que mueven el proceso de remediación de vulnerabilidades en nuestros datos no son vistosas: pon el arreglo donde se escribe el código, dale al desarrollador una guía en vez de un parche opaco y haz que la verificación sea una nueva prueba y no una casilla marcada. Los sistemas cuyos desarrolladores usaron nuestros plugins de IDE remediaron a casi el doble de la tasa de los que no, y los sistemas que rompieron la compilación cerraron hallazgos ocho días más rápido en la mediana. Toda otra métrica de un programa de remediación de vulnerabilidades depende de ese hábito.
Preguntas frecuentes
¿Cuál es la diferencia entre remediación y mitigación de vulnerabilidades?
La remediación de vulnerabilidades corrige la debilidad en su origen, así que la ruta de ataque desaparece. La mitigación de vulnerabilidades deja la debilidad en su lugar y reduce la probabilidad o el impacto de la explotación con un control compensatorio, como restringir el acceso de red o desactivar una funcionalidad. La remediación es la meta; la mitigación es lo que compra tiempo hasta que el arreglo esté disponible, y necesita fecha de vencimiento.
¿Cómo se verifica que una vulnerabilidad fue arreglada?
Volviendo a probar la ubicación específica con la misma técnica que la encontró, no cerrando el ticket. En Fluid Attacks esa nueva prueba se llama reattack, y la corre la herramienta de forma automática o el pentester que reportó el hallazgo de forma manual. Si la debilidad sobrevive, la plataforma la marca como Verified (vulnerable). Al menos el 90 % de las solicitudes recibe una primera respuesta en una mediana de menos de ocho horas de oficina.
¿Cuánto debe tardar la remediación de vulnerabilidades?
Depende de la severidad y de los plazos que defina tu acuerdo de nivel de servicio de remediación. Fluid Attacks aplica ≤7 días para crítica, ≤15 para alta, ≤30 para media y ≤60 para baja en su propio código. En la práctica, en los sistemas que evaluamos en 2025, la mediana del tiempo de remediación fue de 14 días para las vulnerabilidades críticas y de 40 días para las de severidad alta.
¿Puede la IA arreglar vulnerabilidades de software de forma segura?
Con revisión, sí, y el patrón de uso refleja esa cautela. Autofix y Custom Fix se usaron en 53,6 % de los sistemas que evaluamos en 2025, y el 93 % de esos sistemas usó Custom Fix, la guía paso a paso, en lugar del parche automático. La IA generativa puede producir código vulnerable, así que la remediación asistida por IA todavía necesita pruebas y una nueva prueba antes de contar como terminada.
¿Fluid Attacks verifica que tus arreglos funcionaron?
Sí. La remediación de vulnerabilidades solo se cierra en nuestra plataforma después de que una nueva prueba lo confirma, solicitada desde la plataforma, el IDE o tu sistema de tickets. Los clientes del plan Advanced reciben reattacks manuales del pentester que reportó la vulnerabilidad, con evidencia en cualquiera de los dos sentidos.
Cierra el ciclo en cada arreglo
Los pentesters y los escáneres de Fluid Attacks vuelven a probar cada arreglo que reportas, para que la remediación de vulnerabilidades termine con evidencia y no con una suposición. Prueba gratuita · Contáctanos.
Empieza ya con la solución de ASPM de Fluid Attacks
