El problema del 89 %: cómo los LLM están resucitando a la «mayoría inactiva» del código abierto

Los asistentes de programación con IA están resucitando silenciosamente millones de paquetes abandonados de código abierto. Durante la última década, los desarrolladores se guiaron por una heurística sencilla para proteger el código abierto: Popularidad \= confianza. Si un paquete se descargaba millones de veces por semana (lodash, react, requests), asumíamos que era «lo bastante seguro» porque miles de personas lo revisaban. Si era poco conocido, actuábamos con cautela.

Los desarrolladores humanos siguen señales sociales de confianza, como la popularidad, la actividad de mantenimiento y la adopción por parte de la comunidad. Este modelo de «sabiduría colectiva» funcionaba porque los desarrolladores humanos son, por naturaleza, seres sociales. Seguimos los caminos establecidos por nuestros pares. Sin embargo, la IA generativa está empezando a romper este modelo.

Los sistemas de IA seleccionan paquetes según patrones estadísticos en datos de entrenamiento que abarcan toda la historia de internet, incluidos millones de proyectos abandonados y repositorios experimentales. Los LLM son estocásticos: no entienden la «popularidad» ni el «estado del mantenimiento» como lo haría un arquitecto o ingeniero. En cambio, entienden la probabilidad estadística a partir de datos de entrenamiento que abarcan toda la historia de internet, con lo bueno, lo malo y lo abandonado.

Creamos Snyk Advisor y luego lo integramos en nuestra Security DB para ayudar a cerrar la brecha entre la inteligencia de código abierto y el estado de los paquetes, y brindar a desarrolladores y agentes distintos datos sobre seguridad, popularidad, mantenimiento y comunidad. ¿Cómo potencia la información sobre el estado de los paquetes de Snyk a los agentes de IA? Esta es nuestra perspectiva.

Los datos: visualización de la «mayoría inactiva»

Al analizar el ecosistema de código abierto, surge un patrón sorprendente. Un número muy reducido de paquetes impulsa gran parte de la internet actual, mientras que la gran mayoría se usa muy poco o ha sido abandonada por completo.

Para entender el riesgo, debemos volver a examinar la estructura del ecosistema de código abierto. Snyk aportó datos clave al informe Census II de Linux Foundation y Harvard, que describe la realidad de la cadena de suministro. Al superponer los datos sobre el estado de los paquetes con su prevalencia, surge una jerarquía clara:

Casi el 90 % del ecosistema de código abierto pertenece a la mayoría inactiva: millones de experimentos, bifurcaciones y proyectos sin mantenimiento que se han abandonado. Los desarrolladores humanos rara vez eligen paquetes de este nivel; los sistemas de IA, en cambio, sí lo hacen.

La desconexión de la IA

Los desarrolladores humanos suelen mantenerse en los niveles superiores del ecosistema: frameworks de uso extendido, bibliotecas de infraestructura confiables y herramientas maduras para dominios específicos. Como los LLM se entrenan con enormes repositorios de código que abarcan toda la historia de internet, pueden mostrar paquetes de cualquier parte del ecosistema, incluida la mayoría inactiva.

Como resultado, los LLM pueden recomendar paquetes del 89.5 % inferior del ecosistema: proyectos abandonados, bifurcaciones sin mantenimiento e incluso experimentos sencillos de «Hello World». Por ejemplo, el investigador de seguridad Luke Hinds compartió una interacción en la que un LLM recomendó el paquete de Go gorilla/sessions:

El problema con esta recomendación del LLM es que gorilla/sessions se archivó. Como los repositorios archivados ya no reciben actualizaciones, usar este paquete genera deuda de mantenimiento a largo plazo y riesgos sin corregir en la cadena de suministro.

Peor aún, los LLM sufren alucinaciones (o «alucinaciones de paquetes de IA») y recomiendan con seguridad paquetes que nunca existieron. Esto crea dos nuevos vectores de ataque:

1. La resurrección de zombis: un LLM sugiere un paquete de 5 años sin mantenimiento de la «mayoría inactiva» porque resuelve un problema de nicho específico. Tiene 0 CVE (porque nadie los busca), pero contiene fallas críticas.

1. Slopsquatting (ataques mediante alucinaciones de IA): los atacantes predicen nombres de paquetes comunes que los LLM alucinan (por ejemplo, huggingface-cli-tool en lugar del huggingface-cli real) y los registran con cargas maliciosas. Cuando una IA sugiere este paquete «lógico» pero falso, el desarrollador instala malware.

El giro estratégico: de la «popularidad» a la «procedencia»

Como CISO, no puedes depender de que tus desarrolladores revisen manualmente cada sugerencia de IA. La velocidad es demasiado alta. Debes cambiar el enfoque de tu programa: pasar de «buscar lo malo» a «garantizar lo bueno». En publicaciones anteriores, describimos los roles de los CISO y cómo evolucionan sus responsabilidades.

Del mismo modo, como ingeniero, no puedes depender por completo de los agentes de programación con IA para que elijan e instalen paquetes desde npm o PyPI, debido al riesgo inherente de la cadena de suministro de software: podrían introducir un paquete malicioso que robe datos o instale malware, por ejemplo, mediante las capacidades postinstall del administrador de paquetes npm.

¿Cómo podemos brindar a los agentes de programación con IA y a los ingenieros de software heurísticas sobre el estado de los paquetes para obtener resultados autónomos más seguros? Con el camino establecido de Snyk.

1. Encuentra paquetes confiables en security.snyk.io

Antes de elegir una dependencia, los desarrolladores y los sistemas de IA necesitan conocer la reputación y confiabilidad de los paquetes de código abierto. La nueva experiencia de Snyk Security Database ofrece una vista centralizada de las señales de confianza de los paquetes para ayudar a los equipos a identificar rápidamente proyectos de amplia adopción, bien mantenidos y con buena reputación en los ecosistemas compatibles.

Estrategia: Anima a los desarrolladores y los equipos de plataforma a consultar la información de Snyk Security Database al buscar paquetes, para que prioricen las dependencias maduras y confiables desde las primeras etapas del proceso de selección.

2. Snyk Package Health API ayuda a verificar el estado, no solo las vulnerabilidades

Que un paquete no tenga vulnerabilidades conocidas no significa necesariamente que sea seguro. Puede estar abandonado, sin mantenimiento o carecer de una comunidad confiable. Para proteger las cadenas de suministro de software, hay que evaluar el estado del paquete más allá de los CVE. Snyk Package Health API ofrece inteligencia a nivel de paquete y de versión en los principales ecosistemas (npm, PyPI, Maven, NuGet y Go), y expone señales como:

• Postura de seguridad.

• Actividad de mantenimiento e indicadores del ciclo de vida.

• Métricas de popularidad y adopción.

• Señales de participación de la comunidad.

Esto permite que las plataformas de ingeniería, los pipelines de CI/CD y las herramientas de desarrollo basadas en IA evalúen automáticamente la calidad, sostenibilidad y riesgo para el ecosistema de una dependencia en el momento de considerarla, especialmente cuando se selecciona o se incorpora.

Estrategia: Integra la inteligencia sobre el estado de los paquetes directamente en los flujos de trabajo de selección de dependencias y en los entornos de desarrollo asistidos por IA, para evaluar si un paquete es adecuado antes de agregar una dependencia, no después de instalarla.

Herramientas: Usa Snyk Package Health API para orientar la selección de paquetes, la planificación de actualizaciones y la gobernanza automatizada de dependencias. Consulta el endpoint a nivel de paquete y el endpoint a nivel de versión del paquete para ver detalles de implementación.

Si integras una solución SCA mediante CLI, CI o verificaciones de GitHub CI, Snyk Open Source también detectará estas recomendaciones desacertadas de código de los LLM durante la compilación y antes de ella (imagina que el agente de programación planea ejecutar un npm install … para instalar un paquete malicioso).

3. Aplica medidas de seguridad a las dependencias desde que se incorporan con Snyk Studio

Aunque haya información disponible, los desarrolladores y los asistentes de programación con IA pueden seguir incorporando dependencias automáticamente. Por eso, la seguridad debe aplicarse en el momento de seleccionar una dependencia, no solo durante los análisis de CI/CD.

El flujo de Package Health de Snyk Studio integra la inteligencia sobre el estado de los paquetes directamente en los flujos de desarrollo asistidos por IA. Cuando un asistente de programación con IA propone agregar o actualizar una dependencia, Snyk Studio puede ejecutar automáticamente la verificación del estado del paquete antes de instalarlo y evaluar las señales de riesgo en tiempo real. Así, las organizaciones pueden evitar que paquetes en mal estado, sin mantenimiento o riesgosos ingresen a su código en la etapa más temprana posible: el momento de «proteger desde el inicio».

Estrategia: Configura los asistentes de programación con IA para que ejecuten automáticamente verificaciones de Package Health antes de incorporar dependencias nuevas, pausen o bloqueen la instalación cuando haya señales de riesgo y soliciten la aprobación explícita del usuario para continuar.

4. Defiéndete de las alucinaciones

En ocasiones, los asistentes de programación con IA pueden recomendar paquetes que no existen en los registros públicos. Estos eventos de «paquete no encontrado» deben tratarse como posibles señales de seguridad de la cadena de suministro, no como simples errores de desarrollo, ya que más adelante los atacantes podrían registrar paquetes con nombres similares para aprovechar estos errores.

Estrategia: Trata los errores al resolver dependencias (por ejemplo, «paquete no encontrado») como eventos relevantes para la seguridad. Investiga de dónde provino la sugerencia de la dependencia y valida que el nombre del paquete sea legítimo antes de continuar.

En la siguiente imagen, puedes ver cómo el agente de programación Windusrf invoca Snyk Studio para analizar el estado de los paquetes mediante la herramienta snyk_package_health_check, que forma parte de otras herramientas de seguridad del Snyk MCP Server. Una vez instalado Snyk Studio, el agente de IA puede confirmar que el paquete se puede mantener, no presenta problemas de seguridad y no es malicioso.

La misión de Snyk: proteger el código generado por IA

Creamos Snyk con la convicción de que la seguridad que prioriza a los desarrolladores es la única forma de escalar. Esto es aún más cierto en el mundo de los agentes de programación con IA. Los datos de Census II muestran que el ecosistema de código abierto es vasto y está mayormente inactivo.

Nuestro trabajo es mantener a tu IA y a tus desarrolladores enfocados en los niveles superiores, saludables y dinámicos: el 10 % que impulsa al mundo, y automatizar las defensas contra el caótico 90 %. No dejes que tu IA verifique la confianza. Verifica la confianza de la IA.

¿Quieres saber más sobre cómo los asistentes de programación con IA están transformando los riesgos de la cadena de suministro de software? Explora nuestra guía para proteger Python en la era de la IA.