Cómo la IA acelera la búsqueda de vulnerabilidades

Publicidad · Contenido en colaboración con F5, con la intermediación de Fink & Fuchs. La redacción de SecurityToday ha preparado el texto a nivel formal.

El software moderno cambia cada vez más rápido, por lo que los procesos de revisión tradicionales ya no pueden detectar todas las posibles vulnerabilidades nuevas. La IA generativa analiza código fuente y en parte binarios y código compilado a gran escala en tiempo real, sin sustituir desarrollo seguro ni juicio humano. Los fabricantes deben integrar la búsqueda de vulnerabilidades con IA en un proceso de análisis, priorización, verificación, corrección y aportación de evidencias.

Relacionado: Triaje de vulnerabilidades: basarse solo en el CVSS conduce a decisiones equivocadas · Seguridad de las API: el punto ciego detrás de cada integración

La Agencia de la Unión Europea para la Ciberseguridad (ENISA) ha analizado en su Threat Landscape Report 2025 un total de 4.875 incidentes del periodo comprendido entre julio de 2024 y junio de 2025. Como vía de acceso importante para los atacantes señala la vulneración del software en la cadena de suministro digital mediante la explotación de vulnerabilidades descubiertas. Al mismo tiempo describe la inteligencia artificial como un factor que optimiza los ataques y que genera en las empresas nuevas superficies de ataque. Con ello aumenta la presión sobre la industria del software en dos puntos: debe detectar las vulnerabilidades antes en el proceso de desarrollo y convertir los errores conocidos, tras su evaluación, más rápidamente en medidas eficaces.

Por qué la revisión de software necesita hoy más contexto

Hoy en día las aplicaciones rara vez consisten en un único programa de dimensiones manejables. Combinan distintos lenguajes de programación, bibliotecas, sistemas operativos, archivos de configuración, API e interfaces de gestión. Una vulnerabilidad no se encuentra, por eso, siempre solo en una línea de código, sino también en una laguna al integrar varios módulos, en una configuración predeterminada insegura o en una cadena de suministro insuficientemente protegida. Los análisis clásicos, como las pruebas estáticas y dinámicas, el fuzzing, las revisiones de código, las comprobaciones de dependencias y los tests reproducibles, aportan cada uno resultados importantes. Sus límites están, sin embargo, sobre todo en el escalado y en el procesamiento del contexto. En bases de código grandes surgen muchos hallazgos que, aunque técnicamente plausibles, a menudo no son explotables en el contexto concreto de la aplicación. La verdadera tarea no consiste, por tanto, en «encontrar más vulnerabilidades», sino en «demostrar de forma fiable los hallazgos relevantes».

Qué pueden aportar los modelos de IA potentes

Los grandes modelos generativos de IA pueden reconocer relaciones entre archivos y módulos, marcar flujos de datos inusuales y formular a partir de un hallazgo una hipótesis verificable. En entornos de prueba adecuados apoyan además la creación de casos de test, el análisis de causas y la preparación de un parche. Eso resulta especialmente útil cuando hay que combinar conocimientos de seguridad, comprensión del código y evaluación de Threat Intelligence.

La tecnología tiene, sin embargo, límites sistemáticos. Los modelos pueden sobrevalorar hallazgos, interpretar mal el contexto o dar explicaciones que suenan convincentes pero no son reproducibles. En áreas críticas para la seguridad se suma otro riesgo: un informe sobre una vulnerabilidad hasta ahora desconocida debe protegerse para evitar que caiga en manos equivocadas. Derechos de acceso estrictos, registro trazable de actividades, entornos de prueba aislados y reglas claras para compartir los resultados forman parte, por tanto, del proceso de revisión, y no solo de la reacción ante un incidente.

Ejemplo práctico: F5 combina el análisis con IA y la seguridad del producto

F5 muestra cómo puede ser en la práctica un enfoque así, con el uso sistemático de modelos de IA potentes para revisar su propio software. En el centro no está una única ejecución del modelo, sino una infraestructura que analiza de forma repetida la base de código, estructura los hallazgos, verifica los resultados y solo pasa a desarrollo los problemas confirmados. El caso es relevante para el sector de la seguridad porque el software de F5 se emplea en más del 80 por ciento de las empresas Global Fortune 500, a menudo en partes especialmente expuestas de la arquitectura de TI: en las transiciones entre usuarios y aplicaciones, entre agentes de IA y API, y en infraestructuras que controlan la disponibilidad y el acceso.

Los errores en tales componentes pueden tener un alcance mucho mayor que un problema aislado en una aplicación interna. En consecuencia, análisis, cobertura de pruebas y entrega deben pensarse en conjunto. De la experiencia adquirida al desarrollar el proceso de revisión se deducen tres lecciones generales: primero, la IA debe trabajar con el contexto real de la implementación, en lugar de valorar solo resúmenes o abstracciones. Segundo, cada hallazgo automatizado necesita una verificación antes de llegar a desarrollo como base para actuar. Tercero, el tratamiento seguro de los resultados forma parte de la seguridad del producto, porque un hallazgo válido contiene información sobre una posible vía de ataque.

Un proceso de revisión sólido consta de cinco etapas

De ahí se deduce, para los fabricantes de software, un proceso de revisión repetible. Combina análisis automatizado con verificaciones estrictas y evita así que una masa enorme de resultados de IA sin verificar llegue al proceso de desarrollo.

1. Contextualizar. Se definen las áreas relevantes de código fuente, las dependencias, las configuraciones, los artefactos de build y las condiciones de despliegue conocidas. Los datos sensibles permanecen en entornos controlados.
2. Analizar. Un análisis estático dirigido por IA busca flujos de datos de riesgo, secuencias sospechosas, lógica de autenticación defectuosa, criptografía insegura y problemas de seguridad de la memoria.
3. Priorizar. Los hallazgos se enriquecen con criterios técnicos como la explotabilidad, asignaciones CWE, valoraciones de gravedad y referencias a archivo y línea.
4. Verificar. Una segunda vía de revisión, por ejemplo otro modelo, un test reproducible, fuzzing o un análisis manual, separa los resultados sólidos de los falsos positivos. Un hallazgo solo se considera válido cuando puede verificarse su impacto real; entonces se remite para su corrección según la prioridad asignada.
5. Corregir y volver a probar. La corrección desarrollada se comprueba mediante una matriz de pruebas adecuada, se verifica que no introduzca regresiones y se asigna a un lanzamiento. Tras la entrega se comprueba además si la medida es eficaz en las configuraciones realmente soportadas.

Operadores y clientes deben cambiar sus ciclos de actualización

En comparación con los métodos de revisión convencionales, estos análisis con IA, más potentes, destapan más vulnerabilidades nuevas. Al mismo tiempo, las vulnerabilidades surgen cada vez más rápido en el desarrollo de software acelerado por la IA, y los atacantes las explotan también en plazos más cortos. Por esta evolución, clientes y operadores de software deben reajustar sus ciclos de actualización. Los parches trimestrales ya no bastan. Deben aplicarse al menos una vez al mes y, en aplicaciones críticas, incluso ad hoc.

Para que esto no cause interrupciones de producción, la protección debe garantizarse con seguridad en tiempo de ejecución. Una mayor frecuencia de correcciones no indica una calidad deficiente. Al contrario: demuestra una capacidad de análisis mejorada y un intervalo más corto entre la identificación del problema y la aplicación de una medida de protección. Aquí es decisivo que el fabricante muestre de forma transparente los posibles impactos de un exploit, así como las versiones soportadas, las rutas de actualización y los tests necesarios. Para que los parches se apliquen con la mayor fluidez posible en la propia infraestructura, las empresas deberían adoptar las siguientes medidas complementarias:

• Mantener el inventario al día. Eliminar aplicaciones, módulos, interfaces y configuraciones que ya no se usan, y preparar los componentes desplegados para actualizaciones periódicas.
• Planificar la capacidad de actualización: adaptar también los procesos de mantenimiento, rollback, alta disponibilidad y pruebas del propio entorno a las actualizaciones frecuentes.
• Utilizar la telemetría. Revisión constante de logs y alarmas que permitan detectar una explotación o una mala configuración antes de que haya parche disponible.
• Priorizar los riesgos. Analizar qué vulnerabilidad descubierta afecta a un componente expuesto, ya se está explotando o permite una elevación de privilegios de gran alcance.
• Considerar los avisos. Revisar la información del proveedor sobre el parche correspondiente, probar las correcciones y proteger la información relevante para la seguridad.

Estas son las principales lecciones para los fabricantes

Los modelos de IA actuales como Claude Mythos o GPT Cyber avanzan a una velocidad enorme. Ya detectan vulnerabilidades reales, muestran posibles exploits y ayudan a crear parches. Pueden analizar código compilado, identificar cadenas complejas de vulnerabilidades y generar Proof-of-Concepts sofisticados. Esto funciona no solo con código fuente, sino en algunos casos también con archivos binarios y código compilado. Para que los modelos apoyen eficazmente la revisión de software hay que tener en cuenta, en particular, los siguientes puntos:

• Demasiados falsos positivos sobrecargan los procesos de desarrollo. La IA tiende a señalar más posibles problemas de los necesarios, en lugar de pasar por alto alguno. Por eso hacen falta inversiones en procesos de verificación, automatización del triaje y bucles de retroalimentación. Solo así los desarrolladores reciben problemas de seguridad y errores reales que deben corregir con alta prioridad.
• Los modelos de IA son cada vez más rápidos y mejores. Cada nueva generación de modelos supone un enorme paso hacia un mayor rendimiento. Por eso las empresas deben revisar su código con los modelos más recientes, para mantener el ritmo de los atacantes, que también usan las últimas versiones.
• Los informes de vulnerabilidades generados deben protegerse estrictamente. Las nuevas vulnerabilidades son una invitación a atacar para los ciberdelincuentes. Por eso solo deben ponerse a disposición del personal autorizado o de modelos de IA con derechos de uso estrictos.

La velocidad necesita gobernanza

La situación de amenaza, sensiblemente agravada por la IA, exige revisiones continuas del software. La propia IA puede ayudar a examinar grandes bases de código más rápido y con más contexto. Pero su valor para la seguridad solo surge al integrarla en un proceso controlado: con reglas de acceso claras, verificación independiente, priorización basada en riesgos, tests reproducibles y vías de actualización fiables. Para los fabricantes de software crítico es, a la vez, una cuestión práctica de producto. Quien conecta análisis, desarrollo, gestión de lanzamientos y comunicación con clientes puede traducir los nuevos conocimientos más rápido en protección resiliente. Así, por ejemplo, F5 está pasando ahora su ritmo trimestral de lanzamientos a actualizaciones más frecuentes para todo el software. Para los clientes, a su vez, la capacidad de evaluar y aplicar con rapidez actualizaciones continuas se convierte en un componente central de su propia resiliencia.

Conclusión

La IA no hace que las vulnerabilidades sean automáticamente manejables. Más bien acelera el ritmo al que se encuentran y evalúan los errores, y al que pueden explotarse o también corregirse. Para proveedores y clientes de aplicaciones críticas, un proceso de actualización continuo, fluido y trazable se vuelve cada vez más importante.

¿Quiere saber más sobre F5 y sobre estrategias eficaces contra los ataques basados en IA? Le esperamos en nuestro estand 7A-531 durante la feria it-sa en Núremberg.

Preguntas frecuentes

Cada pregunta está cerrada. Con un toque se despliega la respuesta.

¿Por qué ya no basta la revisión clásica de software?

Las aplicaciones combinan hoy muchos lenguajes de programación, bibliotecas, configuraciones y API. El análisis estático y dinámico, el fuzzing y las revisiones de código chocan con límites de escala y de procesamiento del contexto en bases de código grandes. Muchos hallazgos no son explotables en el contexto concreto de la aplicación.

¿Cuándo se considera válido un hallazgo de la IA?

Solo cuando una segunda vía de verificación demuestra de forma trazable su impacto real. Puede ser otro modelo, una prueba reproducible, fuzzing o un análisis manual. Después, el hallazgo pasa a la corrección priorizada.

¿Con qué frecuencia deben aplicar parches los operadores?

Según F5, los parches trimestrales ya no son suficientes. Las actualizaciones deberían llegar al menos cada mes y, en aplicaciones críticas, de forma puntual cuando sea necesario. Mientras tanto, la seguridad en tiempo de ejecución protege la producción.

¿Por qué hay que proteger los informes de vulnerabilidades?

Un hallazgo válido describe una posible vía de ataque. Por eso, los derechos de acceso estrictos, el registro trazable, los entornos de prueba aislados y unas reglas claras para compartir resultados forman parte del proceso de revisión.

Selección editorial

RecomendadoTriage de vulnerabilidades: CVSS guía mal la priorizaciónRecomendadoSeguridad en APIs: el punto ciego detrás de cada integración

Más de la red MBF Media

Digital ChiefsLa CRA obliga a los fabricantes a notificar en 24 horasMyBusinessFutureFabricantes notifican a ENISA incidentes CRA antes que al CSIRTcloudmagazinSi la IA escribe el 80 % del código, ¿quién lo revisa?

Fuente de la imagen: Getty Images / 1169539468

Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.