Un agente de codificación puede resolver un error instalando una librería, cambiando un archivo de bloqueo (lockfile), actualizando una imagen base o ejecutando un comando en la terminal. La funcionalidad vuelve a funcionar, las pruebas pasan y el equipo continúa. Pero cada paquete añadido entra en la cadena de suministro del producto: código de terceros, dependencias transitivas, scripts de instalación, licencias, vulnerabilidades y comportamiento en la canalización (pipeline).

El riesgo no concierne solo a los paquetes vulnerables. Surge cuando el agente elige componentes y comandos para hacer funcionar rápidamente una funcionalidad sin evaluar la madurez, el mantenimiento, la licencia, el typosquatting, los archivos de bloqueo, los contenedores, el registro, los tokens, la SBOM y los controles de fusión (merge).

Para los ingenieros de DevOps, de seguridad y los CTO, la pregunta concreta antes de realizar el merge es: qué nuevas dependencias ha introducido la IA, por qué son necesarias, qué ejecutan, qué componentes transitivos traen, qué scripts lanzan, qué licencias tienen y cómo serán monitoreadas después del despliegue.

[Callforaction-WAPT]

Cuando la IA instala un paquete para resolver un error

El patrón es común: la compilación falla, falta un analizador, un SDK no está configurado, una prueba requiere un mock o un componente frontend necesita una utilidad. El asistente sugiere npm install, pip install, cargo add o go get, actualiza package.json, modifica requirements.txt, cambia un archivo de bloqueo o inserta una dependencia en el Dockerfile.

Este atajo puede ser correcto, pero debe revisarse como una modificación de seguridad. Una librería no es solo una función extra: puede ejecutar código en la fase de instalación, importar decenas de paquetes transitivos, tener una licencia incompatible, estar poco mantenida o introducir vulnerabilidades conocidas. La primera pregunta no es “¿el paquete funciona?”, sino “¿es realmente necesario?”. Si el proyecto ya tiene una librería equivalente, si el problema se resuelve con pocas líneas de código claro o si la dependencia entra solo para hacer pasar una prueba, el costo en términos de cadena de suministro puede superar el beneficio.

Dependency sprawl: el costo oculto del “vibe coding”

La proliferación de dependencias (dependency sprawl) significa acumular librerías porque cada una resuelve un pequeño problema local. Con los agentes de codificación de IA este fenómeno se acelera, porque el agente no siente el peso operativo de mantener los paquetes a lo largo del tiempo: instala, adapta el código y sigue adelante.

El costo llega después: actualizaciones de seguridad, incompatibilidad entre versiones, paquetes más grandes, compilaciones más lentas, licencias que gestionar, CVE que clasificar, dependencias transitivas que monitorear, contenedores más pesados, SBOM más compleja y una superficie de ataque más amplia. Una regla práctica ayuda: cada nueva dependencia debe tener una motivación, un propietario y una alternativa evaluada. Si nadie sabe por qué se añadió o qué riesgo introduce, no debería entrar en el merge solo porque la IA lo sugirió.

Typosquatting y paquetes casi homónimos

Los modelos pueden sugerir nombres plausibles que a veces corresponden al paquete correcto, otras veces a una alternativa poco conocida, un envoltorio (wrapper) no mantenido o un paquete creado para interceptar errores de escritura. El riesgo aumenta cuando el agente instala automáticamente sin que la elección pase por un control humano.

Antes de aceptar un paquete, es necesario verificar el registro, el repositorio oficial, los mantenedores, las versiones recientes, los problemas abiertos, el volumen de descargas, la firma o procedencia si está disponible, la documentación y la comunidad. No basta con que el nombre parezca familiar: en ecosistemas como npm y PyPI, diferencias mínimas en el nombre pueden llevar a paquetes completamente distintos. Para paquetes críticos, vale la pena evaluar también la cadena de mantenedores, porque un proyecto legítimo pero abandonado, adquirido o con versiones repentinas tras años de silencio requiere cautela tanto en el plano técnico como en el de la confianza en el mantenimiento.

Dependencias transitivas y archivos de bloqueo

El manifiesto muestra lo que el equipo ha declarado que quiere usar; el archivo de bloqueo muestra lo que realmente entrará en la compilación. Una sola dependencia puede traer decenas o cientos de paquetes transitivos, y una actualización automática puede cambiar versiones no previstas. Un archivo de bloqueo regenerado puede ocultar una superficie mucho más amplia que la diferencia visible en package.json.

El archivo de bloqueo debe revisarse junto con el manifiesto. Si la IA actualiza package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, uv.lock, Pipfile.lock, go.sum o Cargo.lock, el revisor debe entender qué ha cambiado: nuevos paquetes, actualizaciones mayores, scripts, fuentes de registro y árbol de dependencias. No es necesario leer cada línea manualmente, pero sí tener visibilidad sobre lo que ha entrado. Para reducir el ruido, conviene separar las actualizaciones intencionales de las funcionalidades: una PR que añade una funcionalidad y actualiza la mitad del archivo de bloqueo es difícil de validar, por lo que es preferible aislar la dependencia necesaria, bloquear las versiones y evitar latest.

Scripts de instalación y ganchos de ciclo de vida

Muchos gestores de paquetes permiten scripts en la fase de instalación o compilación: preinstall, install, postinstall, prepare, scripts de configuración, scripts de compilación, plugins y ganchos (hooks). Estos scripts pueden ejecutar código en los portátiles de los desarrolladores, en CI/CD o dentro de contenedores. Si la IA añade un paquete sin comprobar estos scripts, está autorizando de hecho a código de terceros a ejecutarse en el proceso de compilación.

La revisión debe buscar scripts nuevos o modificados en los manifiestos y en los paquetes añadidos. Un comando aparentemente inofensivo puede descargar binarios, generar código, leer variables de entorno, enviar telemetría o alterar archivos. En entornos de CI con tokens y secretos, un script de instalación malicioso puede tener un impacto serio. Cuando sea posible, es útil adoptar políticas que limiten la ejecución de scripts, compilaciones en entornos aislados (sandboxed), tokens con alcance mínimo y registros controlados.

Licencias y cumplimiento del código de terceros

La cadena de suministro no trata solo de vulnerabilidades. Una librería puede ser técnicamente segura y comercialmente problemática: licencias copyleft, restricciones de uso, obligaciones de atribución, incompatibilidad con la distribución propietaria o con las políticas del cliente pueden hacer que una dependencia sea inadecuada para el contexto.

Los agentes de IA no siempre consideran las restricciones de licencia. Si se pide añadir una librería para exportar PDF, el asistente puede elegir lo que conoce o lo que funciona, no necesariamente lo que es compatible con el modelo de negocio o con el contrato del cliente. Para empresas de software y productos B2B, cada nueva dependencia debería pasar por un escaneo de licencias o una lista de permitidos (allowlist). Las excepciones deben documentarse, porque en ausencia de políticas el riesgo emerge tarde: durante la diligencia debida, auditorías de clientes, adquisiciones empresariales o preparación para el lanzamiento.

Contenedores, imágenes base y paquetes de sistema

El riesgo en la cadena de suministro no se detiene en el código de la aplicación. Un agente puede modificar Dockerfiles, imágenes base, paquetes del SO, instaladores, scripts curl, repositorios apt, versiones de Node o Python, etapas de compilación y permisos en tiempo de ejecución. Puede usar latest, instalar herramientas innecesarias o dejar la aplicación ejecutándose como root.

Cada imagen debe tratarse como un componente del producto. Las prácticas recomendadas incluyen imágenes base mínimas y mantenidas, fijación de versiones, escaneo de contenedores, usuario no root donde sea posible, reducción de paquetes del SO, compilaciones multi-etapa limpias y ausencia de secretos en las capas. Si la IA añade un patrón del tipo curl | sh, es necesario detenerse y verificar la fuente, la firma, la suma de comprobación y la necesidad antes de proceder. Una compilación que pasa porque el contenedor instala “todo lo que hace falta” puede volverse difícil de parchear y monitorear con el tiempo.

Ecosistemas diferentes, señales diferentes

El control de la cadena de suministro cambia según la pila tecnológica. En Node.js el riesgo pasa a menudo por package.json, archivos de bloqueo, scripts npm, paquetes transitivos y paquetes frontend. En Python es necesario mirar requirements.txt, pyproject.toml, archivos de bloqueo, ruedas (wheels), dependencias nativas, índices privados y paquetes casi homónimos. En Go, go.mod y go.sum hacen más claro el gráfico de dependencias, pero aun así deben controlarse las rutas de los módulos, las directivas de reemplazo y las fuentes. En Rust, Cargo.toml y Cargo.lock muestran los crates y las funcionalidades habilitadas.

Un agente de IA puede conocer la sintaxis de todos estos ecosistemas, pero no conoce las políticas del equipo. Puede usar npm audit fix cambiando más versiones de las necesarias, instalar un paquete de Python no aprobado, añadir una funcionalidad de Cargo que trae código no previsto o modificar un Dockerfile para instalar librerías de sistema sin fijar versiones. Para cada ecosistema la regla es la misma: el manifiesto y el archivo de bloqueo deben leerse juntos, las fuentes de los paquetes deben ser conocidas y las actualizaciones automáticas deben estar separadas de las funcionalidades. Si el proyecto usa registros privados, es importante verificar también las alternativas y prioridades, porque una configuración errónea puede descargar un paquete público en lugar del interno.

Confusión de dependencias y registros privados

Las empresas que usan paquetes internos deben considerar el riesgo de confusión de dependencias (dependency confusion). Si un paquete privado tiene un nombre que puede existir también en un registro público, una configuración incorrecta del gestor de paquetes puede descargar el componente equivocado. Los agentes de IA pueden agravar el problema generando configuraciones de registro genéricas o eliminando ajustes porque “no son necesarios” para la compilación local.

Es necesario controlar los ámbitos (scopes) de npm, índices de Python, registros de Docker, GitHub Packages, GitLab Package Registry, proxies corporativos y espejos, verificando que los paquetes internos sean resueltos por el registro correcto, que los tokens tengan un alcance mínimo y que los registros (logs) no expongan credenciales. Si un agente modifica .npmrc, pip.conf, poetry config, el inicio de sesión de Docker o los flujos de trabajo de publicación, esa modificación debe tratarse como sensible. La prueba más sencilla es reproducir la compilación en un entorno limpio y observar de dónde se descargan los paquetes: una compilación que funciona en el portátil del desarrollador pero usa fuentes diferentes en CI no es gobernable.

Registros, tokens y credenciales de publicación

Cadena de suministro también significa quién puede descargar y publicar. Los tokens de npm, PyPI, GitHub Packages, registros de Docker, registros de paquetes privados y credenciales de CI/CD deben tener un alcance mínimo. Un agente con acceso a la terminal o a la canalización puede leer o usar tokens si el entorno no está adecuadamente separado.

Es necesario verificar dónde residen los tokens de registro, quién puede publicar, qué ramas activan lanzamientos, qué paquetes son privados, qué espacios de nombres están protegidos y qué registros pueden imprimir credenciales. Si la IA modifica flujos de trabajo de publicación o versiones, esa modificación es sensible y requiere revisión explícita. Para los paquetes internos, proteger la denominación y los espacios de nombres es fundamental: una importación ambigua o una configuración de registro incorrecta puede llevar a la confusión de dependencias, haciendo que el sistema de compilación descargue un paquete público en lugar del interno previsto.

SBOM, procedencia y trazabilidad

Si no se sabe qué ha entrado en la compilación, no es posible gestionarlo con el tiempo. Una Lista de Materiales de Software (SBOM) ayuda a enumerar componentes, versiones y dependencias. CycloneDX es un estándar consolidado para representar SBOM, mientras que OpenSSF SLSA proporciona un marco para razonar sobre la procedencia y la integridad de la compilación.

Para un MVP pequeño una SBOM puede parecer excesiva, pero para un producto que va a clientes, un SaaS con datos reales o una empresa de software que entrega código, se convierte en una herramienta práctica: cuando sale una CVE, cuando un cliente pide evidencias o cuando una dependencia se ve comprometida, saber qué está incluido en el lanzamiento reduce tiempos e incertidumbre. Los agentes de IA aumentan la necesidad de trazabilidad porque pueden añadir y cambiar componentes frecuentemente. Sin una SBOM o un inventario de dependencias, el equipo depende de la memoria de quien aceptó la diferencia (diff).

Escáneres automáticos: necesarios, no suficientes

SCA, escaneo de dependencias, escaneo de contenedores y escaneo de licencias son controles indispensables: interceptan vulnerabilidades conocidas, licencias problemáticas y versiones obsoletas. Sin embargo, no responden a todas las preguntas de seguridad relevantes.

Un escáner no evalúa si esa dependencia es realmente necesaria, si se eligió por error un paquete casi homónimo, si un script postinstall es coherente con la política de la empresa, si el archivo de bloqueo se regeneró sin motivo, si una licencia es aceptable para ese cliente o si la compilación descarga código de forma no reproducible. Por esto, la revisión de la cadena de suministro debe combinar herramientas automáticas y juicio humano: el escáner da señales, pero la decisión de merge requiere contexto.

Monitoreo después del merge

La cadena de suministro no se cierra con el merge. Una dependencia limpia hoy puede recibir una CVE mañana, cambiar de mantenedor, introducir una versión comprometida o volverse incompatible con un parche de seguridad. Por esto es necesario saber qué componentes están en producción y quién posee la remediación.

El monitoreo debe conectar SBOM, escáneres, gestión de vulnerabilidades, seguimiento de problemas y lanzamientos. Cuando surge una vulnerabilidad, el equipo debe entender rápidamente si el componente está presente, en qué versión, en qué servicio, si es accesible, si existe un exploit activo, qué mitigación aplicar y quién debe aprobar la actualización. Los agentes de IA pueden ayudar a preparar actualizaciones, pero no deberían aplicarlas sin revisión: una actualización automática puede corregir una CVE y romper la autenticación, el análisis, la serialización, la carga o la compatibilidad en tiempo de ejecución. El parche debe tratarse como una modificación del producto, no como una simple limpieza.

Cuando el paquete toca la seguridad de la aplicación

Algunas dependencias requieren mayor atención porque entran directamente en los límites de seguridad: librerías de autenticación, JWT, criptografía, sanitización de HTML, motores de plantillas, analizadores de markdown, carga de archivos, validación de entradas, ORM, controladores de bases de datos, clientes HTTP, middleware CORS, limitación de tasa (rate limiting), registro y gestión de secretos.

Si la IA sustituye o reconfigura una de estas librerías, la revisión debe leer también el comportamiento de la aplicación. Un nuevo analizador puede cambiar la gestión de XSS; un middleware CORS puede abrir dominios no previstos; una actualización de ORM puede modificar consultas o escapes; un paquete de carga de archivos puede aceptar tipos MIME o rutas de forma diferente; una librería JWT puede requerir configuraciones explícitas sobre el algoritmo, la audiencia o el emisor. Estas dependencias no deben aprobarse solo porque no tienen CVE conocidas: la pregunta es si están configuradas correctamente para el producto. Aquí es donde la cadena de suministro y la seguridad de la aplicación se encuentran.

Comandos generados automáticamente por los agentes

Cuando un agente tiene acceso a la terminal, puede ejecutar instalaciones, actualizaciones, migraciones, pruebas, scripts de compilación, comandos en la nube y modificaciones de configuración. El registro de comandos se convierte en parte de la revisión: no basta con mirar el código final, hay que saber qué se ha ejecutado.

Un comando puede modificar archivos no esperados, actualizar archivos de bloqueo, instalar paquetes globales, cambiar configuraciones locales, generar artefactos, crear cachés o enviar datos a servicios externos. En entornos con secretos, tokens o credenciales en la nube, el riesgo aumenta aún más. Para agentes operativos es necesario definir listas de permitidos de comandos, requerir aprobación para instalaciones y despliegues, usar entornos aislados, tokens con alcance mínimo y conservar los registros. Si el agente instala paquetes sin aprobación, el proceso de revisión ya empieza tarde.

Políticas de merge para dependencias generadas por la IA

Una política eficaz no debe bloquear cada cambio, sino hacer explícitas las decisiones. Cada nueva dependencia propuesta o instalada por la IA debería indicar: motivo, gestor de paquetes, versión, licencia, mantenedor, alternativas consideradas, impacto en el archivo de bloqueo, resultados de SCA, posibles scripts y propietario interno.

Las dependencias de alto riesgo deberían requerir aprobación explícita: paquetes no mantenidos, librerías con pocas descargas, envoltorios de seguridad, analizadores, motores de plantillas, gestores de carga, criptografía, autenticación, redes, paquetes que ejecutan scripts, imágenes base nuevas y herramientas que entran en CI/CD. Para equipos que usan codificación con IA de forma continua, esta política se convierte en parte del Ciclo de Vida de Garantía de Software: no hace falta hacer una excepción cada vez, sino tener un camino repetible para instalar, evaluar, aprobar y monitorear.

Cómo ISGroup verifica la cadena de suministro y las dependencias generadas por la IA

ISGroup puede verificar una PR, un repositorio o un proceso de lanzamiento en el que los agentes de IA modifican dependencias, archivos de bloqueo, Dockerfiles, flujos de trabajo, scripts o registros de paquetes. El control concierne tanto al código como a la cadena que lo lleva a producción.

Si la IA ha modificado…	Riesgo principal	Control recomendado
Manifiesto, archivo de bloqueo, paquete, script, Dockerfile o árbol de dependencias	Dependencias vulnerables, innecesarias o no gobernadas	Revisión de código
Componentes, servicios, librerías y versiones expuestas online	Vulnerabilidades conocidas explotables	Evaluación de vulnerabilidades
Dependencias y componentes en producción a monitorear con el tiempo	Vulnerabilidades recurrentes y gestión de parches	Servicio de gestión de vulnerabilidades
Canalización, políticas de merge, controles SCA, SBOM y puertas de lanzamiento	Proceso no repetible en los lanzamientos	Ciclo de vida de garantía de software
Nube, registro de contenedores, IAM, tokens, artefactos y despliegue	Configuración errónea o privilegios excesivos	Evaluación de seguridad en la nube

La elección del control depende del punto en el que entra el riesgo: código y manifiesto, componentes expuestos, proceso de parcheo, canalización o nube. Antes del merge conviene saber si el paquete es realmente necesario y si la compilación sigue siendo gobernable. Si tienes una PR generada por IA que añade paquetes, modifica archivos de bloqueo o cambia la canalización, ISGroup puede ayudarte a verificar dependencias, scripts, contenedores, SBOM y controles de merge antes del lanzamiento.

Evidencias a preparar para una verificación

Para iniciar una verificación eficaz, es útil recopilar repositorios, ramas, PR, manifiestos, archivos de bloqueo, árboles de dependencias, Dockerfiles, flujos de trabajo de CI/CD, escáneres utilizados, informes de SCA, informes de licencias, SBOM si existe, comandos ejecutados por el agente, tokens involucrados, registros utilizados y la motivación de las nuevas dependencias.

Para cada paquete añadido, es útil documentar el nombre, la versión, el registro, el mantenedor, el repositorio, la licencia, las alternativas disponibles, el motivo técnico, las dependencias transitivas, los scripts de instalación y el propietario interno. Si el agente ha ejecutado comandos, es importante conservar los registros y la salida. Estas evidencias permiten distinguir una dependencia necesaria de un atajo generado, un riesgo bloqueante de una actualización planificable y una vulnerabilidad conocida de un problema de proceso.

Cuándo bloquear el merge

Bloquea el merge si una nueva dependencia es sospechosa, innecesaria, no mantenida, con licencia incompatible, con scripts no verificados, con vulnerabilidad crítica no mitigada, con un archivo de bloqueo demasiado amplio sin explicación o si la canalización se ha modificado para eludir controles.

Puedes planificar después del merge solo actividades con riesgo residual bajo: mejorar la documentación, generar SBOM si el lanzamiento no es inminente, refinar políticas, añadir patrones de escaneo o reducir dependencias no críticas con propietario y fecha de vencimiento. Las dependencias que ejecutan código, tocan la seguridad o entran en producción deben estar claras antes.

Lista de verificación de la cadena de suministro para PR generadas por agentes

• Cada nueva dependencia tiene motivo, propietario y alternativa evaluada.
• El manifiesto y el archivo de bloqueo se revisan juntos.
• El nombre del paquete, mantenedor, registro y repositorio están verificados.
• Los scripts preinstall, install, postinstall, prepare y de compilación están controlados.
• Se han ejecutado escaneos de SCA, licencias y contenedores.
• Las versiones y las imágenes base tienen una fijación explícita, sin latest no motivado.
• SBOM generada o actualizada cuando el producto lo requiere.
• Los tokens de registro y CI/CD tienen un alcance mínimo.
• Los comandos ejecutados por el agente están registrados y aprobados donde sea necesario.
• Las dependencias generadas por la IA pasan por una revisión obligatoria antes del merge.

Preguntas frecuentes

• Si el escáner SCA está limpio, ¿puedo aceptar la dependencia?
• No automáticamente. El escáner no evalúa la necesidad, licencia, mantenedor, typosquatting, scripts de instalación, coherencia del archivo de bloqueo e impacto en el producto. Es una herramienta de apoyo, no un semáforo en verde.
• ¿El archivo de bloqueo realmente debe revisarse?
• Sí. El archivo de bloqueo muestra lo que realmente entra en la compilación, incluidas las dependencias transitivas y las actualizaciones indirectas que no aparecen en el manifiesto.
• ¿Puede un agente instalar paquetes por sí mismo?
• Puede hacerlo solo si el proceso lo permite. En proyectos con datos reales o en producción, las instalaciones y comandos que modifican dependencias deberían requerir aprobación explícita y registros conservados.
• ¿Cuándo se necesita una SBOM?
• Cuando debes entregar software, responder a clientes empresariales, gestionar vulnerabilidades con el tiempo o saber rápidamente si una CVE afecta a un lanzamiento específico.
• ¿Qué cambia respecto a una revisión de código normal?
• La revisión de código lee el código. La revisión de la cadena de suministro lee también manifiestos, archivos de bloqueo, scripts, registros, contenedores, SBOM, licencias, comandos ejecutados y canalizaciones.
• ¿Cuándo se necesita el Servicio de Gestión de Vulnerabilidades?
• Cuando el problema no es solo controlar una PR, sino monitorear continuamente componentes, versiones y vulnerabilidades en producción con el tiempo.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

• OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
• OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/
• OpenSSF Scorecard: https://openssf.org/scorecard/
• OpenSSF SLSA: https://openssf.org/projects/slsa/
• OWASP SAMM: https://owasp.org/www-project-samm/
• OWASP Top 10 – Vulnerable and Outdated Components: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/