El sector necesita un sistema fiable para notificar y rastrear paquetes comprometidos si quiere seguir compartiendo software.
Aunque hay más software de código abierto disponible que nunca, el riesgo de utilizarlo nunca había sido tan alto. ¿Por qué? Porque informes recientes sobre la manipulación maliciosa de paquetes demuestran que analizar el código fuente de un repositorio público no garantiza que el paquete distribuido sea seguro.
Dado que asumimos que los paquetes son seguros, cuando está demostrado que no lo son, el ecosistema de la cadena de suministro de software queda expuesto. Los artefactos de compilación, los paquetes, las canalizaciones, los puntos de distribución de paquetes y los procesos de instalación se utilizan habitualmente con fines maliciosos.
Cuanto más popular es el paquete, más rápido se producen los daños. Actualmente, estamos observando que las herramientas de IA son las más afectadas por el envenenamiento, y los agentes de IA agravan los daños con tanta rapidez que puede afirmarse que el sector está desbordado por la vulneración de paquetes.
Lo que hemos hecho no nos llevará hasta allí
El ecosistema de software de código abierto no cuenta con ningún registro oficial de paquetes de software comprometidos. Esto significa que las organizaciones carecen de un sistema fiable que les permita confiar en los paquetes de código que utilizan. Además, los procesos de compilación, los comportamientos de instalación y los repositorios de paquetes presuponen que son seguros, en lugar de contemplar que puedan estar comprometidos. La automatización y los agentes de IA agravan y aceleran el riesgo a la velocidad de las máquinas.
Para hacer frente a este nuevo desafío, el ecosistema del software de código abierto necesita:
- Colaboración de todo el sector para notificar paquetes comprometidos utilizando una única fuente de información fiable.
- Esfuerzo específico para subsanar las brechas de seguridad en la cadena de suministro de software del ecosistema.
- Compromiso del ecosistema para desarrollar, promover e implementar las mejores prácticas del sector.
Una cultura de aprendizaje y mejora continuos constituye una defensa formidable. Nunca debemos dejar de mejorar la seguridad de nuestro ecosistema de código fuente, nuestras canalizaciones de compilación y nuestros repositorios de paquetes.
Primeros pasos
Tenemos una solución aproximada a lo que necesitamos. Está alojada por la Open Source Security Foundation (OpenSSF) y se denomina Malicious Packages Repository (MPR). Ofrece un lugar y un proceso centralizados para definir y notificar paquetes maliciosos. Lo que necesita es una amplia participación del sector para convertirse en el estándar de facto para el seguimiento y la corrección de paquetes comprometidos.
El MPR utiliza una especificación de archivos procesable por máquinas denominada formato Open Source Vulnerability (OSV), que emplea JSON para automatizar el envío y la recopilación de informes, así como para proporcionar datos a los escáneres. Esto permite aplicar un procedimiento específico para que los investigadores de confianza aporten nuevos datos de forma continua, rápida y eficiente. Por último, lo mantiene un grupo de trabajo activo y abierto a nuevos colaboradores y mejoras.
Necesitamos algo como el MPR de OpenSSF, centrado en los paquetes maliciosos, que haga por ellos lo que se está haciendo con las vulnerabilidades del código fuente a través del programa CVE. El cambio comienza por reconocer la situación actual, y este fue sin duda el impulso que llevó a crear el MPR de OpenSSF. Así pues, aunque el trabajo ya ha comenzado, aún queda mucho por hacer antes de que llegue a ser tan útil como la base de datos CVE. Como sector, podemos y debemos colaborar para que el ecosistema de software que compartimos sea más fiable.
Sobre el autor
Artículos relacionados del blog
Las 10 principales amenazas en la entrega de aplicaciones de IA: falta de seguridad y cumplimiento normativo
La IA amplía el alcance del cumplimiento normativo: ya no se limita a proteger rutas y almacenes, sino que también abarca la gobernanza del comportamiento en tiempo de ejecución —el acceso a los modelos, el contexto de recuperación, los resultados y las acciones de los agentes—, por lo que los controles deben situarse más cerca de la inferencia.
Las 10 principales amenazas en la entrega de aplicaciones de IA: controles de tráfico insuficientes
Los límites de tasa y la limitación de tráfico tradicionales no reflejan el verdadero alcance del impacto. Las cargas de trabajo de IA se distribuyen entre modelos, almacenes vectoriales y servicios, lo que provoca picos de latencia, fallos en cascada y reintentos.
Comportamiento y límites: el cambio hacia la seguridad agéntica
Los agentes generan secuencias emergentes y sin límites en las que el riesgo se acumula con el tiempo. La seguridad debe pasar de validar solicitudes individuales a supervisar continuamente el comportamiento en flujos de varios pasos que evolucionan con el tiempo.
Habilidades de los agentes: un estándar abierto emergente
Las skills declaran la intención, pero no imponen controles. La seguridad real debe residir en el límite de las herramientas, donde los pensamientos del agente se convierten en acciones y se pueden aplicar las políticas.
De paquetes a prompts: la inferencia añade una nueva capa a la pila
La inferencia no es entrenamiento. No es experimentación. No es un ejercicio de ciencia de datos. La inferencia es un comportamiento en tiempo de ejecución en producción y funciona como una capa de aplicación.