IA generativa y desarrollo de software: ¿qué nuevos riesgos introduce en la cadena de suministro?

¿Cómo está cambiando la IA generativa el desarrollo de software?

La IA ya no se limita a completar líneas de código: progresivamente participa en decisiones sobre arquitectura, dependencias, configuración, pruebas, documentación y mantenimiento.

Los primeros asistentes funcionaban principalmente como herramientas de autocompletado. Hoy un desarrollador puede describir una funcionalidad mediante lenguaje natural y obtener archivos completos, pruebas, consultas, configuraciones y recomendaciones de paquetes.

Los agentes de desarrollo llevan esta automatización un paso más adelante. Pueden analizar un repositorio, modificar varios archivos, ejecutar herramientas y proponer cambios sobre una aplicación.

Esto cambia la escala del desarrollo.

Un equipo puede producir y modificar software a una velocidad mucho mayor, pero esa aceleración también incrementa la cantidad de decisiones técnicas que deben ser confiables.

Y muchas de esas decisiones involucran componentes que la empresa no desarrolló.

La IA no elimina las dependencias open source: puede multiplicar su uso

Generar más código no significa depender menos del open source. En muchos casos significa seleccionar, instalar y actualizar componentes con mayor frecuencia.

Las aplicaciones modernas ya se construyen sobre frameworks, librerías, paquetes, APIs, imágenes de contenedores y otros componentes externos.

Cuando un asistente genera una funcionalidad, puede sugerir automáticamente paquetes para resolver autenticación, procesamiento de datos, interfaces, logging, conexión con bases de datos o prácticamente cualquier otra necesidad.

Esto crea una diferencia importante.

Antes, el desarrollador podía investigar manualmente una biblioteca, revisar su documentación y decidir qué versión incorporar. Ahora una parte de esa decisión puede comenzar con una recomendación generada automáticamente.

La velocidad con la que se crea código comienza a trasladarse también a la velocidad con la que se consumen dependencias.

Riesgo 1: la IA puede recomendar dependencias vulnerables o desactualizadas

Un modelo de lenguaje puede conocer cómo utilizar una biblioteca sin disponer necesariamente del contexto actualizado para determinar si una versión concreta sigue siendo segura.

Este punto es fundamental.

Los modelos se entrenan sobre grandes cantidades de información y pueden reconocer patrones extremadamente bien. Sin embargo, la situación de una dependencia cambia continuamente.

Una versión considerada adecuada en determinado momento puede descubrirse vulnerable después. Una biblioteca popular puede dejar de mantenerse. Puede existir una versión más reciente que resuelva problemas conocidos.

Por eso, saber escribir correctamente una llamada a una librería no equivale a saber si esa dependencia es actualmente la opción más segura para una organización.

La inteligencia sobre vulnerabilidades, malware, versiones, compatibilidad y políticas empresariales necesita mantenerse actualizada.

Riesgo 2: las alucinaciones pueden llegar al gestor de paquetes

Una recomendación incorrecta de IA puede convertirse en un riesgo real cuando el desarrollador intenta instalar un paquete o una versión que el modelo asumió que existía.

Las alucinaciones de los modelos no son solamente un problema de respuestas incorrectas en un chatbot.

En desarrollo de software pueden tener consecuencias operativas.

Por ejemplo, un asistente podría recomendar un nombre de paquete plausible pero inexistente. Si un atacante registra posteriormente ese nombre en un repositorio público, puede intentar aprovechar la confianza del desarrollador o de una automatización que intente instalarlo.

También pueden existir recomendaciones sobre versiones inexistentes o rutas de actualización que no corresponden con la realidad del ecosistema.

Por eso, una recomendación generada por IA debería contrastarse contra fuentes de inteligencia y registros reales antes de convertirse en una dependencia de producción.

Riesgo 3: más código generado puede significar más riesgo generado

La IA permite producir software a una escala mayor, por lo que una decisión insegura también puede replicarse con mayor rapidez.

Supongamos que un patrón inseguro es copiado manualmente por un desarrollador en una aplicación. El problema existe, pero tiene una escala determinada.

Ahora imaginemos que un asistente utiliza ese mismo patrón para generar decenas de servicios, archivos o proyectos.

La automatización funciona en ambas direcciones.

Puede multiplicar productividad, pero también puede multiplicar errores.

Esto significa que la seguridad necesita acercarse al momento en que la IA está tomando decisiones, en lugar de depender exclusivamente de controles que ocurren después de generar grandes cantidades de código.

Riesgo 4: la software supply chain ahora incluye nuevos tipos de activos

La cadena de suministro de una aplicación basada en IA puede incluir modelos, datasets, agentes, bases vectoriales, frameworks de orquestación y servicios externos además de las dependencias tradicionales.

Esta expansión cambia lo que una organización necesita inventariar y gobernar.

La pregunta de seguridad deja entonces de ser únicamente “¿qué librerías contiene nuestra aplicación?”.

Ahora también necesitamos preguntarnos qué modelos, fuentes de datos, herramientas y agentes participaron en la construcción o funcionamiento del software.

Cómo la IA amplía la cadena de suministro de software

La principal transformación puede visualizarse como una expansión de los puntos desde los cuales código, componentes y decisiones llegan a producción.

Riesgo 5: los modelos de IA también son dependencias

Cuando una aplicación depende de un modelo externo para funcionar, ese modelo pasa a formar parte de su cadena de suministro.

Esto resulta especialmente importante con el crecimiento de repositorios y ecosistemas donde las organizaciones pueden descargar modelos previamente entrenados.

Desde la perspectiva del desarrollador, incorporar un modelo puede parecer similar a incorporar cualquier otro componente: encontrar uno adecuado, descargarlo, integrarlo y utilizarlo.

Desde la perspectiva de seguridad, sin embargo, aparecen nuevas preguntas.

¿Quién publicó el modelo? ¿Qué versión se está utilizando? ¿Cuál es su procedencia? ¿Ha sido modificado? ¿Existe trazabilidad sobre el artefacto? ¿Qué dependencias adicionales requiere?

El mismo principio utilizado durante años para gobernar componentes open source comienza así a extenderse al ecosistema de IA: no basta con que un componente funcione; también es necesario conocer qué estamos incorporando y de dónde proviene.

¿Por qué revisar el código al final del pipeline puede ser demasiado tarde?

Cuanto más tarde se descubre una dependencia problemática, mayor puede ser el trabajo necesario para reemplazarla.

Supongamos que un asistente recomienda una biblioteca y el equipo comienza a construir varias funcionalidades alrededor de ella.

Si el problema se detecta inmediatamente, elegir otra versión o componente puede ser relativamente sencillo.

Si se descubre semanas después, la dependencia puede haberse extendido por diferentes módulos, pruebas e integraciones.

La remediación deja entonces de ser una decisión sobre un paquete y se convierte en retrabajo.

Por esta razón, la seguridad de la software supply chain está avanzando hacia controles cada vez más cercanos al momento de selección de componentes.

La idea es simple: evitar una dependencia riesgosa suele ser más eficiente que encontrarla cuando ya está integrada.

De Shift Left a seguridad en el momento de la decisión

La IA está empujando la seguridad más allá del concepto tradicional de Shift Left: el objetivo comienza a ser intervenir mientras se genera código y se seleccionan dependencias.

Durante años, Shift Left significó mover controles de seguridad hacia etapas más tempranas del SDLC.

Con asistentes y agentes, existe una oportunidad todavía anterior.

Si la herramienta puede consultar información actualizada antes de recomendar una dependencia, es posible influir sobre la decisión antes de que el componente entre al proyecto.

Esto cambia la lógica de seguridad.

En lugar de:

Seleccionar → incorporar → escanear → encontrar problema → corregir

el objetivo pasa a ser:

Consultar → evaluar → seleccionar componente adecuado → incorporar

El resultado potencial es menos retrabajo y menor cantidad de riesgo entrando al pipeline.

La IA necesita contexto de seguridad en tiempo real

Un modelo puede ser excelente generando código y seguir necesitando fuentes externas para conocer el estado actual de una dependencia.

Esto se debe a que la información necesaria para una decisión de seguridad cambia continuamente.

Nuevas vulnerabilidades aparecen. Se publican versiones. Los paquetes pueden comprometerse. Cambian las políticas de una empresa. Una versión puede ser técnicamente válida y, al mismo tiempo, estar prohibida por una política interna.

Por eso, la calidad del modelo no sustituye a la inteligencia actualizada sobre componentes.

El desarrollo asistido por IA necesita combinar dos capacidades diferentes:

• la capacidad del modelo para comprender contexto y generar soluciones;
• fuentes confiables y actualizadas que permitan validar las decisiones relacionadas con la cadena de suministro.

¿Qué controles necesita una software supply chain impulsada por IA?

Las organizaciones necesitan extender sus controles existentes hacia los nuevos puntos donde la IA selecciona, modifica o incorpora componentes.

Una estrategia práctica puede incluir varios niveles de control.

La clave está en evitar dos extremos: permitir que la IA incorpore cualquier elemento sin controles o construir un proceso tan rígido que elimine el beneficio de velocidad que motivó su adopción.

¿Qué cambia para DevSecOps?

DevSecOps necesita evolucionar desde revisar únicamente lo que los desarrolladores construyen hacia gobernar también las decisiones que realizan herramientas y agentes de IA.

Esto no implica crear un pipeline completamente diferente.

Muchas prácticas existentes continúan siendo útiles: análisis de componentes, políticas, repositorios controlados, SBOM, protección del pipeline y automatización.

Lo que cambia es el alcance.

Los equipos necesitan preguntarse si esas mismas políticas alcanzan a un desarrollador cuando utiliza un asistente para agregar una dependencia, si un agente puede evitar los controles existentes o si un modelo externo está siendo incorporado sin el mismo nivel de trazabilidad exigido a otros artefactos.

DevSecOps pasa así de asegurar un pipeline a asegurar un ecosistema de decisiones humanas y automatizadas.

¿Cómo encaja Sonatype en el desarrollo asistido por IA?

El enfoque de Sonatype apunta a proporcionar inteligencia actualizada sobre componentes dentro del mismo flujo donde desarrolladores y herramientas de IA toman decisiones sobre dependencias.

Esta dirección resulta especialmente relevante porque un asistente de código puede comprender perfectamente cómo utilizar un paquete sin saber necesariamente si una versión concreta presenta vulnerabilidades conocidas, problemas de calidad o riesgos adicionales.

Sonatype Guide extiende inteligencia sobre componentes hacia asistentes y entornos compatibles con MCP, permitiendo consultar información relacionada con dependencias, vulnerabilidades y versiones durante el desarrollo.

Esto introduce una capa de contexto entre la capacidad generativa del modelo y el ecosistema real de componentes.

La idea no consiste en reemplazar al asistente de IA, sino en complementarlo con información que el modelo por sí mismo no necesariamente posee en tiempo real.

Dentro de una estrategia más amplia, estos controles pueden complementarse con gestión de repositorios, análisis de componentes, políticas y protección de la cadena de suministro para evitar que decisiones inseguras avancen hacia producción.

Cómo empezar a gobernar el desarrollo de software con IA

Las empresas no necesitan esperar a tener agentes completamente autónomos para comenzar a establecer controles sobre su software supply chain de IA.

El primer paso puede ser simplemente obtener visibilidad.

¿Qué herramientas de IA utilizan los desarrolladores? ¿Qué repositorios consultan? ¿Pueden instalar dependencias? ¿Qué modelos externos consume la organización? ¿Qué herramientas están conectadas mediante MCP?

Después puede analizarse dónde existen decisiones sin validación.

Por ejemplo, si un asistente puede sugerir cualquier dependencia y la primera comprobación ocurre en CI/CD, existe una oportunidad para mover la inteligencia hacia el momento de selección.

También conviene establecer políticas claras sobre componentes, herramientas autorizadas, modelos, accesos y excepciones.

El objetivo no es detener la adopción de IA.

Es construir las condiciones necesarias para utilizarla a escala sin perder visibilidad sobre lo que entra en el software.

Conclusión: la IA acelera el desarrollo y también amplía lo que debemos proteger

La IA generativa no sustituye la software supply chain tradicional: la hace más rápida, automatizada y extensa.

Los riesgos conocidos de componentes open source continúan existiendo. Las aplicaciones siguen dependiendo de paquetes, frameworks, contenedores y servicios externos.

La diferencia es que ahora asistentes y agentes pueden participar directamente en la selección y modificación de esos elementos.

Al mismo tiempo aparecen nuevos activos: modelos, datasets, agentes, bases vectoriales, servicios de IA y conexiones MCP.

Esto obliga a evolucionar la estrategia de seguridad.

Escanear una aplicación antes de producción continúa siendo importante, pero puede no ser suficiente cuando las decisiones se producen automáticamente y a una velocidad mucho mayor.

Las organizaciones necesitan combinar la productividad de la IA con inteligencia actualizada, políticas automatizadas, trazabilidad y controles que acompañen al software desde el momento en que se selecciona una dependencia hasta que llega a producción.

El desafío de los próximos años no será elegir entre velocidad y seguridad. Será conseguir que los controles de la software supply chain puedan operar a la misma velocidad que el desarrollo impulsado por IA.