Estás en el blog de Nicolau Roca
PyPI: qué hacer cuando cambia el publicador
Cómo evaluar cambios de publicador y pérdida de atestaciones en paquetes Python, sin confundir procedencia válida con código seguro.
La actualización de una dependencia pasa las pruebas. El nombre del paquete es el esperado, la versión es nueva y el archivo tiene una atestación criptográficamente válida. Solo ha cambiado un detalle: ahora lo publica otro repositorio.
Puede ser una migración legítima. Puede reflejar un cambio de organización. También puede ser justo la señal que nuestro control de procedencia pretendía detectar. Si la automatización solo pregunta «¿tiene firma válida?», las tres explicaciones reciben la misma respuesta antes de que nadie haya comprobado cuál corresponde.
La procedencia necesita una expectativa independiente del archivo que estamos evaluando. Una prueba válida permite comprobar una relación entre un artefacto y una identidad. Aceptar esa identidad, y aceptar que sustituya a la anterior, son decisiones adicionales.
Qué prueba una atestación de publicación de PyPI
El modelo de seguridad de PyPI distingue expresamente procedencia y confianza. La atestación básica vincula la distribución con un publicador autorizado. No certifica que su código sea benigno ni excluye una alteración anterior o durante la construcción. Tampoco reemplaza los controles sobre quién puede ejecutar el proceso de publicación.
La distinción importa porque hay dos preguntas diferentes: «¿este archivo corresponde a quien lo publicó?» y «¿es esa la procedencia que hemos decidido aceptar?». Resolver la primera ayuda mucho a resolver la segunda, pero no la contesta por nosotros.
La guía de verificación de PyPI ilustra precisamente esa separación: el verificador recibe el repositorio esperado, contrasta la identidad y verifica el artefacto frente a las atestaciones. La expectativa no se obtiene aceptando sin más cualquier repositorio que aparezca en la evidencia descargada.
Para un equipo consumidor, esto significa que una política de dependencias no termina en activar una opción del instalador. Debe decidir de dónde procede la identidad esperada, quién puede cambiarla y qué ocurre si una actualización ya no aporta la misma evidencia.
La evidencia también puede desaparecer sin que haya un ataque
Un estudio original de EasyxLab, publicado el 3 de octubre de 2026 y actualizado el día 5, encontró una versión más reciente con algún archivo atestado en 3.479 de 14.995 proyectos analizables de una selección de 15.000 paquetes populares de PyPI: un 23,2 %. La recogida corresponde al 2 de octubre y excluye archivos subidos después del 1 de octubre a las 12:40:51 UTC. No es una tasa de protección de todas las instalaciones de Python.
El trabajo también estudia proyectos que dejaron de atestar. Es un borrador realizado por agentes de IA, incluida la clasificación y revisión; utiliza una población basada en descargas recientes y reconoce limitaciones como examinar un archivo por versión para cambios de publicador. La cooperativa responsable desarrolla una herramienta relacionada. Es evidencia exploratoria para investigar transiciones, no una estimación de paquetes comprometidos ni una validación humana independiente.
La consecuencia práctica merece atención aunque no aceptemos ninguna extrapolación: un proyecto que antes aportaba evidencia puede dejar de hacerlo. En nuestro proceso de admisión, «nunca tuvimos esa garantía» y «acaba de desaparecer una garantía que utilizábamos» no deberían ser estados indistinguibles.
Imagina que el mantenedor cambia su automatización de publicación y omite un paso. Bloquear una actualización puede ser razonable mientras se aclara, pero acusar al proyecto de estar comprometido no se deduce de esa ausencia. La investigación debe poder concluir que hay una regresión de evidencia sin inventar una intrusión.
La unidad de aceptación es el archivo que instalamos
Una versión de un paquete puede ofrecer una distribución de código fuente y varios archivos preparados para plataformas diferentes. Si producción instala uno de ellos, la evidencia de otro no cubre por asociación el archivo elegido. Una etiqueta verde junto al nombre del proyecto puede resultar demasiado gruesa para una política de despliegue.
Por eso el registro de aceptación debe identificar el artefacto exacto y su resumen criptográfico, además de la versión. También debe conservar la expectativa de procedencia utilizada al decidir. Un hash permite fijar bytes; por sí solo no explica por qué aceptamos esos bytes ni demuestra que su autor sea quien creemos.
Esta precisión evita una falsa sensación de continuidad. Podemos mantener el mismo número de versión y cambiar de distribución al actualizar el entorno de ejecución. El cambio relevante para nuestro control ocurre en el archivo resuelto, aunque el nombre que ve el equipo en el inventario permanezca igual.
Una matriz de transición de procedencia
Propongo revisar las actualizaciones con esta matriz. Es una política de admisión que cada equipo debe ajustar al riesgo de su entorno, no una clasificación de la honestidad de los mantenedores.
| Situación observada | Decisión que falta |
|---|---|
| Atestación válida y publicador esperado. | Continuar con los controles de código, vulnerabilidades y compatibilidad. La procedencia supera su comprobación; no las demás. |
| Atestación válida y publicador diferente. | Retener la transición hasta contrastar su legitimidad por una vía independiente y registrar quién modifica la expectativa. |
| Antes había atestación; el artefacto nuevo no la tiene. | Investigar la pérdida y decidir una excepción temporal o mantener la versión aceptada, considerando también el riesgo de no actualizar. |
| La verificación falla. | Separar falta de conectividad, evidencia incompleta e incompatibilidad criptográfica. No convertir cualquier error del verificador en «sin atestación». |
| No existía evidencia previa. | Aplicar la política inicial de incorporación. La ausencia histórica no se convierte en una garantía por repetición. |
La matriz obliga a resolver un caso incómodo: una versión aceptada puede tener una vulnerabilidad y la corrección llegar sin la evidencia habitual. «Fijar siempre la anterior» sería una política sencilla, pero podría aumentar el riesgo que intentamos reducir. Una excepción debería identificar el archivo, el motivo, los controles compensatorios y la condición que permitirá cerrarla. No necesita convertirse en una autorización indefinida para cualquier actualización futura.
Al verificar una migración legítima, conviene evitar la circularidad de usar únicamente el mismo canal cuya continuidad estamos poniendo en duda. El anuncio del nuevo repositorio puede ser una pista; la aceptación necesita apoyarse en la relación de confianza que el equipo ya tenía y en evidencia suficiente para ese cambio concreto. Si no existe, la incertidumbre permanece.
Automatizar la comparación, hacer explícita la excepción
Un control útil conserva el último artefacto aceptado, detecta qué dimensión cambió y entrega al responsable una diferencia comprensible. «No cumple seguridad» aporta poco. «El archivo resuelto ya no tiene atestación; la versión anterior sí la tenía» permite investigar sin confundir hechos y sospechas.
Esto también evita trasladar trabajo invisible a quienes mantienen proyectos abiertos, un problema que ya aparecía al analizar el coste de reparar vulnerabilidades descubiertas con IA. Nuestro requisito interno no demuestra que exista un defecto externo, y un informe preciso resulta más útil que una alarma acusatoria.
La actualización inicial puede terminar aprobada. Incluso puede mejorar el proceso de publicación. Lo importante es que la decisión deje de depender de una insignia y pase a sostener una afirmación concreta: estos bytes proceden de esta identidad, ese cambio de identidad está explicado y aceptamos este artefacto bajo estas condiciones. La criptografía aporta una parte de la respuesta. El resto sigue siendo una decisión de ingeniería.
