código abierto
Antes, solo las empresas de software especializadas y los gigantes tecnológicos tenían preocupaciones por las vulnerabilidades del código abierto y los ataques a la cadena de suministro. Pero los tiempos han cambiado. Hoy en día, incluso las pequeñas 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 se dedican a escribir código, 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ás complicado solucionar que simplemente instalar la última actualización de Windows.
El desarrollo de software moderno es inseparable de los componentes de código abierto. Sin embargo, los riesgos asociados se han multiplicado en los últimos años, aumentando tanto en variedad como en complejidad. Estamos observando cómo se inyecta código malicioso en repositorios populares, datos sobre vulnerabilidades fragmentados y erróneos, el uso sistemático de componentes obsoletos y vulnerables, y cadenas de dependencias cada vez más complejas.
La escasez de datos sobre vulnerabilidades en el código abierto
Aunque tu organización cuente con un proceso de gestión de vulnerabilidades sólido para el software comercial de terceros, te darás cuenta de que el código abierto requiere una revisión completa de dicho proceso. Las bases de datos públicas más utilizadas suelen ser incompletas, inexactas o, sencillamente, lentas al recibir actualizaciones en lo que respecta al código abierto. Esto convierte la priorización de vulnerabilidades en un juego de adivinanzas. Ningún grado de automatización te ayudará si tus datos de referencia están llenos de brechas.
Según las cifras de Sonatype, alrededor del 65 % de las vulnerabilidades de código abierto a las que se ha asignado un ID CVE carecen de una puntuación de gravedad (CVSS) en la NVD, la base de datos de vulnerabilidades más utilizada. De esas vulnerabilidades sin puntuar, casi el 46 % se clasificaría en realidad como Alta si se analizara adecuadamente.
Incluso cuando se dispone de una puntuación CVSS, las diferentes fuentes solo coinciden en la gravedad en aproximadamente el 55 % de los casos. Una base de datos puede marcar una vulnerabilidad como Crítica, mientras que otra le asigna una puntuación Media. Los metadatos más detallados, como las versiones de los paquetes afectados, suelen estar plagados de errores e incoherencias. Tus escáneres 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á en orden.
El déficit de datos sobre vulnerabilidades va en aumento y el proceso de notificación se está ralentizando. En los últimos cinco años, el número total de CVE se ha duplicado, pero el número de CVE sin puntuación de gravedad se ha multiplicado por 37. Según Tenable, en 2025, el código de explotación de prueba de concepto (PoC) público solía estar disponible en el plazo de una semana tras el descubrimiento de una vulnerabilidad, pero conseguir que esa misma vulnerabilidad se incluyera en el NVD llevaba una media de 15 días.
Los procesos de enriquecimiento, como la asignación de una puntuación CVSS, son aún más lentos. Sonatype, en el mismo estudio, estima que el tiempo medio para asignar una puntuación CVSS es de 41 días, y que algunos defectos permanecen sin clasificar hasta un año.
El problema del código fuente abierto heredado
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 útil (EOL), pueden encontrarse en entre el 5 % y el 15 % de los proyectos corporativos, según HeroDevs. En cinco registros de código abierto muy populares, hay al menos 81 000 paquetes que contienen vulnerabilidades conocidas, pero que pertenecen a versiones obsoletas y sin soporte técnico. Estos paquetes nunca tendrán parches oficiales. Esta “carga heredada” representa alrededor del 10 % de los paquetes en Maven Central y PyPI, y un asombroso 25 % en npm.
El uso de este tipo de código de código abierto rompe el ciclo de vida estándar de la gestión de parches: no es posible actualizar, ni de forma automática ni manual, una dependencia que ya no cuenta con soporte técnico. Además, cuando las versiones EOL no se incluyen en los boletines oficiales de vulnerabilidades, los escáneres de seguridad pueden clasificarlas como “no afectadas” por un fallo y pasarlas por alto.
Un ejemplo claro de esto es Log4Shell, la vulnerabilidad crítica (CVSS 10) de la popular biblioteca Log4j descubierta en 2021. La versión vulnerable representó 40 millones de las 300 millones de descargas de Log4j realizadas en 2025. Hay que tener en cuenta que estamos hablando de una de las vulnerabilidades más 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ón de los defectos menos publicitados es significativamente peor.
A este problema se suma la falta de visibilidad. Muchas organizaciones carecen de las herramientas necesarias para trazar un árbol de dependencias completo u obtener una visibilidad total de los paquetes y versiones específicos 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.
Malware en registros de código abierto
Los ataques que involucran paquetes de código abierto infectados o intrínsecamente maliciosos se han convertido en una de las amenazas de más rápido crecimiento para la cadena de suministro de software. Según los investigadores de Kaspersky, a finales de 2024 se habían detectado aproximadamente 14 000 paquetes maliciosos en los registros más populares, lo que supone un aumento interanual del 48 %. Sonatype informó de un aumento aún más espectacular a lo largo de 2025, con la detección de más de 450 000 paquetes maliciosos.
Los motivos detrás de estos ataques son muy variados: el robo de criptomonedas, la recopilación de credenciales de desarrolladores, el espionaje industrial, la obtención de acceso a infraestructuras a través de procesos de CI/CD o el compromiso de servidores públicos para alojar campañas de spam y phishing. Estas tácticas son empleadas tanto por grupos APT de espionaje como por ciberdelincuentes con motivaciones económicas. Cada vez más, la vulneración de un paquete de código abierto es solo el primer paso de una intrusión corporativa en varias fases.
Entre los escenarios de ataque más comunes se incluyen la vulneración de las credenciales de un mantenedor legítimo de un paquete de código abierto, la publicación de una biblioteca “útil” con código malicioso incrustado o la publicación de una biblioteca maliciosa con un nombre casi idéntico 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áticos. El ejemplo más notorio es la campaña Shai-Hulud. En este caso, el código malicioso robó tokens de GitHub y npm y siguió infectando nuevos paquetes, hasta extenderse finalmente a más de 700 paquetes de npm y decenas de miles de repositorios. En el proceso, filtró secretos de CI/CD y claves de acceso a la nube al dominio público.
Aunque este escenario técnicamente no está relacionado con vulnerabilidades, las herramientas y políticas de seguridad necesarias para gestionarlo son las mismas que se utilizan para la gestión de vulnerabilidades.
Cómo los agentes de IA aumentan los riesgos relacionados con el uso del código fuente abierto
La integración apresurada y omnipresente de agentes de IA en el desarrollo de software aumenta significativamente la velocidad de los desarrolladores, pero también amplifica cualquier error. Sin una supervisión rigurosa y sin medidas de protección claramente definidas, el código generado por IA es extremadamente vulnerable.
Las investigaciones revelan que el 45 % del código generado por IA contiene fallos incluidos en la lista OWASP Top 10, mientras que el 20 % de las aplicaciones basadas en IA implementadas contienen peligrosos errores de configuración.
Esto sucede porque los modelos de IA se entrenan con conjuntos de datos masivos que incluyen grandes volúmenes de código obsoleto, de demostración o puramente educativo.
Estos problemas sistémicos resurgen cuando un modelo de IA decide qué componentes de código abierto incluir en un proyecto. A menudo, el modelo desconoce qué versiones de los paquetes existen actualmente o cuáles han sido señaladas como vulnerables. En su lugar, sugiere una versión de dependencia extraída 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ón de dependencias.
En 2025, incluso los principales LLM recomendaron versiones incorrectas de las dependencias, simplemente inventando una respuesta, en el 27 % de los casos.
¿Puede la IA arreglar todo?
Es una idea sencilla y tentadora: basta con aplicar un agente de IA a tu código fuente y dejar que detecte y corrija todas las vulnerabilidades. Desafortunadamente, la IA no puede resolver este problema por completo. Los obstáculos 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íble de recursos y requiere conocimientos especializados que siguen estando fuera del alcance de la mayoría de las empresas.
Además, si se descubre una vulnerabilidad en un componente obsoleto o sin soporte, un agente de IA no puede “corregirla automáticamente”. Sigues enfrentándote a la necesidad de desarrollar parches personalizados o llevar a cabo una migración compleja. Si un fallo está oculto en lo más profundo de una cadena de dependencias, es probable que la IA lo pase por alto por completo.
¿Qué se debe hacer?
Para minimizar los riesgos descritos anteriormente, será necesario ampliar el proceso de gestión de vulnerabilidades para incluir políticas de descarga de paquetes de código abierto, normas de funcionamiento de los asistentes de IA y el proceso de compilación de software. Esto incluye lo siguiente:
- Utilizar una solución integral de seguridad para cargas de trabajo en la nube.
- Comprobar los paquetes de código abierto que se utilizan en tu proceso de desarrollo de software con fuentes de inteligencia sobre amenazas para componentes de código abierto.
- Considerar medidas de seguridad para proteger el código de IA y los agentes de IA.
- Eliminar sistemáticamente los componentes de código abierto obsoletos.
Puedes leer más sobre la gestión de vulnerabilidades en el código abierto en una publicación de blog dedicada a este tema.
