Praia Do Forte, Brasil - Nvidia, Google, Meta, IBM y Microsoft están apostando por modelos y herramientas de código abierto (Open Source) para acelerar el desarrollo de inteligencia artificial (IA), una estrategia que permite a otras empresas y usuarios utilizar su tecnología para crear aplicaciones sin desarrollar todos sus componentes desde cero. Sin embargo, esa colaboración tiene un reto: la creciente introducción de software malicioso en herramientas de las que dependen miles de proyectos.
Hackers infectan el código antes de crear apps y aprovechan una falla en la IA abierta que preocupa a Microsoft y Google
La firma de ciberseguridad Kaspersky identificó cerca de 19,500 paquetes maliciosos en proyectos de código abierto al cierre de 2025, un crecimiento de 37% respecto a 2024, cuando había detectado alrededor de 14,000, lo cual también coincide con el creciente valor de esta industria.
Según cifras de Research and Markets, el mercado global de modelos de inteligencia artificial de código abierto (open-source AI models) pasó de valer 19,050 millones de dólares en 2025 a 23,080 millones de dólares en 2026 y se estima que alcance los 50,030 millones de dólares para 2030, es decir, un ritmo anual compuesto de aproximadamente 21.3%.
Además, el riesgo llega en un momento en el que las empresas utilizan cada vez más bibliotecas y componentes desarrollados por terceros para construir productos de IA, pues estos recursos permiten reducir tiempos y costos, aunque elevan el riesgo de que el código incorporado no haya sido alterado por un atacante.
“Cuando haces la descarga de un software o haces la actualización, usted como usuario, solo usa el artefacto final”
El investigador también añadió durante el Cyber Security Week 2026 que detrás de ese producto existe una cadena de desarrollo que puede convertirse en objetivo de los delincuentes.
El interés de los atacantes está en los permisos que tienen los desarrolladores porque incluso sus equipos pueden almacenar accesos a repositorios privados, servicios en la nube, claves de programación y credenciales utilizadas para publicar nuevas versiones de software, explica Leite. En este caso, si un delincuente consigue apropiarse de esos accesos, puede distribuir componentes alterados bajo el nombre de un desarrollador legítimo y alcanzar a otras empresas que confían en sus herramientas.
La diferencia con otros ataques es que los criminales no necesitan engañar directamente al usuario final sino que, pueden comprometer las cuentas de quienes mantienen el programa, robar sus credenciales y publicar versiones maliciosas que otras personas descarguen como parte de su trabajo habitual.
Las tecnológicas apuestan por abrir sus modelos de IA
Una de las compañías que impulsa esta estrategia es Nvidia , que ha ampliado su familia Nemotron con modelos, conjuntos de datos y herramientas disponibles para que los desarrolladores construyan agentes de IA especializados.
En octubre de 2026, la empresa presentó Nemotron 3.5 Super VL, un modelo multimodal abierto orientado a tareas que combinan razonamiento, interpretación de documentos, imágenes y uso de herramientas. La compañía también promueve su integración con plataformas y bibliotecas de desarrollo abiertas.
Meta ha seguido una estrategia similar con Llama, una familia de modelos cuyos pesos pueden descargarse y adaptarse bajo condiciones de licencia específicas. Esto permite que empresas y desarrolladores construyan aplicaciones propias sin depender exclusivamente de un servicio cerrado.
Google también busca ampliar su presencia en este ecosistema, pues en abril lanzó Gemma 4 bajo la licencia Apache 2.0 y reportó que los modelos de la familia Gemma acumulaban más de 400 millones de descargas y habían dado lugar a más de 100,000 variantes creadas por desarrolladores.
La apuesta incluye a IBM, que distribuye Granite 4.0 para aplicaciones empresariales, y a Microsoft, que en marzo presentó Phi-4-reasoning-vision-15B, un modelo de pesos abiertos diseñado para tareas de razonamiento y análisis visual.
La expansión de estos modelos no significa que estén infectados desde su origen. El problema identificado por los investigadores aparece en los componentes externos, repositorios y procesos que las empresas utilizan para desarrollar y distribuir aplicaciones.
El problema puede extenderse de una organización a otra, ya que de acuerdo con Leite, cuando los atacantes comprometen las credenciales de quienes mantienen una biblioteca de software, pueden publicar una actualización maliciosa que otros desarrolladores incorporen a sus proyectos y si esa actualización también permite robar accesos, los delincuentes pueden repetir el procedimiento con nuevas herramientas y ampliar el alcance del ataque.
Leite ejemplificó este panorama con una campaña que comprometió herramientas utilizadas para revisar la seguridad del software y citó a Trivy, un programa de código abierto que permite detectar vulnerabilidades en aplicaciones y sistemas.
En marzo de 2026, atacantes modificaron componentes empleados por esta herramienta en procesos automatizados de desarrollo. De acuerdo con el Instituto SANS, la operación alcanzó 76 de las 77 etiquetas de versión de una de sus acciones de GitHub.
El ataque fue relevante porque las herramientas de seguridad suelen contar con permisos para examinar código, acceder a repositorios y analizar infraestructura, De esta forma, al comprometerlas, los delincuentes pueden intentar obtener información que normalmente estaría protegida. “Como es una herramienta de seguridad, ellos tienen el privilegio máximo”, explicó Leite.
Un ejemplo de esto ocurrió el 21 de octubre, cuando LiteLLM , una plataforma de código abierto que permite conectar aplicaciones con distintos modelos de inteligencia artificial, sufrió un ataque a su cadena de suministro de software.
De acuerdo con la investigación publicada por la compañía, los atacantes aprovecharon una clave administrativa que había quedado expuesta en un repositorio público meses antes y con ella consiguieron acceder a credenciales de desarrollo y modificar el proceso de publicación de una actualización, que terminó distribuyendo software malicioso diseñado para robar credenciales y facilitar la ejecución remota de código.
La versión comprometida estuvo disponible durante aproximadamente dos horas antes de ser retirada, lo que muestra cómo una herramienta utilizada por las empresas puede convertirse en una vía de acceso para los delincuentes si se comprometen sus mecanismos de distribución.
Por otra parte, Google Threat Intelligence identificó a TeamPCP, también conocido como UNC6780, como responsable de una serie de ataques contra componentes de código abierto entre febrero y mayo de 2026 donde sus investigadores observaron intentos de utilizar accesos obtenidos mediante software de IA comprometido para ingresar a otros entornos empresariales.
Esto muestra que el objetivo no siempre es alterar el funcionamiento de una aplicación. En ocasiones, los atacantes buscan las credenciales que permiten administrar sistemas, publicar nuevas versiones o acceder a información empresarial.
La IA puede acelerar el desarrollo, pero también la propagación del riesgo
Leite advirtió que los agentes de IA están cambiando la velocidad con la que se crean aplicaciones porque estas herramientas pueden escribir código, incorporar bibliotecas externas y realizar tareas de mantenimiento, lo que reduce el trabajo manual de los desarrolladores.
Sin embargo, el investigador señaló que un agente también podría incorporar una dependencia comprometida si no existen controles para verificar su procedencia.
“Ahora puedes desarrollar muy rápido, basta pedir a tu agente de AI hacer una aplicación”, explicó durante su presentación. El problema, añadió, es que estas herramientas pueden introducir paquetes que ya hayan sido alterados.
La advertencia coincide con el informe State of the Software Supply Chain 2026 , de Sonatype, donde la empresa identificó más de 454,600 nuevos paquetes maliciosos durante 2025 en los ecosistemas que monitorea, una medición más amplia y con metodología distinta de la utilizada por Kaspersky.
No obstante, el uso de IA no demuestra por sí mismo que una aplicación sea más vulnerable pero el riesgo depende de qué componentes incorpora, cómo se verifican y qué permisos tienen durante el desarrollo.
La propia Kaspersky reconoce que los proyectos de código abierto no son necesariamente menos seguros que las soluciones propietarias debido a que una comunidad activa puede revisar el código, identificar vulnerabilidades y corregirlas, mientras que en los sistemas cerrados estas tareas dependen principalmente de los equipos responsables del producto.
IBM ofrece un ejemplo de cómo las compañías intentan responder a este desafío al presentar Granite 4.0, destacó el uso de firmas criptográficas para verificar la autenticidad de sus modelos y facilitar su trazabilidad.
Microsoft y Nvidia publicaron en octubre de 2026 una guía conjunta para gestionar los riesgos de los modelos de pesos abiertos en entornos empresariales. Su planteamiento es que la seguridad no depende únicamente de sí un modelo es abierto o cerrado, sino de cómo se utiliza, qué sistemas puede consultar y qué controles existen alrededor de su implementación.
Además, las organizaciones deben adoptar una lógica de desarrollo defensivo: revisar las dependencias externas, controlar las versiones que utilizan y limitar la duración de las credenciales empleadas para publicar software. Para Leite, la respuesta requiere cambiar la manera en que las empresas desarrollan sus aplicaciones ya que, no basta con evitar errores en el código propio sino que también deben considerar que una biblioteca externa puede haber sido comprometida antes de incorporarla a un proyecto.