AI Security on KnightLi Blog

Llegó la era de la búsqueda de vulnerabilidades con AI: por qué Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn explotaron juntos

Thu, 21 May 2026 09:30:01 +0800

En las últimas semanas aparecieron varias vulnerabilidades relacionadas con el kernel Linux: Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn entraron una tras otra en la conversación de seguridad. Algunas permiten elevación local de privilegios, otras pueden filtrar archivos muy sensibles y otras afectan hosts de contenedores y entornos multi-tenant. La primera reacción de mucha gente es: ¿por qué Linux se volvió tan inseguro de repente?

La respuesta más precisa es: Linux no empeoró de repente. Problemas ocultos durante mucho tiempo están siendo descubiertos más rápido y de forma más sistemática.

Lo realmente importante en esta ola no son solo los parches para varios CVE, sino el cambio en la forma de descubrir vulnerabilidades. Antes, unos pocos investigadores de primer nivel podían tardar mucho en conectar bugs lógicos entre subsistemas. Ahora, la auditoría asistida por AI, el análisis estático automatizado, el fuzzing y las plataformas de investigación de seguridad amplifican ese trabajo. Las vulnerabilidades no aparecieron de la noche a la mañana, pero la velocidad de descubrimiento, reproducción y difusión aumentó.

Qué tienen en común estas vulnerabilidades

Primero, pongamos los incidentes recientes en una tabla.

Vulnerabilidad	Impacto principal	Rasgos clave	Riesgo principal
Copy Fail / CVE-2026-31431	Elevación local de privilegios	Ruta relacionada con Linux crypto / AF_ALG e issue de escritura en page cache	De usuario normal a root; especialmente sensible en contenedores
Dirty Frag / CVE-2026-43284, CVE-2026-43500	Elevación local de privilegios	Primitiva de escritura en page cache en rutas XFRM/ESP, RxRPC y similares	Explotación encadenable; afecta límites entre host y contenedor
Fragnesia / CVE-2026-46300	Elevación local de privilegios	Problema lógico en el subsistema XFRM ESP-in-TCP	Superficie de ataque cercana a Dirty Frag
ssh-keysign-pwn / CVE-2026-46333	Filtración local de información sensible y riesgo de elevación	Falla lógica en `__ptrace_may_access()` del kernel Linux	Riesgo para claves SSH del host, `/etc/shadow` y otros archivos sensibles

No son la misma vulnerabilidad, pero comparten varios patrones:

No son RCE remotas tradicionales, sino elevación local de privilegios o filtración local de información sensible.
Requieren que el atacante obtenga primero alguna capacidad de ejecución local, como una shell normal, ejecución dentro de un contenedor, permisos de tarea CI o una cuenta de bajo privilegio.
La mayoría del riesgo está en fronteras del kernel: page cache, subsistemas de red/cripto, checks de permiso ptrace y kernels compartidos por contenedores.
Los entornos cloud-native amplifican el impacto, porque los contenedores no son una frontera de seguridad fuerte y el kernel del host sigue siendo la base compartida.

Así que la pregunta no es solo “¿hay parche?”. La pregunta profunda es: ¿por qué problemas tan bajos, ocultos y latentes aparecieron concentrados en tan poco tiempo?

Primera razón: muchas vulnerabilidades son deuda histórica, no código recién escrito

Cuando la gente ve la fecha de divulgación, suele pensar que el bug fue introducido en una versión reciente. Muchas veces no es así.

El punto clave de problemas como Copy Fail es que una vulnerabilidad puede permanecer dormida durante años, hasta que alguien conecta la ruta de llamadas, el límite de permisos y la semántica de memoria correctos. La información pública indica que Copy Fail está relacionada con optimizaciones del kernel alrededor de 2017. Dirty Frag y Fragnesia también apuntan a rutas profundas donde se cruzan red, cripto y page cache.

Lo peligroso de estos bugs no es que una línea de código parezca obviamente mala, sino que varias condiciones se superponen:

Un subsistema procesa datos in-place por rendimiento.
Una interfaz permite a usuarios sin privilegios alcanzar funciones del kernel.
Una ruta conecta páginas de archivo de solo lectura, page cache, fragmentos de red y buffers criptográficos.
Una restricción implícita no está en tipos, asserts ni documentación.
El resultado es una ruta donde un usuario normal puede afectar estado del kernel que no debería tocar.

Esto no es lo que mejor detecta una revisión normal de código. Un revisor puede entender el subsistema crypto, otro la red y otro la gestión de memoria, pero el bug vive justo en la intersección.

Segunda razón: la complejidad del kernel Linux supera el límite de revisión humana

La fortaleza de Linux es ser abierto, general, con amplio soporte de hardware y un ecosistema enorme. Pero esas ventajas también tienen coste.

El kernel Linux moderno no es un “kernel pequeño”. Incluye planificación, memoria, sistemas de archivos, pila de red, frameworks criptográficos, drivers, virtualización, mecanismos de contenedores, eBPF, LSM, módulos de seguridad y adaptación a plataformas de hardware. Cada subsistema tiene historia, mantenedores, objetivos de rendimiento y cargas de compatibilidad.

El problema es que las vulnerabilidades no suelen vivir dentro de un solo módulo, sino en los cruces:

splice() conecta páginas de archivo y pipes.
AF_ALG conecta espacio de usuario con la API crypto del kernel.
XFRM/ESP conecta paquetes de red, cripto y páginas de memoria.
RxRPC y ESP-in-TCP hacen la pila de red más compleja.
Los contenedores vuelven más común la ejecución local de bajo privilegio.

Desde ingeniería, el kernel Linux ya no tiene un tamaño que “muchos ojos” puedan revisar por completo de forma fiable. El open source facilita corregir y revisar, pero no significa que cada rincón reciba revisión de seguridad continua. Pocas personas entienden vulnerabilidades entre subsistemas, y justo esas suelen tener gran impacto.

Tercera razón: las optimizaciones de rendimiento adelgazan las fronteras de seguridad

En esta ola aparece un tema repetido: reducir copias, reutilizar buffers y procesar datos in-place por rendimiento.

Estas optimizaciones son razonables. El kernel es infraestructura. Una pequeña pérdida de rendimiento afecta proveedores cloud, bases de datos, red, almacenamiento y plataformas de contenedores. Una copia menos, cifrado/descifrado más rápido o una asignación menos de memoria pueden importar en producción.

Pero el coste de seguridad también es claro. Cuando los límites entre datos de solo lectura, páginas compartidas, entrada controlada por usuario, buffers del kernel y salida criptográfica se adelgazan, una mala interpretación del contrato de entrada/salida por un subsistema puede generar escrituras o lecturas no autorizadas.

Es decir, la optimización de rendimiento no es incorrecta, pero crea combinaciones más frágiles:

El cifrado/descifrado in-place reduce copias, pero depende más del aislamiento correcto de buffers de entrada y salida.
Page cache mejora el acceso a archivos, pero también puede convertirse en superficie de ataque.
Zero-copy aumenta throughput, pero hace que distintos subsistemas compartan los mismos objetos de memoria.
Los contenedores mejoran despliegue, pero un kernel compartido aumenta el radio de explosión de una LPE local.

Las fronteras de seguridad no pueden mantenerse solo con “todos recuerdan no equivocarse”. Deben imponerse mediante tipos, checks de permisos, restricciones de inmutabilidad, pruebas, fuzzing y auditoría continua. Si no, cuantas más optimizaciones e hipótesis implícitas se acumulen, más probable es que aparezcan vulnerabilidades.

Cuarta razón: los contenedores aumentan el valor de las vulnerabilidades locales

Antes, “elevación local de privilegios” parecía menos urgente que una vulnerabilidad remota, porque el atacante ya necesitaba acceso local. La era cloud-native cambió esa evaluación.

Hoy la ejecución local puede venir de muchas fuentes:

Una aplicación web termina dando una shell normal.
Un job CI/CD ejecuta código no confiable.
Un contenedor corre tareas subidas por usuarios.
Una plataforma multi-tenant permite notebooks, plugins, scripts o builds.
Entornos de ejecución de código AI, sandboxes y jueces online son cada vez más comunes.

Cuando un atacante tiene ejecución dentro de un contenedor, una LPE del kernel ya no es un “problema local pequeño”. Los contenedores comparten el kernel del host, así que una vulnerabilidad del kernel puede cruzar la frontera del contenedor y afectar al host y otros tenants.

Por eso Copy Fail y Dirty Frag atraen tanta atención de equipos cloud, de seguridad y de contenedores. Pueden convertir “ejecución local de bajo privilegio” en “riesgo a nivel de host”.

El impacto de AI: bajó el coste de descubrir vulnerabilidades

La parte más propia de esta época es la búsqueda de vulnerabilidades asistida por AI.

La información pública de Copy Fail menciona que Xint Code de Theori participó en el proceso de descubrimiento. Más allá de las capacidades exactas de la herramienta, esto marca una tendencia: AI no necesariamente inventa vulnerabilidades de la nada, pero ayuda mucho a los investigadores a acortar rutas de búsqueda.

AI afecta la investigación de vulnerabilidades de varias formas:

Leer código desconocido más rápido
Los subsistemas del kernel son grandes. Los investigadores no pueden leer manualmente todas las rutas. AI ayuda a resumir funciones, cadenas de llamadas, relaciones de entrada/salida y patrones sospechosos.
Encontrar conexiones entre módulos más fácilmente
Muchas vulnerabilidades se esconden en cadenas como “entrada de usuario -> pila de red -> framework crypto -> páginas de memoria -> caché de archivos”. AI ayuda a ordenar estas rutas entre archivos, directorios y subsistemas.
Generar hipótesis de auditoría con más facilidad
Preguntas como “qué rutas escriben datos controlados por usuario en page cache”, “qué APIs permiten a usuarios sin privilegios tocar subsistemas crypto” o “qué funciones asumen que buffers de entrada y salida nunca se solapan” pueden enumerarse de forma más sistemática.
Convertir hallazgos en ejemplos reproducibles
AI no sustituye el criterio de investigadores de kernel, pero puede ayudar a escribir código de validación, organizar ideas de PoC, explicar rutas defectuosas y generar tests.

El resultado es que baja el coste unitario de descubrir vulnerabilidades.

Antes, una vulnerabilidad de kernel de alta calidad podía requerir mucho tiempo de investigadores de élite. Ahora, alguien que entiende sistemas y usa herramientas AI puede filtrar rutas sospechosas más rápido. El techo de oferta de vulnerabilidades sube, y las divulgaciones concentradas se vuelven más probables.

Pero AI no es la única razón

También hay que evitar el extremo contrario: culpar de todo a AI.

AI es un acelerador, no la causa raíz. Las causas reales siguen siendo:

Acumulación de código histórico.
Contratos implícitos de optimizaciones de rendimiento que nunca se impusieron.
Complejidad excesiva entre subsistemas.
Demasiadas funciones del kernel expuestas por defecto.
Pruebas de seguridad que no cubren todas las combinaciones.
Contenedores, multi-tenancy y entornos de ejecución automatizada que aumentan el valor de bugs locales.

Sin estas condiciones, ni siquiera una AI potente encontraría tantos bugs de alto impacto. Al revés: mientras existan, cuanto más madura sea AI, más fácil será descubrir vulnerabilidades de forma sistemática.

Qué significa para los defensores

Para equipos de operaciones, seguridad y plataforma, esta ola deja varias lecciones directas.

Primero, no trates la elevación local de privilegios como baja prioridad.
Si tu entorno tiene contenedores, CI, ejecución online, plugins, notebooks o cargas multi-tenant, una LPE local puede convertirse en riesgo de host.

Segundo, el ritmo de parcheo del kernel debe acelerarse.
Hosts críticos, nodos Kubernetes, CI Runner, sandboxes de AI y hosts de virtualización no deberían quedarse mucho tiempo en kernels viejos. Actualizaciones, ventanas de reinicio, live patch y rollback gradual necesitan procesos claros.

Tercero, reduce superficie de ataque del kernel innecesaria.
Protocolos, módulos, user namespaces, sockets especiales e interfaces de debug que no hagan falta deben cerrarse según necesidad de negocio. Activado por defecto no significa expuesto por defecto.

Cuarto, la seguridad de contenedores debe asumir que el kernel puede romperse.
Usar non-root, capabilities mínimas, seccomp, AppArmor/SELinux, sistemas de archivos de solo lectura y montajes sensibles aislados sigue siendo importante. No detienen todos los bugs del kernel, pero reducen condiciones previas y daño posterior.

Quinto, el monitoreo debe mirar cadenas de elevación.
No basta mirar entradas remotas. También hay que vigilar procesos anómalos, lectura de archivos sensibles, carga de módulos kernel, señales de escape de contenedor, anomalías en CI Runner y accesos a archivos valiosos como /etc/shadow y claves SSH del host.

Qué significa para las comunidades open source

Para Linux y grandes proyectos open source, la búsqueda de vulnerabilidades con AI trae doble presión.

Por un lado, AI ayuda a defensores a encontrar problemas antiguos más rápido. Más vulnerabilidades latentes corregidas públicamente es bueno a largo plazo.

Por otro lado, AI también crea ruido. Reportes automáticos de baja calidad, falsos positivos, duplicados y afirmaciones de “AI encontró un bug” sin contexto consumen tiempo de mantenedores. El reto no es “usar o no AI”, sino cómo integrar su salida en procesos responsables de seguridad:

Los reportes deben tener reproducción mínima.
Deben explicar alcance e hipótesis de amenaza.
Deben distinguir problema teórico, bug activable y vulnerabilidad explotable.
Deben respetar embargo, coordinación con distribuciones y ventanas de corrección.
Los mantenedores necesitan mejores tests automatizados, fuzzing, análisis estático y validación de regresión.

AI acelera el descubrimiento de vulnerabilidades, y eso exige mecanismos de corrección y coordinación más maduros. Si no, la productividad de investigación se convierte en presión para mantenedores y pánico para usuarios.

Conclusión: no es el fin del mito, es una nueva realidad de seguridad

Linux sigue siendo una de las bases de sistemas operativos más transparentes, controlables, corregibles y endurecibles. El problema no es que Linux se haya vuelto inseguro de repente, sino que la complejidad del kernel moderno, el uso cloud-native y la búsqueda asistida por AI están cambiando la velocidad de exposición de vulnerabilidades.

Es probable que aparezcan eventos parecidos. No porque cada vez haya un nuevo desastre, sino porque rutas complejas acumuladas durante años se están buscando de forma más eficiente.

Lo que debe cambiar son nuestras hipótesis de seguridad:

No tratar “no hay vulnerabilidades divulgadas” como “no hay vulnerabilidades”.
No tratar la elevación local de privilegios como bajo riesgo.
No tratar el aislamiento de contenedores como frontera fuerte.
No confiar solo en revisión manual para software de sistema con decenas de millones de líneas.
No esperar solo parches; reducir superficie, acelerar parcheo y construir defensa en profundidad.

AI llevó la búsqueda de vulnerabilidades a una era de mayor producción. Para atacantes y defensores. La diferencia es si los defensores pueden convertir esa capacidad en auditoría más rápida, correcciones más tempranas y gobernanza de infraestructura más estable.

Referencias

APT45 usa IA para validar vulnerabilidades a escala: baja la barrera de los ataques zero-day

Sun, 17 May 2026 19:52:39 +0800

Google Threat Intelligence Group publicó un nuevo AI Threat Tracker el 11 de mayo de 2026. Lo importante no es solo que los atacantes estén usando IA. El cambio real está en cómo la usan: de escritura, traducción y reconocimiento pasan a investigación de vulnerabilidades, validación de PoC, ofuscación de malware y orquestación automática de ataques.

Hay dos puntos que se mezclan con facilidad, así que conviene separarlos.

Primero, Google dijo que identificó lo que considera el primer exploit zero-day desarrollado con ayuda de IA. Ese caso corresponde a un grupo de ciberdelincuencia no identificado. El objetivo era una herramienta popular y open source de administración web, y la vulnerabilidad permitía saltarse 2FA cuando el atacante ya tenía credenciales válidas. Google afirmó que trabajó con el proveedor afectado para la divulgación responsable y que pudo haber evitado una explotación masiva.

Segundo, APT45 no fue atribuido como responsable de ese zero-day. GTIG señaló por separado que APT45, un grupo vinculado a Corea del Norte, fue observado enviando grandes volúmenes de prompts repetitivos a modelos de IA para analizar recursivamente distintos CVE y validar exploits PoC. Es decir, APT45 está usando IA como herramienta de investigación de vulnerabilidades y gestión de arsenal, no solo como asistente para escribir correos de phishing.

Qué muestra el caso del zero-day asistido por IA

Este zero-day no era un fallo típico de corrupción de memoria, filtrado de entrada o mala configuración simple. GTIG lo describió como una falla lógica semántica de alto nivel: el desarrollador había codificado una suposición de confianza dentro del flujo de autenticación, creando una contradicción entre la lógica de 2FA enforcement y sus excepciones.

Este tipo de vulnerabilidad no es cómodo para los escáneres tradicionales. El análisis estático y el fuzzing son mejores encontrando crashes, sinks peligrosos, rutas de entrada y salida, y patrones conocidos. No siempre entienden qué garantía quería preservar el desarrollador y en qué excepción se rompe esa garantía.

Ahí aparece el riesgo de los modelos grandes. No necesariamente son mejores que un investigador de seguridad experto, pero son buenos leyendo contexto, explicando intención, comparando rutas de código parecidas y señalando inconsistencias de lógica de negocio. Cuando los atacantes conectan esa capacidad a procesos automatizados, fallos lógicos que antes requerían mucha lectura manual pueden filtrarse a mayor escala.

GTIG también observó señales de generación por IA en el exploit, como docstrings educativos, una puntuación CVSS inventada y una estructura Python de estilo casi didáctico. Google también indicó que no cree que se haya usado Gemini, aunque tiene alta confianza en que el actor utilizó algún modelo de IA para apoyar el descubrimiento y la weaponization de la vulnerabilidad.

Por qué el cambio de APT45 merece atención

APT45 se sigue desde hace años como un grupo de amenazas vinculado a Corea del Norte, con actividades de espionaje, obtención de ingresos e inteligencia estratégica. Lo que GTIG destacó esta vez fue su forma de usar IA: análisis masivo, repetitivo y recursivo de CVE, validación de PoC exploit y acumulación de capacidades de ataque más fiables.

Eso no es lo mismo que pedirle a la IA que escriba un script.

Si una organización puede conectar IA con triaje de vulnerabilidades, validación de PoC, ajuste de payloads y entornos de prueba, cambia su cuello de botella humano. Antes, cuántas vulnerabilidades podía estudiar un equipo dependía del número de investigadores, su experiencia y el tiempo disponible. Ahora la IA puede absorber parte de la lectura repetitiva, el resumen, las pruebas de variantes y el juicio inicial, dejando a las personas más tiempo para seleccionar objetivos, confirmar explotabilidad y preparar la entrega.

Para los defensores, esto significa que la ventana de exposición de vulnerabilidades conocidas se acorta.

Después de que se divulga un CVE, los atacantes no tienen que leer desde cero el aviso, revisar el patch diff, montar el entorno y arreglar un PoC manualmente. La IA puede ayudar a entender impacto, generar ideas de prueba, depurar fallos y resumir diferencias entre versiones objetivo. Aunque el resultado aún requiera corrección humana, el rendimiento total sube.

Esto no significa que la IA pueda hackearlo todo sola

No hace falta interpretar esto como prueba de que la IA ya puede completar intrusiones enteras por sí sola.

El informe de GTIG dice algo más concreto: varias fases de la cadena de ataque están siendo aceleradas por IA. Investigación de vulnerabilidades, ofuscación de malware, reconocimiento, ingeniería social, operaciones de información, automatización de UI móvil y abuso de cadena de suministro ya muestran señales de participación de IA.

Pero la IA todavía falla. Puede alucinar vulnerabilidades, juzgar mal la explotabilidad, generar código que no funciona o perderse en lógica de autorización empresarial compleja. El peligro real no es que la IA sea perfecta, sino que los atacantes pueden probar barato. Cuando el ensayo masivo es suficientemente barato, las salidas malas se filtran y las útiles entran en la operación.

Por eso importan casos como APT45. Los grupos estatales o cercanos al Estado tienen objetivos y paciencia. Si la IA reduce el trabajo repetitivo, pueden dedicar más recursos a objetivos de alto valor.

La defensa debe mirar menos “si hay zero-day” y más “cuánto dura la ventana”

Muchas empresas solían dividir el riesgo en dos grupos: vulnerabilidades conocidas mediante gestión de parches y zero-days mediante defensa en profundidad. Cuando la IA entra en la investigación de vulnerabilidades, esa frontera se vuelve menos clara.

Las preguntas prácticas son:

Tras publicarse un nuevo CVE, ¿cuánto tarda un atacante externo en producir un exploit utilizable?
¿Puede el inventario de activos decir el mismo día qué sistemas están afectados?
¿Pueden WAF, EDR, logs e identidad detectar intentos anómalos?
¿Los sistemas de alto riesgo usan MFA, mínimo privilegio y aislamiento de red por defecto?
¿Los componentes open source, plugins de AI agent y conectores de terceros entran en la revisión de cadena de suministro?

Los zero-days asistidos por IA no invalidan la seguridad básica. Al contrario, castigan los entornos donde esa base lleva demasiado tiempo descuidada.

Si el ciclo de parches es lento, el inventario no está claro, la exposición a internet no tiene dueño, los logs no se pueden consultar y los permisos de cuentas son excesivos, que el atacante use IA solo cambia la eficiencia. El problema ya existía.

La cadena de suministro de IA también es superficie de ataque

GTIG también señaló que los atacantes empiezan a mirar el ecosistema de software de IA: agent skills, conectores de datos de terceros, librerías wrapper open source y frameworks de automatización. El riesgo no siempre viene de que el modelo sea comprometido. También puede venir de herramientas contaminadas alrededor del modelo.

Esto importa para cualquiera que use AI coding, AI Agent o plugins de automatización.

Un skill malicioso, una dependencia con backdoor o un conector con permisos excesivos pueden convertir un sistema de IA de ayudante en ruta de ejecución para el atacante. Cuando un agent puede acceder a archivos, navegador, terminal, cuentas cloud o datos empresariales, la revisión de cadena de suministro no puede quedarse en la capa tradicional de aplicaciones.

Como mínimo:

No instalar agent skills ni plugins de origen dudoso.
Aislar herramientas que ejecutan comandos, leen archivos o acceden a secretos.
No ejecutar scripts generados por IA sin revisar directamente en producción.
Escanear dependencias, GitHub Actions, paquetes PyPI / npm y componentes de proyectos de IA.
Aplicar mínimo privilegio y monitoreo de filtraciones a model API keys, secretos cloud y GitHub Token.

Consejos prácticos para equipos de seguridad

Primero, adelantar la respuesta a vulnerabilidades. Los CVE de alto riesgo no deberían esperar a una ventana mensual de parches, sobre todo en VPN, gateways, paneles de administración, sistemas de identidad, CI/CD y herramientas de administración remota.

Segundo, construir un inventario de activos consultable. Si la IA ayuda a los atacantes a ubicar objetivos más rápido, los defensores también deben responder rápido: ¿tenemos este sistema, qué versión y dónde está expuesto?

Tercero, complementar firmas con detección de comportamiento. Los exploits y malware generados por IA pueden cambiar rasgos superficiales, pero bypass de autenticación, inicios de sesión anómalos, exploración masiva, patrones de solicitudes fallidas y elevación de privilegios dejan huellas de comportamiento.

Cuarto, incluir las herramientas de IA en la gobernanza de seguridad. Coding agents, browser agents, document agents, scripts de automatización y mercados de plugins internos necesitan aprobación, revisión, logs y rollback.

Quinto, no reducir la defensa con IA a comprar un modelo de seguridad. Lo útil es poner IA en priorización de vulnerabilidades, análisis de logs, evaluación de impacto de parches, revisión de código y comprobación de baselines de configuración, para que la velocidad defensiva también suba.

Resumen

El informe de GTIG envía una señal clara: la IA está acelerando el ritmo del ataque y la defensa.

El zero-day asistido por IA muestra que los fallos lógicos y bypasses de autenticación pueden ser más fáciles de detectar con modelos. El caso APT45 muestra que grupos maduros ya usan IA para analizar CVE y validar PoC a escala. PROMPTSPY, la ofuscación generada por IA y los ataques a la cadena de suministro de agents muestran que la IA está entrando en la cadena de herramientas ofensivas.

No es el fin del mundo, pero tampoco es una noticia cualquiera.

Para las organizaciones, la respuesta práctica no es el pánico. Es hacer que parches, activos, logs, identidad, cadena de suministro y permisos de herramientas de IA sean más rápidos, claros y verificables. La IA aumenta la velocidad de prueba de los atacantes. Los defensores también deben aumentar la velocidad de descubrimiento, juicio y remediación.