PyPI estrena pestaña de seguridad y avisos de procedencia

PyPI ya dice si el 100% de los archivos de una release tiene origen verificado

El umbral es binario y ya está visible: una release de PyPI tiene «procedencia completa» solo cuando el 100% de sus archivos lleva al menos una atestación digital. El equipo de la Python Package Index terminó el rediseño de sus páginas de proyecto que anunció en julio y lo puso en producción, con una pestaña de seguridad dedicada a verificar de dónde salió cada archivo antes de que corra en tu entorno.

Para un founder que sostiene un producto sobre una pila de decenas de dependencias open source, esto cambia una cosa concreta: la confianza en un paquete deja de ser una corazonada sobre el mantenedor y pasa a tener un estado consultable. Y en un año en el que los ataques a la cadena de suministro de Python dejaron de ser teóricos, ese estado importa.

¿Qué cambia en las páginas de proyecto de PyPI?

El rediseño se apoya en un trabajo de investigación de usuarios con miembros de la comunidad Python y en las recomendaciones de la OpenSSF Attestations Style Guide. PyPI lo implementó junto a Kabu Creative, con financiamiento de la Open Source Security Foundation.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La pieza central es la nueva pestaña de seguridad, que traduce a la interfaz dos conceptos que hasta ahora vivían en la documentación técnica: procedencia y atestaciones. PyPI introdujo las atestaciones digitales en 2024 para dejar un registro verificable del origen de cada archivo publicado, pero la interfaz no explicaba qué significaban ni cuáles eran sus límites.

Procedencia completa: todos los archivos de la release tienen atestación, de tipo PyPI Publish (confirma que el archivo lo publicó un Trusted Publisher) o SLSA Build Provenance (vincula el archivo con su commit de origen, la plataforma de build y las instrucciones de compilación).
Sin procedencia: ningún archivo de la release tiene atestación. Es habitual en releases antiguas o en proyectos que todavía no configuraron Trusted Publishing.
Advertencias de procedencia: señales que aparecen cuando el metadata de un archivo se ve inusual o choca con el historial del proyecto.

El punto que más se malinterpreta es el segundo. Según recoge Help Net Security, la diseñadora colaboradora de PyPI Nicole Harris insistió en que la ausencia de procedencia no implica que una release sea maliciosa: significa que el origen del archivo no puede verificarse criptográficamente. En esos casos, el consejo es evaluar las señales de confianza que rodean al paquete: historial de los mantenedores, patrón de releases y actividad del repositorio.

¿Cuándo aparece una advertencia y qué deberías hacer?

Las advertencias cubren cuatro escenarios distintos, y cada uno tiene su propia lectura. La fuente original de PyPI los detalla así:

Procedencia parcial: algunos archivos tienen atestación y otros no. El caso típico es una release donde los wheels se publicaron por Trusted Publishing y el tarball de código fuente se subió a mano con un token de API.
Orígenes mezclados: los archivos de una misma release provienen de sistemas de build o repositorios distintos. La verificación pendiente es si todos salieron de fuentes controladas por los mantenedores.
Cambio de repositorio o workflow: la release viene de un repositorio diferente al de la versión anterior. Suele ser legítimo —un cambio de nombre de la organización o una migración— pero también puede indicar un pipeline comprometido o una cuenta tomada.
Pérdida de atestaciones: un proyecto que publicaba con atestaciones empezó a subir archivos sin ellas. Puede ser un cambio deliberado de proceso; si no era esperado, conviene tratar la release con escepticismo hasta verificarla.

La recomendación del equipo de PyPI es concreta: ante cualquier advertencia, revisar las notas de la release o preguntar en el issue tracker del proyecto antes de instalar. La interfaz, además, ahora muestra estas advertencias en la parte superior de la página del proyecto, junto a los banners de releases retiradas (yanked), proyectos archivados y pre-releases. Si un proyecto o release está en cuarentena, solo se muestra ese banner, porque tiene precedencia sobre todos los demás.

También cambió la tabla de archivos: se puede buscar y filtrar listas largas, ver el estado de procedencia de cada archivo y detectar archivos tardíos, marcados con un icono naranja de advertencia cuando se subieron más de 14 días después del timestamp inicial de la release. Esos avisos solo aparecen en releases anteriores a julio de 2026, cuando PyPI introdujo la política de rechazar archivos nuevos pasado ese plazo. El historial de releases, por su parte, ahora expone número de archivos, estado de procedencia y estado de la release.

¿Por qué esto deja de ser un detalle técnico?

El propio equipo de PyPI justifica el rediseño con una frase que cualquier founder debería leer dos veces: con el crecimiento del ecosistema Python, PyPI se volvió un objetivo cada vez más atractivo para actores maliciosos.

Los datos de este año respaldan esa preocupación. BankInfoSecurity reportó el quinto brote en ocho meses de la familia de malware Shai-Hulud, que infectó más de 170 paquetes con casi 180 millones de descargas semanales combinadas, según la firma Ox Security. Entre las víctimas estuvieron paquetes de npm construidos por TanStack, Mistral AI, OpenSearch Project y UiPath. La versión de PyPI del paquete de Mistral AI, la 2.4.6, estuvo disponible para descarga unas tres horas e incluía un ladrón de credenciales según el equipo de seguridad de Microsoft.

El detalle más incómodo —y el que obliga a leer bien lo que promete la nueva pestaña de PyPI— es cómo cayó TanStack. Según Endor Labs, citado por BankInfoSecurity, el ataque funcionó contra un objetivo que «hizo todo bien sobre el papel»: autenticación de dos factores en las cuentas de los mantenedores, trusted-publisher binding en lugar de tokens de larga duración y atestaciones de procedencia firmadas en cada release. El atacante usó una técnica nueva —un commit huérfano empujado a un fork del repositorio— para obtener un token de publicación legítimo y de corta vida. En seis minutos infectó 42 paquetes, detectados unos 20 minutos después por StepSecurity.

La conclusión para un equipo de producto es que la procedencia no es un escudo: es un registro. Sirve para saber qué pasó y para responder rápido, no para impedir que un pipeline legítimo publique algo malicioso. El otro caso del año apunta en la misma dirección: Ars Technica documentó cómo versiones comprometidas de LiteLLM descargadas desde PyPI permitieron extraer credenciales de más de 2.500 organizaciones en una ventana de 40 minutos en marzo, a partir de un archivo de 195 TB analizado por las firmas de seguridad.

¿Qué significa esto para tu startup?

La traducción práctica es que la evaluación de dependencias deja de ser una tarea de fin de trimestre y se vuelve un paso del flujo de trabajo. Cuatro acciones que puedes implementar esta semana:

1. Agrega la pestaña de seguridad a tu criterio de adopción. Antes de sumar un paquete nuevo, abre su página en PyPI y revisa el estado de procedencia y las advertencias. Si no tiene procedencia, no lo descartes automáticamente: mira historial de mantenedores, frecuencia de releases y actividad del repositorio, que es exactamente lo que recomienda PyPI. Si tiene una advertencia activa, esa release espera.

2. Migra tus propios paquetes a Trusted Publishing. Si publicas librerías internas o abiertas en PyPI, pasar de tokens de API de larga duración a Trusted Publishing elimina una credencial permanente de tu CI y, de paso, hace que tus usuarios vean un estado de procedencia claro. PyPI documenta el proceso y la guía de seguridad de paquetes ampliada en este mismo lanzamiento.

3. Implementa un período de enfriamiento en el pipeline. La orientación que circula entre los defensores es no absorber cada actualización al minuto. Ollie Whitehouse, CTO del NCSC británico, dijo a periodistas —según BankInfoSecurity— que estos ataques se detectan en cuestión de horas o días y que muchas organizaciones no necesitan actualizar en tiempo real. La práctica se conoce como code cooldown: bloquear paquetes nuevos durante horas o días antes de que entren al pipeline, con lockfiles y versiones fijadas.

4. Trata la rotación de claves como higiene, no como respuesta a incidentes. Es la recomendación de Ox Security que recoge el mismo reporte: MFA en las cuentas de código y nube, y rotación rutinaria de credenciales. Si un paquete que instalaste resultó comprometido, cualquier secreto alcanzable desde esa máquina ya debe considerarse expuesto.

Conclusión

El rediseño de PyPI es una mejora real de transparencia: por primera vez, el estado de procedencia de una release está a un clic y con lenguaje entendible para quien no vive en la especificación de SLSA. Pero la lección del año es más dura. Un proyecto puede tener 2FA, Trusted Publishing y atestaciones firmadas en cada release y aun así ser comprometido. Las señales de seguridad de PyPI no reemplazan el criterio de tu equipo: lo hacen más rápido de aplicar. Para un equipo pequeño, con pocos ingenieros y mucha superficie de dependencias, eso ya es una ventaja competitiva concreta.