{"id":32017,"date":"2026-04-14T17:17:09","date_gmt":"2026-04-14T15:17:09","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=32017"},"modified":"2026-04-14T17:17:09","modified_gmt":"2026-04-14T15:17:09","slug":"open-source-vulnerabilities-in-ai-era","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/open-source-vulnerabilities-in-ai-era\/32017\/","title":{"rendered":"Vulnerabilidades de c\u00f3digo abierto: ahora un problema para todas las empresas"},"content":{"rendered":"

Antes, solo las empresas de software especializadas y los gigantes tecnol\u00f3gicos ten\u00edan preocupaciones por las vulnerabilidades del c\u00f3digo abierto y los ataques a la cadena de suministro. Pero los tiempos han cambiado. Hoy en d\u00eda, incluso las peque\u00f1as empresas cuentan con sus propios equipos de desarrollo, lo que hace que el problema afecte a todo el mundo. Los equipos de TI internos de una de cada dos empresas<\/a> se dedican a escribir c\u00f3digo, configurar integraciones y automatizar flujos de trabajo, incluso aunque su actividad principal no tenga absolutamente nada que ver con el software. Es lo que exige la eficiencia empresarial moderna. Sin embargo, el resultado de ello es una nueva clase de vulnerabilidades de software, del tipo que resulta mucho m\u00e1s complicado solucionar que simplemente instalar la \u00faltima actualizaci\u00f3n de Windows.<\/p>\n

El desarrollo de software moderno es inseparable de los componentes de c\u00f3digo abierto. Sin embargo, los riesgos asociados se han multiplicado en los \u00faltimos a\u00f1os, aumentando tanto en variedad como en complejidad. Estamos observando c\u00f3mo se inyecta c\u00f3digo malicioso en repositorios populares, datos sobre vulnerabilidades fragmentados y err\u00f3neos, el uso sistem\u00e1tico de componentes obsoletos y vulnerables, y cadenas de dependencias cada vez m\u00e1s complejas.<\/p>\n

La escasez de datos sobre vulnerabilidades en el c\u00f3digo abierto<\/h2>\n

Aunque tu organizaci\u00f3n cuente con un proceso de gesti\u00f3n de vulnerabilidades<\/a> s\u00f3lido para el software comercial de terceros, te dar\u00e1s cuenta de que el c\u00f3digo abierto requiere una revisi\u00f3n completa de dicho proceso. Las bases de datos p\u00fablicas m\u00e1s utilizadas suelen ser incompletas, inexactas o, sencillamente, lentas al recibir actualizaciones en lo que respecta al c\u00f3digo abierto. Esto convierte la priorizaci\u00f3n de vulnerabilidades en un juego de adivinanzas. Ning\u00fan grado de automatizaci\u00f3n te ayudar\u00e1 si tus datos de referencia est\u00e1n llenos de brechas.<\/p>\n

Seg\u00fan las cifras de Sonatype, alrededor del 65\u00a0% de las vulnerabilidades de c\u00f3digo abierto<\/a> a las que se ha asignado un ID CVE carecen de una puntuaci\u00f3n de gravedad<\/a> (CVSS) en la NVD, la base de datos de vulnerabilidades m\u00e1s utilizada. De esas vulnerabilidades sin puntuar, casi el 46\u00a0% se clasificar\u00eda en realidad como Alta si se analizara adecuadamente.<\/p>\n

Incluso cuando se dispone de una puntuaci\u00f3n CVSS, las diferentes fuentes solo coinciden en la gravedad en aproximadamente el 55\u00a0% de los casos. Una base de datos puede marcar una vulnerabilidad como Cr\u00edtica, mientras que otra le asigna una puntuaci\u00f3n Media. Los metadatos m\u00e1s detallados, como las versiones de los paquetes afectados, suelen estar plagados de errores e incoherencias. Tus esc\u00e1neres de vulnerabilidades que comparan versiones de software acaban dando falsas alarmas con falsos positivos o, por el contrario, dando un falso informe de que todo est\u00e1 en orden.<\/p>\n

El d\u00e9ficit de datos sobre vulnerabilidades va en aumento y el proceso de notificaci\u00f3n se est\u00e1 ralentizando. En los \u00faltimos cinco a\u00f1os, el n\u00famero total de CVE se ha duplicado, pero el n\u00famero de CVE sin puntuaci\u00f3n de gravedad se ha multiplicado por 37. Seg\u00fan Tenable, en 2025, el c\u00f3digo de explotaci\u00f3n de prueba de concepto (PoC) p\u00fablico sol\u00eda estar disponible en el plazo de una semana<\/a> tras el descubrimiento de una vulnerabilidad, pero conseguir que esa misma vulnerabilidad se incluyera en el NVD llevaba una media de 15 d\u00edas.
\nLos procesos de enriquecimiento, como la asignaci\u00f3n de una puntuaci\u00f3n CVSS, son a\u00fan m\u00e1s lentos. Sonatype, en el mismo estudio<\/a>, estima que el tiempo medio para asignar una puntuaci\u00f3n CVSS es de 41 d\u00edas, y que algunos defectos permanecen sin clasificar hasta un a\u00f1o.<\/p>\n

El problema del c\u00f3digo fuente abierto heredado<\/h2>\n

Las bibliotecas, aplicaciones y servicios que ya no reciben mantenimiento, ya sea porque se han abandonado o porque hace tiempo que han alcanzado su fin de vida \u00fatil (EOL), pueden encontrarse en entre el 5\u00a0% y el 15\u00a0% de los proyectos corporativos<\/a>, seg\u00fan HeroDevs. En cinco registros de c\u00f3digo abierto muy populares, hay al menos 81\u00a0000 paquetes que contienen vulnerabilidades conocidas, pero que pertenecen a versiones obsoletas y sin soporte t\u00e9cnico. Estos paquetes nunca tendr\u00e1n parches oficiales. Esta \u201ccarga heredada\u201d representa alrededor del 10\u00a0% de los paquetes en Maven Central y PyPI, y un asombroso 25\u00a0% en npm.<\/p>\n

El uso de este tipo de c\u00f3digo de c\u00f3digo abierto rompe el ciclo de vida est\u00e1ndar de la gesti\u00f3n de parches: no es posible actualizar, ni de forma autom\u00e1tica ni manual, una dependencia que ya no cuenta con soporte t\u00e9cnico. Adem\u00e1s, cuando las versiones EOL no se incluyen en los boletines oficiales de vulnerabilidades, los esc\u00e1neres de seguridad pueden clasificarlas como \u201cno afectadas\u201d por un fallo y pasarlas por alto.<\/p>\n

Un ejemplo claro de esto es Log4Shell<\/a>, la vulnerabilidad cr\u00edtica (CVSS 10) de la popular biblioteca Log4j descubierta en 2021. La versi\u00f3n vulnerable represent\u00f3 40\u00a0millones<\/a> de las 300\u00a0millones de descargas de Log4j realizadas en 2025. Hay que tener en cuenta que estamos hablando de una de las vulnerabilidades m\u00e1s infames y ampliamente difundidas de la historia, una que fue aprovechada activamente, parcheada por el desarrollador y solucionada en todos los principales productos derivados. La situaci\u00f3n de los defectos menos publicitados es significativamente peor.<\/p>\n

A este problema se suma la falta de visibilidad. Muchas organizaciones carecen de las herramientas necesarias para trazar un \u00e1rbol de dependencias completo u obtener una visibilidad total de los paquetes y versiones espec\u00edficos integrados en su stack de software. Como consecuencia, estos componentes obsoletos suelen pasar desapercibidos y ni siquiera llegan a incluirse en la lista de correcciones pendientes.<\/p>\n

Malware en registros de c\u00f3digo abierto<\/h2>\n

Los ataques que involucran paquetes de c\u00f3digo abierto infectados o intr\u00ednsecamente maliciosos se han convertido en una de las amenazas de m\u00e1s r\u00e1pido crecimiento para la cadena de suministro de software. Seg\u00fan los investigadores de Kaspersky<\/a>, a finales de 2024 se hab\u00edan detectado aproximadamente 14\u00a0000 paquetes maliciosos en los registros m\u00e1s populares, lo que supone un aumento interanual del 48\u00a0%. Sonatype inform\u00f3 de un aumento a\u00fan m\u00e1s espectacular a lo largo de 2025, con la detecci\u00f3n de m\u00e1s de 450\u00a0000 paquetes maliciosos.<\/p>\n

Los motivos detr\u00e1s de estos ataques son muy variados: el robo de criptomonedas, la recopilaci\u00f3n de credenciales de desarrolladores, el espionaje industrial, la obtenci\u00f3n de acceso a infraestructuras a trav\u00e9s de procesos de CI\/CD o el compromiso de servidores p\u00fablicos para alojar campa\u00f1as de spam y phishing. Estas t\u00e1cticas son empleadas tanto por grupos APT de espionaje<\/a> como por ciberdelincuentes con motivaciones econ\u00f3micas<\/a>. Cada vez m\u00e1s, la vulneraci\u00f3n de un paquete de c\u00f3digo abierto es solo el primer paso de una intrusi\u00f3n corporativa en varias fases.<\/p>\n

Entre los escenarios de ataque m\u00e1s comunes se incluyen la vulneraci\u00f3n de las credenciales de un mantenedor leg\u00edtimo de un paquete de c\u00f3digo abierto, la publicaci\u00f3n de una biblioteca \u201c\u00fatil\u201d con c\u00f3digo malicioso incrustado o la publicaci\u00f3n de una biblioteca maliciosa con un nombre casi id\u00e9ntico al de una popular. Una tendencia especialmente preocupante en 2025 ha sido el aumento de los ataques automatizados similares a los de los gusanos inform\u00e1ticos. El ejemplo m\u00e1s notorio es la campa\u00f1a Shai-Hulud<\/a>. En este caso, el c\u00f3digo malicioso rob\u00f3 tokens de GitHub y npm y sigui\u00f3 infectando nuevos paquetes, hasta extenderse finalmente a m\u00e1s de 700 paquetes de npm y decenas de miles de repositorios. En el proceso, filtr\u00f3 secretos de CI\/CD y claves de acceso a la nube al dominio p\u00fablico.<\/p>\n

Aunque este escenario t\u00e9cnicamente no est\u00e1 relacionado con vulnerabilidades, las herramientas y pol\u00edticas de seguridad necesarias para gestionarlo son las mismas que se utilizan para la gesti\u00f3n de vulnerabilidades.<\/p>\n

C\u00f3mo los agentes de IA aumentan los riesgos relacionados con el uso del c\u00f3digo fuente abierto<\/h2>\n

La integraci\u00f3n apresurada y omnipresente de agentes de IA en el desarrollo de software aumenta significativamente la velocidad de los desarrolladores, pero tambi\u00e9n amplifica cualquier error. Sin una supervisi\u00f3n rigurosa y sin medidas de protecci\u00f3n claramente definidas, el c\u00f3digo generado por IA es extremadamente vulnerable.<\/p>\n

Las investigaciones revelan que el 45\u00a0% del c\u00f3digo generado por IA contiene fallos incluidos en la lista OWASP Top 10<\/a>, mientras que el 20\u00a0% de las aplicaciones basadas en IA implementadas contienen peligrosos errores de configuraci\u00f3n.<\/p>\n

Esto sucede porque los modelos de IA se entrenan con conjuntos de datos masivos que incluyen grandes vol\u00famenes de c\u00f3digo obsoleto, de demostraci\u00f3n o puramente educativo.<\/p>\n

Estos problemas sist\u00e9micos resurgen cuando un modelo de IA decide qu\u00e9 componentes de c\u00f3digo abierto incluir en un proyecto. A menudo, el modelo desconoce qu\u00e9 versiones de los paquetes existen actualmente o cu\u00e1les han sido se\u00f1aladas como vulnerables. En su lugar, sugiere una versi\u00f3n de dependencia extra\u00edda de sus datos de entrenamiento, que es casi con toda seguridad obsoleta. En algunos casos, los modelos intentan llamar a versiones inexistentes o a bibliotecas totalmente inventadas. Esto abre la puerta a ataques de confusi\u00f3n de dependencias<\/a>.<\/p>\n

En 2025, incluso los principales LLM recomendaron versiones incorrectas de las dependencias, simplemente inventando una respuesta, en el 27\u00a0% de los casos<\/a>.<\/p>\n

\u00bfPuede la IA arreglar todo?<\/h2>\n

Es una idea sencilla y tentadora: basta con aplicar un agente de IA a tu c\u00f3digo fuente y dejar que detecte y corrija todas las vulnerabilidades. Desafortunadamente, la IA no puede resolver este problema por completo. Los obst\u00e1culos fundamentales que hemos comentado limitan a los agentes de IA tanto como a los desarrolladores humanos. Si faltan datos sobre vulnerabilidades o estos no son fiables, en lugar de encontrar vulnerabilidades conocidas, te ves obligado a redescubrirlas desde cero. Se trata de un proceso que consume una cantidad incre\u00edble de recursos y requiere conocimientos especializados que siguen estando fuera del alcance de la mayor\u00eda de las empresas.<\/p>\n

Adem\u00e1s, si se descubre una vulnerabilidad en un componente obsoleto o sin soporte, un agente de IA no puede \u201ccorregirla autom\u00e1ticamente\u201d. Sigues enfrent\u00e1ndote a la necesidad de desarrollar parches personalizados o llevar a cabo una migraci\u00f3n compleja. Si un fallo est\u00e1 oculto en lo m\u00e1s profundo de una cadena de dependencias, es probable que la IA lo pase por alto por completo.<\/p>\n

\u00bfQu\u00e9 se debe hacer?<\/h2>\n

Para minimizar los riesgos descritos anteriormente, ser\u00e1 necesario ampliar el proceso de gesti\u00f3n de vulnerabilidades para incluir pol\u00edticas de descarga de paquetes de c\u00f3digo abierto, normas de funcionamiento de los asistentes de IA y el proceso de compilaci\u00f3n de software. Esto incluye lo siguiente:<\/p>\n