Durante los últimos días se han acumulado suficientes incidentes de seguridad como para alimentar una imagen inquietante: vulnerabilidades críticas en componentes utilizados por millones de servidores, campañas contra bancos y empresas, cadenas de suministro comprometidas, credenciales robadas y agentes de inteligencia artificial capaces de mantener operaciones ofensivas durante horas con escasa intervención humana.
La expresión octubre negro ha empezado a utilizarse para explicar ese escenario. Circulan también cifras sobre millones de ataques, cientos o miles de empresas comprometidas y enjambres de agentes de IA actuando de forma autónoma contra Internet.
Los hechos dibujan una situación grave, aunque bastante diferente.
No existe evidencia de una gran ofensiva coordinada de agentes de IA contra Internet ni de que todos los incidentes ocurridos durante estas semanas tengan una causa común. Tampoco puede equipararse el enorme volumen de intentos de explotación registrado contra algunas vulnerabilidades con un número equivalente de intrusiones exitosas.
Sí existen, en cambio, pruebas de un cambio importante. Durante las últimas semanas han coincidido vulnerabilidades críticas descubiertas con ayuda de modelos avanzados, ataques reales en los que agentes de IA han realizado una parte sustancial del trabajo técnico y campañas que muestran cómo una sola persona puede investigar y atacar centenares o miles de objetivos a un coste mucho menor que hace unos años.
PHP2Shell, ARTEX y Cairn permiten observar tres piezas diferentes de ese cambio. La IA puede contribuir a encontrar vulnerabilidades extremadamente difíciles y convertirlas en vectores explotables. Puede integrarse en herramientas capaces de ejecutar reconocimiento, adaptar estrategias y continuar atacando durante horas. Y puede multiplicar la escala a la que opera una persona.
El resultado para las empresas es especialmente relevante. La carrera entre descubrir una vulnerabilidad y corregirla siempre ha existido, pero algunas partes de ese proceso se están acelerando mucho más deprisa que los procedimientos internos necesarios para inventariar sistemas, probar actualizaciones y desplegar correcciones.
Esa compresión de la ventana defensiva explica mejor el octubre negro que buena parte de las afirmaciones que han circulado durante estos días.
Qué significa realmente el octubre negro de la ciberseguridad
«Black October» no es la denominación de una campaña atribuida a un determinado grupo ni una declaración oficial de organismos como CISA, CERT-EU o el NCSC británico. La expresión se popularizó en redes sociales al coincidir durante los últimos días numerosos incidentes, vulnerabilidades críticas y alertas de seguridad.
Una de las publicaciones que ayudó a extenderla llegó a describir las 48 horas anteriores como las peores de la historia de la ciberseguridad. El problema de esa interpretación aparece al revisar uno por uno los incidentes de la lista: muchos habían comenzado semanas o meses antes y responden a causas completamente diferentes.
Dentro del mismo relato terminaron mezclándose ataques contra la cadena de suministro, vulnerabilidades de software, fallos criptográficos, robos de credenciales, filtraciones de datos y campañas en las que sí existe evidencia del uso de agentes de IA.
La concentración de incidentes y alertas es real. La causalidad común, no.
La distinción importa porque presentar todos estos incidentes como ataques relacionados con la inteligencia artificial dificulta entender qué está cambiando realmente. El uso de agentes en operaciones ofensivas es solo una parte de lo ocurrido, pero también una de las que puede tener mayores consecuencias para empresas y equipos de seguridad.
Los agentes no han sustituido de repente a los atacantes humanos. Lo que empieza a observarse es una transferencia progresiva de tareas que antes requerían trabajo especializado: reconocer infraestructura, identificar puntos débiles, probar credenciales, interpretar errores, modificar una estrategia, escribir código o seguir investigando después de que falle el primer intento.
Es el salto que separa la automatización convencional de un sistema agéntico.
Un escáner puede recorrer miles de direcciones buscando una vulnerabilidad conocida siguiendo unas instrucciones determinadas. Un agente puede recibir un objetivo, explorar lo que encuentra, decidir qué probar después y adaptar el proceso a los resultados.
Esa diferencia ya aparece en operaciones reales.
PHP2Shell y el episodio que convirtió la alarma en global
El caso que ha concentrado buena parte de la atención es PHP2Shell, el nombre con el que se conocen conjuntamente CVE-2026-109618 y CVE-2026-109619.
Ambas vulnerabilidades afectan al núcleo de PHP, uno de los componentes más extendidos de la web. Las versiones corregidas se publicaron el 21 de octubre y los dos fallos recibieron una puntuación de 9,2 sobre 10 en CVSS 4.0. En determinadas condiciones, permiten que un atacante sin autenticar ejecute código en un servidor vulnerable.
La escala potencial explica la reacción. PHP está presente en aproximadamente siete de cada diez sitios web cuyo lenguaje de servidor puede identificarse. Ese porcentaje ha aparecido repetidamente resumido como «el 70% de Internet está en peligro», una formulación que necesita varios matices.
Que un servidor utilice PHP no implica automáticamente que haya sido atacado, que siga ejecutando una versión vulnerable o que pueda explotarse con éxito. Mucho menos significa que el 70% de Internet haya sido comprometido.
La superficie potencial sí es extraordinariamente grande.
El aspecto más significativo de PHP2Shell está, además, en su descubrimiento.
Wiz comenzó en agosto una investigación sobre PHP utilizando su plataforma Atlas y modelos de frontera. La compañía explica que Gemini 4 Argon y GPT-5.6 Sol participaron en el proceso de investigación que permitió encontrar las vulnerabilidades y desarrollar vías prácticas de explotación. Otro investigador, Calif, había llegado independientemente a una vulnerabilidad crítica dentro del programa Patch the Planet de OpenAI.
El problema técnico subyacente tenía antecedentes. Parte de las condiciones relacionadas con el fallo había sido discutida previamente por mantenedores de PHP, pero faltaba una ruta práctica que permitiera convertirlas en ejecución remota de código.
Ahí está uno de los elementos que probablemente tendrán consecuencias más duraderas.
Durante décadas han existido errores de software que permanecían sin explotar porque encontrar una combinación práctica de condiciones, construir un exploit estable y depurarlo exigía demasiado conocimiento, tiempo o dinero. Los modelos avanzados empiezan a reducir algunos de esos costes.
Una vulnerabilidad antigua puede adquirir un riesgo distinto cuando cambia la capacidad de quien intenta explotarla.
PHP2Shell ofrece un ejemplo particularmente visible porque la IA aparece del lado defensivo: investigadores utilizaron modelos para encontrar un fallo antes de que se conociera una explotación exitosa generalizada. Pero las mismas capacidades empleadas para comprender código, plantear hipótesis y desarrollar pruebas pueden estar disponibles para un atacante.
De un fallo crítico a millones de intentos en cuestión de horas
La cronología posterior muestra el otro problema.
Amazon Threat Intelligence registró en su red de «honeypots» MadPot un intento de explotación relacionado con PHP2Shell el 17 de octubre, cuatro días antes de la divulgación pública y de la publicación de los parches. La compañía no ha podido determinar cómo consiguió el atacante información sobre las vulnerabilidades. Tampoco puede establecer que aquel intento hubiera funcionado contra un sistema real.
La precisión resulta importante: existe evidencia de actividad ofensiva previa a la divulgación, pero esa observación no demuestra que un agente de IA descubriera independientemente el fallo.
Después llegó la aceleración.
Cuando las correcciones y los detalles técnicos comenzaron a circular, aparecieron pruebas de concepto y distintos actores empezaron a lanzar tráfico contra sistemas expuestos. Cloudflare desplegó mitigaciones y observó cómo los atacantes iban modificando sus «payloads» en respuesta a las defensas. Su consejero delegado, Matthew Prince, llegó a hablar de millones de intentos de explotación.
Es probablemente el dato que más confusión ha generado.
Millones de intentos de explotación no significan millones de servidores comprometidos.
Un mismo sistema puede recibir multitud de peticiones maliciosas. Un atacante puede probar repetidamente la misma técnica. Muchas peticiones pueden dirigirse contra máquinas que ya están actualizadas, no utilizan la configuración necesaria o disponen de mecanismos capaces de bloquearlas.
Confirmar una intrusión exige además otro nivel de evidencia: demostrar que el ataque tuvo éxito y que permitió ejecutar código, acceder a datos o modificar el sistema.
A 23 de octubre, las fuentes públicas consultadas no habían confirmado una ola de ataques exitosos mediante PHP2Shell comparable al volumen de intentos observado. The Verge señalaba que todavía no se habían confirmado ejecuciones remotas exitosas, mientras The Guardian hablaba de millones de intentos sin una gran brecha pública atribuida al fallo.
Eso puede cambiar a medida que avancen las investigaciones forenses.
Existe además una segunda afirmación que la evidencia disponible no permite sostener: que esos millones de intentos estén siendo ejecutados por agentes de inteligencia artificial.
La explotación masiva automatizada lleva décadas formando parte de Internet. Scripts, botnets y herramientas de escaneo pueden comenzar a buscar un fallo en cuanto aparece una prueba de concepto. En PHP2Shell sabemos que la IA intervino en el descubrimiento y desarrollo de rutas de explotación. Sabemos también que existe actividad automatizada a gran escala. No existe por ahora una atribución pública que permita unir ambas afirmaciones y concluir que el tráfico procede mayoritariamente de agentes autónomos.
ARTEX muestra dónde sí están atacando los agentes
Para encontrar pruebas mucho más claras del uso ofensivo de agentes hay que mirar otros casos.
ARTEX es un «framework» de pruebas de penetración capaz de conectar modelos de lenguaje con diferentes herramientas y coordinar agentes que realizan tareas ofensivas. Puede encargarse de actividades que van desde el reconocimiento hasta la explotación y la exfiltración con poca intervención humana.
CrowdStrike vinculó su utilización a una campaña contra entidades financieras de Corea del Sur que comenzó a finales de septiembre. Reuters informó inicialmente de ataques contra al menos nueve bancos y relacionó la actividad con un joven atacante probablemente situado en China. ARTEX fue utilizado junto a modelos como Claude para automatizar partes del proceso.
Las consecuencias fueron reales. Algunas instituciones comunicaron exposición de información de clientes y las autoridades surcoreanas ampliaron posteriormente las investigaciones a más entidades financieras.
La atribución necesita cautela. Identificar a un operador probablemente ubicado en China no equivale a atribuir esa campaña al Estado chino.
El desarrollador de ARTEX retiró después el repositorio público y anunció que las siguientes versiones dejarían de distribuirse como código abierto tras conocerse el abuso de la herramienta. Las copias ya existentes continuaron disponibles.
Pocos días después apareció un caso todavía más significativo.
Microsoft atribuyó al actor alineado con China al que denomina Storm-0940 una operación que utilizó ARTEX dentro de una campaña relacionada con el compromiso de ConnectWise Cloud Backup. Según la telemetría de Microsoft, los atacantes emplearon agentes para automatizar reconocimiento, intentos de contraseña y abuso de aplicaciones OAuth contra organizaciones de numerosos sectores.
La escala permite entender qué aporta la IA.
Microsoft registró más de 151.000 intentos fallidos de autenticación en una de las campañas y picos de alrededor de 2.900 intentos por minuto. Tras comprometer identidades de aplicaciones de ConnectWise, el actor pudo llegar a más de 2.250 «tenants» de Microsoft 365.
Eso tampoco significa que 2.250 organizaciones fueran comprometidas.
La propia Microsoft subraya que la mayoría de los intentos contra las organizaciones objetivo no tuvieron éxito. En algunos entornos sí se produjo actividad posterior y el atacante obtuvo acceso privilegiado. En varios casos, el intervalo entre seleccionar el objetivo y alcanzar privilegios elevados fue inferior a tres horas.
Ahí aparece una medida mucho más útil que cualquier cifra viral sobre empresas «hackeadas»: la velocidad.
Miles de intentos pueden generar alertas. El problema es que, cuando reconocimiento, autenticación y movimientos posteriores ocurren a velocidad de máquina, una organización dispone de muy poco margen para investigar esas señales y actuar antes de que el atacante continúe.
Cairn y el coste de atacar más de mil objetivos
La investigación sobre Cairn permite observar otro cambio relevante, esta vez relacionado con la economía del atacante. El investigador Snorre Fagerland, de NorForge, accedió a instalaciones expuestas de esta plataforma y pudo analizar cómo distintos operadores utilizaban sus agentes. Uno de ellos lanzó campañas contra más de 1.200 sitios web y consiguió acceder a más de un centenar, incluidos sitios relacionados con Deere, SharkNinja y Cummins.
El funcionamiento de la operación ayuda a entender por qué este caso resulta especialmente significativo. El operador podía proporcionar instrucciones muy breves y dejar que los agentes continuaran trabajando durante horas: exploraban la infraestructura disponible, buscaban vulnerabilidades, probaban distintos caminos y modificaban su actuación cuando una opción no funcionaba. En algunas intrusiones, ese proceso se prolongó durante unas 23 horas sin supervisión humana continua.
Fagerland calculó que el gasto asociado a la actividad observada rondó los 5.000 dólares, aproximadamente 50 dólares por intrusión conseguida. La cifra describe exclusivamente esa campaña y no puede interpretarse como un precio general del cibercrimen ni como una estimación de lo que costaría comprometer cualquier empresa. Su relevancia está en lo que revela sobre la distribución del trabajo entre el atacante y los agentes.
Una operación de este tipo habría requerido tradicionalmente muchas horas de atención humana. Cuando una parte sustancial de ese trabajo puede delegarse en agentes que actúan de forma simultánea sobre múltiples objetivos, el coste de investigar una organización adicional se reduce y el tiempo del operador deja de crecer en la misma proporción que el número de sistemas analizados. El atacante sigue eligiendo objetivos, configurando las herramientas y supervisando los resultados, pero ya no necesita intervenir personalmente en cada paso.
Esa capacidad ayuda también a distinguir un agente de un «chatbot» utilizado como apoyo. Un asistente conversacional puede explicar cómo realizar una tarea o ayudar a escribir código; un sistema agéntico puede ejecutar acciones, observar sus resultados, modificar el siguiente paso y continuar trabajando con un grado creciente de autonomía. Es esa combinación de ejecución, adaptación y persistencia la que empieza a modificar la escala a la que puede operar una sola persona.
El error de convertir todos los incidentes de octubre en ataques de IA
El alcance de ese cambio no significa que cualquier incidente ocurrido durante estas semanas pueda relacionarse con la inteligencia artificial. De hecho, uno de los problemas de la narrativa del «octubre negro» es que ha terminado agrupando bajo una misma explicación sucesos que tienen orígenes y características muy diferentes.
LiteLLM proporciona un buen ejemplo. El 21 de octubre apareció en PyPI la versión 1.107.0 de esta biblioteca, utilizada para conectar aplicaciones con diferentes proveedores de modelos. El paquete había sido manipulado e incluía código destinado a robar credenciales, y también quedaron afectadas las imágenes correspondientes distribuidas mediante Docker. Wiz calculó alrededor de 49.000 descargas antes de que la versión fuese puesta en cuarentena.
El «malware» buscaba claves de AWS, GCP y Azure, credenciales SSH, datos almacenados en navegadores y tokens relacionados con servicios de inteligencia artificial. Wiz observó además el uso de credenciales de AWS robadas pocas horas después de su extracción. LiteLLM ocupa una posición especialmente sensible dentro de muchas arquitecturas porque conecta aplicaciones y modelos y puede encontrarse cerca de secretos de alto valor, por lo que el incidente está directamente relacionado con el crecimiento de la infraestructura de IA.
También existen indicios de que un modelo pudo participar en el desarrollo del código malicioso, pero esa circunstancia no permite concluir que un agente autónomo ejecutara toda la intrusión. Utilizar un LLM para escribir o adaptar «malware» y delegar una operación ofensiva completa en agentes son fenómenos diferentes, aunque ambos formen parte de la transformación que está experimentando la seguridad.
El caso de eMudhra muestra todavía mejor por qué conviene separar los distintos episodios. La compañía india había generado en abril de 2025 varias claves privadas extraordinariamente débiles para autoridades de certificación intermedias. El problema permaneció sin detectar durante aproximadamente 18 meses y terminó provocando que grandes fabricantes dejaran de confiar en los certificados afectados. Reuters informó de ocho claves afectadas y de la posterior salida de eMudhra del negocio internacional de certificados SSL/TLS.
Una autoridad intermedia comprometida puede permitir la emisión de certificados fraudulentos y facilitar la suplantación de servicios, por lo que las consecuencias potenciales del fallo eran considerables. Sin embargo, no existe evidencia que permita relacionarlo con agentes de IA. La coincidencia temporal de PHP2Shell, LiteLLM, eMudhra y otras vulnerabilidades contribuye a explicar la sensación de crisis que ha rodeado a octubre, pero presentarlos como partes de una misma ofensiva ofrecería una imagen equivocada de lo ocurrido.
Qué cambia realmente cuando el atacante utiliza agentes
La automatización ofensiva existe desde mucho antes de la inteligencia artificial generativa. Internet lleva décadas recibiendo escaneos automáticos, intentos de fuerza bruta, explotación masiva de vulnerabilidades conocidas, campañas de «phishing» y actividad de botnets capaces de operar a gran escala sin que una persona intervenga en cada acción.
La diferencia que empiezan a mostrar ARTEX y Cairn está en el tipo de tareas que pueden automatizarse. En lugar de limitarse a ejecutar una secuencia programada previamente, un agente puede interpretar el resultado de una acción y utilizarlo para decidir qué hacer después. Si un servicio no responde como esperaba, puede probar otro camino; si encuentra nueva información durante el reconocimiento, puede incorporarla a su investigación; también puede generar o adaptar código, conservar contexto entre tareas y continuar trabajando durante horas. Dependiendo de la arquitectura utilizada, varios agentes pueden además repartirse funciones y coordinar sus resultados.
De esta forma, parte de las decisiones que antes obligaban a alternar continuamente entre herramientas automáticas y un operador humano empiezan a integrarse dentro del propio proceso. Eso no significa que hayan desaparecido las personas que dirigen los ataques. En los casos documentados hasta ahora sigue habiendo alguien que selecciona objetivos y herramientas, proporciona instrucciones, mantiene la infraestructura y recoge los resultados.
Por esa razón, hablar de inteligencias artificiales que deciden espontáneamente atacar empresas describiría un escenario distinto del que muestran las investigaciones actuales. Lo que sí está aumentando es la autonomía operativa que puede delegarse en el sistema y, con ella, la capacidad de un atacante para trabajar sobre muchos más objetivos sin multiplicar en la misma proporción el tiempo humano necesario.
La ventana entre vulnerabilidad y ataque se está estrechando
PHP2Shell permite conectar esa mayor autonomía con otro fenómeno: la reducción del tiempo que puede transcurrir entre la aparición de una vulnerabilidad y los primeros intentos de aprovecharla.
Amazon extrae una conclusión especialmente relevante de lo ocurrido: la dependencia histórica de una prueba de concepto pública está perdiendo importancia. Durante años, numerosos actores esperaban a que investigadores especializados publicaran código funcional antes de incorporar una vulnerabilidad a sus campañas. Las herramientas asistidas por IA pueden reducir el trabajo necesario para analizar un parche, entender qué problema corrige y desarrollar un exploit, lo que permite comenzar esa investigación mucho antes.
Para una empresa, los tiempos son distintos. Ante una vulnerabilidad crítica necesita localizar los componentes afectados, entender qué aplicaciones dependen de ellos, determinar qué versiones están instaladas, conseguir una actualización, comprobar que no interfiere con otros servicios, autorizar el cambio, desplegarlo y verificar posteriormente el entorno. En una organización grande, además, esas tareas suelen estar repartidas entre varios equipos y sometidas a procedimientos destinados a evitar que una corrección genere nuevos problemas.
Mientras ese proceso avanza, el trabajo ofensivo puede desarrollarse en paralelo. Un modelo puede estar analizando código mientras un agente explora activos expuestos y otra herramienta prueba credenciales; al mismo tiempo pueden desarrollarse nuevas variantes de un exploit o continuar los intentos contra miles de sistemas, independientemente de que sea de madrugada o fin de semana.
La cuestión relevante, por tanto, no es únicamente que los ataques puedan ser más rápidos. Es que determinadas fases de la operación ofensiva están acelerándose a un ritmo que las organizaciones difícilmente pueden reproducir en procesos que requieren coordinación, comprobaciones y decisiones humanas. Esa diferencia entre ambas velocidades constituye una de las principales consecuencias empresariales de los episodios observados durante octubre.
Qué deberían estar preguntándose las empresas
Los acontecimientos de estas semanas trasladan algunas cuestiones que tradicionalmente podían quedar confinadas a los equipos de seguridad hacia responsables de tecnología, operaciones y negocio. No se trata de extraer una lista universal de medidas a partir de unos incidentes concretos, pero sí de observar qué capacidades organizativas adquieren mayor importancia cuando el tiempo disponible para responder empieza a reducirse.
Una de ellas es la visibilidad sobre los propios sistemas. Ante una vulnerabilidad como PHP2Shell, saber simplemente que «la empresa utiliza PHP» aporta poca información para evaluar la exposición real. La organización necesita poder determinar dónde está desplegado, qué versiones mantiene, qué aplicaciones dependen de ellas y cuáles de esos sistemas están accesibles desde Internet. Cuanto más tiempo requiera responder a esas preguntas, mayor será la parte de la ventana defensiva que se consume antes incluso de tomar una decisión.
Algo parecido ocurre con los procesos de actualización. Los ciclos diseñados alrededor de semanas pueden encontrarse ahora con vulnerabilidades cuya explotación comienza antes de la publicación oficial o apenas unas horas después de que aparezca una corrección. Eso no implica que una actualización crítica deba instalarse automáticamente en producción, porque un parche también puede afectar a servicios esenciales. La cuestión para los responsables tecnológicos está en conocer cuánto tarda realmente su organización en pasar de una alerta crítica a una evaluación fiable y, a partir de ahí, a una decisión que pueda ejecutarse.
Las dependencias introducen otro nivel de exposición. ConnectWise muestra el alcance que puede conseguir un atacante cuando compromete una aplicación que ya dispone de confianza y permisos dentro de los sistemas de sus clientes. LiteLLM plantea una cuestión similar para la nueva infraestructura asociada a la inteligencia artificial: gateways, herramientas de desarrollo, repositorios y sistemas de orquestación pueden concentrar tokens, claves cloud y otras credenciales de especial valor, de modo que su posición dentro de la arquitectura importa tanto como la función que desempeñan.
La velocidad también obliga a revisar qué significa detectar un ataque. Una campaña capaz de generar miles de intentos por minuto puede producir numerosas señales, pero recibir una alerta sirve de poco si interpretarla, escalarla y responder requiere varias horas. Microsoft advierte precisamente de ese desequilibrio en su análisis de Storm-0940: el volumen de actividad puede hacer más visible al atacante, mientras que la rapidez con la que avanza reduce el margen disponible para detenerlo antes de que alcance el siguiente paso.
Son cuestiones que exceden la elección de una herramienta concreta. Afectan al conocimiento que una organización tiene de su infraestructura, a la velocidad con la que puede tomar decisiones y a la coordinación entre los equipos que deben ejecutarlas.
El «octubre negro» después del ruido
Los incidentes de octubre no prueban que Internet haya entrado en una etapa de ciberguerra autónoma, pero la evidencia disponible sí permite identificar un cambio concreto en la forma en que pueden desarrollarse determinadas operaciones ofensivas. Modelos avanzados han ayudado a descubrir vulnerabilidades extremadamente complejas, herramientas basadas en agentes han participado en ataques reales contra bancos, empresas y servicios cloud, y un solo operador ha podido dirigir campañas contra más de mil objetivos mientras los agentes continuaban trabajando durante horas. En otro caso, un grupo alineado con un Estado utilizó un sistema agéntico para acelerar operaciones contra cientos de organizaciones y alcanzar, en algunos entornos, privilegios elevados en menos de tres horas.
Ese cambio convive con problemas mucho más conocidos. Algunos de los incidentes más graves que han salido a la luz durante estas semanas siguen teniendo su origen en credenciales comprometidas, cadenas de suministro, sistemas heredados, claves mal generadas o software vulnerable. La inteligencia artificial no explica por sí sola el «octubre negro» , pero sí está reduciendo parte del coste y del tiempo que tradicionalmente separaban el descubrimiento de una debilidad de su explotación y a un atacante de su siguiente objetivo.
Para las empresas, la consecuencia está en la diferencia de velocidad. Las organizaciones continúan necesitando tiempo para identificar qué sistemas están afectados, probar correcciones, valorar su impacto, aprobar cambios y desplegarlos con garantías, mientras algunas tareas ofensivas pueden ejecutarse ya de forma simultánea y durante horas con una intervención humana mucho menor.
Ese desequilibrio ayuda a entender mejor lo ocurrido en octubre que la imagen de ejércitos de IA atacando Internet por su cuenta. El riesgo más inmediato está en que cada nueva vulnerabilidad pueda investigarse, probarse y escalarse con mayor rapidez, mientras la capacidad de respuesta de las organizaciones sigue dependiendo de procesos que no se han acelerado en la misma proporción.
