La seguridad de las dependencias en la programación con IA exige tratar cada paquete propuesto por el agente como no fiable hasta que la política y un revisor humano lo aprueben. Los agentes de programación pueden elegir dependencias, ejecutar gestores de paquetes y acceder a registros, por lo que un paquete verosímil pero inexistente puede convertirse en código ejecutable en cuestión de minutos. La seguridad de las dependencias en la programación con IA es la disciplina que controla cómo las dependencias generadas por IA entran, cambian y salen de una compilación de software.
¿Por qué los agentes de programación con IA están creando un problema de dependencias?
Los agentes de programación con IA crean riesgo de dependencias porque pueden recomendar paquetes, editar manifiestos, ejecutar comandos de instalación y acceder a registros públicos más rápido de lo que los revisores pueden validar cada cambio. VentureBeat informó el 24 de septiembre de 2026 de que los asistentes estaban añadiendo paquetes, bibliotecas e imágenes de contenedor mientras los ciclos de aprobación empresariales seguían tardando días.
La velocidad cambia la naturaleza del problema. Un desarrollador puede añadir unas pocas dependencias durante un sprint de funcionalidades, mientras que un agente autónomo puede probar bibliotecas repetidamente, descartar enfoques y dejar paquetes indirectos ocultos en un lockfile. Cada incorporación amplía el conjunto de responsables de mantenimiento, sistemas de publicación y cuentas de registro en los que confía tu aplicación.
El riesgo no se limita al código malicioso. Bibliotecas abandonadas, licencias inesperadas, editores comprometidos, nombres con typosquatting y versiones incompatibles pueden llegar a una compilación a través de una sugerencia que parece razonable en una pull request. Los equipos que ya están preocupados por repositorios maliciosos que secuestran agentes de programación deberían aplicar el mismo escepticismo a los registros de paquetes.
La revisión tradicional también tiene un problema de visibilidad. Una adición de una sola línea a package.json puede incorporar decenas o cientos de componentes transitivos, según el paquete, la versión y el ecosistema en 2026. Por tanto, revisar el paquete directo sin inspeccionar el árbol resuelto es una decisión de seguridad incompleta.
¿Cómo se convierten los paquetes alucinados en ataques a la cadena de suministro?
Los paquetes alucinados se convierten en oportunidades de ataque cuando un modelo de IA sugiere repetidamente un nombre verosímil que no existe, lo que permite a un atacante registrar ese nombre y publicar código hostil. Un estudio académico de 2025 sobre 16 modelos y 576.000 muestras generadas midió una tasa media de alucinación de paquetes de aproximadamente 19.6%.
El estudio, publicado a través de USENIX en 2025, muestra por qué una instalación fallida no es ruido inofensivo. Los nombres repetidos proporcionan a un atacante un canal de distribución ya preparado: registrar el nombre que falta, esperar a que el código generado lo solicite y confiar en el comportamiento normal del gestor de paquetes para recuperarlo.
Sonatype informó de un problema de versiones relacionado en 2026 tras analizar 36.870 recomendaciones de actualización generadas por agentes. Según Sonatype, el 27.76% hacía referencia a versiones inexistentes, incluidas más de 10.000 versiones alucinadas. Que el nombre de un paquete sea real no hace que una versión inventada sea segura; puede desencadenar compilaciones fallidas, sustituciones inseguras o presión para eludir controles.
La propagación puede producirse antes de que nadie publique malware. La Cloud Security Alliance describió el nombre alucinado react-codeshift extendiéndose por 237 repositorios bifurcados antes de que un investigador lo registrara de forma defensiva en enero de 2026. Las bifurcaciones pueden conservar una referencia de dependencia errónea mucho después de que desaparezca la salida original.
La hoja informativa OWASP sobre Secure Coding with AI, consultada el 1 de octubre de 2026, recomienda comprobar cada paquete sugerido en su registro real y revisar su fecha de creación, actividad de descargas e historial del responsable de mantenimiento. OWASP trata los paquetes con menos de 30 días con especial sospecha. En mi opinión, un fallo de instalación debería registrarse como una señal de seguridad, no descartarse como otro error tipográfico del agente.
¿Qué debería exigir una política de aprobación de dependencias de IA?
Una política de aprobación de dependencias de IA debe exigir que el agente identifique el propósito de la dependencia, el paquete y la versión exactos, el registro, el estado de mantenimiento y las alternativas rechazadas antes de la instalación. La seguridad de dependencias en programación con IA debe entonces aplicar la decisión fuera del modelo mediante reglas de integración continua, registros aprobados y autorización humana para cambios sensibles.
La explicación de un modelo es evidencia, no aplicación. Las instrucciones del prompt pueden ignorarse, malinterpretarse o verse desplazadas por contenido hostil del repositorio. El patrón más seguro es sencillo: el agente puede proponer una dependencia, pero un control independiente decide si ese paquete puede entrar en la compilación.
La siguiente lista de comprobación cubre la ruta mínima de revisión para cada dependencia nueva o modificada:
- Confirme que el paquete y la versión exactos existen en el registro previsto, y rechace sustituciones silenciosas.
- Registre el propósito del paquete, el editor, la fecha de creación, la actividad de publicación, la licencia y el historial de mantenimiento.
- Compare al menos una alternativa sin dependencias o ya aprobada, incluido el coste de escribir la función requerida localmente.
- Restrinja las descargas a registros internos o públicos aprobados mediante listas de permitidos de red y la política del repositorio.
- Exija cambios revisados en el manifiesto y el lockfile, valores de integridad, un diff de dependencias y una lista de materiales de software.
- Analice las dependencias directas y transitivas antes de la fusión y, a continuación, haga fallar la integración continua en el umbral de gravedad definido por la organización.
- Envíe la instalación, la política del registro y las excepciones de alto impacto a una puerta de aprobación humana que el agente no pueda aprobar por sí mismo.
Este enfoque también evita la proliferación de dependencias. Si un paquete ahorra 20 líneas de código pero introduce 40 componentes transitivos, la revisión debe medir la confianza añadida en lugar de admirar el archivo fuente más corto. Sinceramente, una pequeña función local suele tener más sentido cuando la alternativa crea un gran árbol de dependencias con mantenimiento deficiente.
La publicación especial 800-204D de NIST recomendó listas de permitidos de fuentes de confianza, verificación de firmas, análisis de vulnerabilidades, comprobaciones de actualizaciones y listas de materiales de software en 2024. NIST también recomendó comenzar el análisis de dependencias en el primer commit, en lugar de posponerlo hasta la publicación. Esos controles encajan de forma natural junto a una validación más amplia de la cadena de suministro de terceros.
¿Cómo debe la CI verificar los cambios de dependencias generados por IA?
La integración continua debe rechazar los cambios de dependencias generados por IA a menos que el manifiesto, el lockfile revisado, los datos de integridad, el diff de dependencias, los resultados de vulnerabilidades y la lista de materiales de software coincidan. Para los proyectos npm en 2026, la instalación determinista y los archivos package-lock.json confirmados dan a los revisores un árbol de dependencias definido en lugar de un intervalo de versiones cambiante.
Según la documentación de npm consultada el 1 de octubre de 2026, package-lock.json registra los artefactos resueltos y los valores de integridad SHA-512 o SHA-1. El estándar npm audit el flujo de trabajo normalmente requiere un lockfile porque una auditoría necesita un árbol definido. Una pull request solo de manifiesto debería fallar automáticamente.
| Control | Evidencia revisada | Condición de fallo |
|---|---|---|
| Verificación del registro | Paquete exacto, versión, editor y registro aprobado | Falta el nombre o la versión, se ha sustituido o se ha obtenido de una fuente no aprobada |
| Instalación determinista | Confirmado package-lock.json y artefactos resueltos |
Cambios en el manifiesto sin los correspondientes cambios revisados en el lockfile |
| Integridad y procedencia | Hashes de integridad, firmas del registro y atestaciones disponibles | El artefacto difiere de los datos bloqueados o falla la verificación requerida |
| Análisis de vulnerabilidades | Hallazgos de dependencias directas y transitivas | Un hallazgo cumple el umbral de rechazo documentado de la organización |
| Comparación de SBOM | Inventario SPDX o CycloneDX frente a la compilación aprobada anterior | Aparece un componente, versión, fuente o dependencia transitiva inesperados |
la documentación de npm consultada en 2026 afirma que las firmas de auditoría de npm comprueban las firmas del registro y las certificaciones de procedencia. La verificación de procedencia requiere npm CLI 9.5.0 o posterior. Las firmas no demuestran que un paquete sea benigno, pero pueden establecer si el artefacto y las pruebas del editor coinciden con lo que presenta el registro.
Genera una lista de materiales de software para cada compilación, no solo para una versión principal. npm puede producir resultados en formato SPDX o CycloneDX, mientras que NIST y la Cybersecurity and Infrastructure Security Agency describen las SBOM como inventarios de software legibles por máquina. Comparar inventarios sucesivos revela el coste oculto de una pequeña modificación del manifiesto.
El análisis por sí solo es demasiado limitado. Es posible que una base de datos de vulnerabilidades no tenga ninguna entrada para un paquete malicioso recién creado, por lo que la seguridad de las dependencias en la codificación con IA también debe evaluar la antigüedad del paquete, el registro, el editor y la procedencia. Un razonamiento similar se aplica cuando los equipos usan agentes de IA durante la revisión de código: los hallazgos automatizados respaldan el criterio, en lugar de sustituirlo.
¿Qué permisos deberían recibir los agentes de codificación?
Los agentes de codificación deberían recibir identidades independientes, credenciales de corta duración y solo los permisos de shell, sistema de archivos, gestor de paquetes y red necesarios para el repositorio asignado. La guía de GitHub de 2026 recomienda herramientas restringidas y aprobación humana para operaciones sensibles, mientras que los commits creados por agentes y los registros de sesión preservan la atribución tras un incidente.
El acceso al registro debe ser explícito. El cortafuegos del agente en la nube de GitHub admite reglas de dominio o URL a nivel de organización y de repositorio, según la documentación consultada el 1 de octubre de 2026, aunque GitHub advierte de que el cortafuegos no es exhaustivo. El filtrado de red debe complementar la política de paquetes, no sustituirla.
La brecha de identidad sigue siendo considerable. VentureBeat Pulse informó el 12 de agosto de 2026 de que 65% de las empresas encuestadas aplicaban permisos de agente con ámbito limitado, pero solo 18% aislaban a sus agentes de mayor riesgo y 53% habían experimentado un incidente de seguridad relacionado con agentes o una situación de riesgo inminente. Un informe independiente de VentureBeat situó en solo 8% en 2026 la proporción que combinaba la aplicación en tiempo de ejecución con el aislamiento de alto riesgo.
He aquí el cálculo que suele pasarse por alto: 65% de aplicación menos 8% que combina aplicación con aislamiento deja una brecha de 57 puntos porcentuales entre el control básico de permisos y el control reforzado combinado en esa encuesta de 2026. Los permisos ayudan, pero la infraestructura y las credenciales compartidas aún pueden convertir a un agente comprometido en un incidente más amplio.
Las credenciales compartidas también debilitan la atribución. El 30 de septiembre de 2026, VentureBeat informó de que 22 de 37 organizaciones encuestadas que ejecutaban agentes de producción con permisos aplicados seguían permitiendo que algunos o la mayoría de los agentes compartieran credenciales. Un registro que muestre “cuenta de automatización” no es suficiente cuando varios agentes pueden usar el mismo secreto.
Mantenga la aprobación fuera del alcance del agente. Una demostración de inyección de prompts del 26 de agosto de 2026, de la que informó VentureBeat, mostró a un agente usando credenciales existentes para realizar un cambio no autorizado en el DNS. El patrón recomendado permite que un agente proponga una acción de gran impacto, pero le impide aprobar esa acción, un modelo útil tanto para la instalación de paquetes y las excepciones de registro como para los cambios de infraestructura. Los equipos también deberían tener en cuenta las formas más amplias en que los agentes de codificación eligen e invocan herramientas.
Preguntas frecuentes
¿Puede un lockfile detener un paquete npm malicioso?
Un lockfile no puede determinar si un paquete npm es malicioso. Un package-lock.json fija el árbol resuelto y registra datos de integridad en 2026, lo que ayuda a la integración continua a detectar artefactos inesperados o cambios en las dependencias.
¿Es npm audit suficiente para la seguridad de las dependencias en la programación con IA?
npm audit no es suficiente para la seguridad de las dependencias en la programación con IA porque el análisis de vulnerabilidades puede pasar por alto paquetes nuevos, alucinados o deliberadamente maliciosos. La identidad del registro, la antigüedad del paquete, el historial del editor, las firmas, la procedencia y las diferencias del SBOM requieren comprobaciones independientes en 2026.
¿Debería permitirse a los agentes de programación instalar paquetes?
Los agentes de programación pueden instalar paquetes dentro de un entorno aislado cuando las listas de permitidos del registro, las credenciales con ámbito limitado, las compilaciones deterministas y las puertas de aprobación externas restrinjan la acción. Las compilaciones de producción deberían rechazar los cambios no revisados en el manifiesto o en el lockfile en 2026.
¿Qué debería explicar un agente antes de añadir una dependencia?
Un agente de programación con IA debería indicar el propósito de la dependencia, el paquete y la versión exactos, el registro de origen, el estado de mantenimiento y las alternativas descartadas. La política de integración continua y un revisor humano deberían verificar esa explicación antes de que la dependencia entre en una compilación de 2026.