Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- PyPI público comprueba quién ha publicado un paquete, no qué hace dicho paquete.
- SecureChain revisa y recompila los paquetes antes de que lleguen a tu entorno.
- Los artefactos recompilados tienen nuevos hash, por lo que es necesario volver a generar los archivos de requisitos fijados.
- La aplicación de parches continúa tras la instalación, en todo el árbol de dependencias.
PyPI público verifica que las subidas estén autenticadas y autorizadas para el proyecto, y publica un hash de cada archivo subido. Lo que no hace es reconstruir esos archivos para demostrar que su contenido procede del repositorio de origen al que apuntan, ni comprueba si el código es seguro para su ejecución. Esa carencia es lo que suele llevar a la gente a buscar una alternativa a PyPI: algo que evalúe lo que hace un paquete, en lugar de limitarse a comprobar de dónde procede.
En esta entrada se explica dónde interviene SecureChain para Python —analizando, recompilando y aplicando parches tras la instalación— y dónde termina su ámbito de actuación.
Qué comprueba el PyPI público y qué aporta una alternativa al PyPI
Cuando se realiza una instalación con «pip» desde el repositorio público de PyPI, solo se aplican unas pocas comprobaciones, y ninguna de ellas analiza qué hará el paquete una vez que se haya instalado en tu entorno.
Para publicar una versión se necesita una cuenta de administrador autenticada. A cada archivo subido se le asigna un hash de publicación, y pip compara la descarga con el hash que le proporciona el índice, lo que permite detectar una transferencia dañada. Sin embargo, ese hash acompaña al archivo desde la misma fuente, por lo que demuestra que el artefacto ha llegado intacto, pero no que alguien haya comprobado su contenido. Modo de comprobación de hash es la opción más estricta, porque con --require-hashes Un hash proporcionado por el índice no cumple con el requisito. El artefacto debe coincidir con un hash que hayas aprobado localmente.
Los mantenedores que se acogen al programa «Trusted Publishing» obtienen credenciales OIDC de corta duración en lugar de un token de API estático, y PyPI puede proporcionar certificaciones digitales que vinculan criptográficamente un artefacto a su identidad de publicación y, mediante la procedencia SLSA, a su ubicación de origen. Se trata de señales de procedencia útiles, pero ninguna de ellas garantiza que el propio artefacto sea inofensivo. Una vez que se ve comprometida una credencial de publicación autorizada o un flujo de trabajo, la autenticación por sí sola no puede revelar nada sobre lo que ha llegado a través de esa vía, y el proceso de notificación y cuarentena de PyPI suele activarse cuando una versión maliciosa ya está lista para su instalación, en lugar de filtrar los artefactos antes de que se publiquen.
Un servidor espejo seguro de PyPI que solo redirige la ubicación desde la que se descargan los paquetes hereda esa misma laguna. Tampoco se trata de un problema específico de Python. Es el punto ciego que muchas herramientas de la cadena de suministro nunca logran subsanar, en el que un paquete se compara con un hash y una fuente de datos CVE, pero nunca con lo que realmente hace cuando se ejecuta.
Pruebas de detección antes del parto, no después
SecureChain analiza el código fuente de un paquete antes incluso de que se envíe a un agente de compilación o a un equipo de un desarrollador, señalando comportamientos sospechosos y bloqueando todo aquello que no supere la inspección. Se trata de un punto del proceso diferente al que suelen actuar la mayoría de las herramientas. Un escáner que solo detecta una dependencia después de que se haya resuelto o instalado está informando sobre algo que ya existe en el entorno. La detección previa al envío implica que un paquete que no supere la inspección nunca llega al entorno de ejecución.
Tres sucesos ocurridos en 2026 demuestran por qué ese momento es importante. LiteLLM distribuyó un programa para robar credenciales en marzo después de que una versión maliciosa de Trivy en su propio proceso de integración continua filtrara el token de PyPI del proyecto. En mayo, tarea duradera, el SDK de tareas duraderas de Microsoft, sufrió un ataque a través de un token de API sustraído de los secretos de GitHub Actions. Y en junio, Hades ya está disponible en PyPI con 37 artefactos «wheel» maliciosos, contabilizados como 26 paquetes por Orca y 19 por Socket. Esos «wheel» utilizaban .pth ganchos de inicio que se activan al arrancar el intérprete, en lugar de al importar el módulo, el mismo truco que había utilizado una de las versiones maliciosas de LiteLLM tres meses antes.
Ninguno de los tres necesitaba un error en la aplicación que utilizaba el paquete. Cada uno siguió una ruta de publicación autorizada, y la autenticación permite confirmar que una ruta está autorizada sin decir nada sobre si el artefacto que se descarga a través de ella es inofensivo. El mismo linaje de la campaña se remonta a la propagación de Shai-Hulud a través de npm, y ese es precisamente el punto. Ese patrón es precisamente lo que las comprobaciones previas a la entrega pretenden detectar, sea cual sea el ecosistema en el que aparezca a continuación.
Recompilar desde el código fuente y qué es lo que realmente se comprueba con ello
La mayoría de los paquetes de Python se instalan a partir de artefactos de distribución que PyPI no recompila de forma independiente para comprobar que coinciden con el repositorio de código fuente del que dicen proceder. Un archivo «wheel» puede generar un hash coherente, instalarse correctamente y, aun así, contener código que el repositorio vinculado nunca ha visto, ya que nada en el sistema de empaquetado obliga a que un archivo «wheel» coincida con su código fuente.
SecureChain recompila los paquetes a partir de una fuente verificada en un entorno controlado, de modo que lo que se instala se remonta a esa fuente en lugar de a un binario opaco de origen. Lo que demuestra esa verificación depende del tipo de paquete.
| Tipo de artefacto | Contiene | Fidelidad de la reconstrucción |
|---|---|---|
| Wheel de Python puro | Archivos fuente, sin compilar | Son muy parecidos, aunque los metadatos ZIP y las marcas de tiempo difieren |
| Rueda con extensiones compiladas | Archivos binarios específicos para cada plataforma compilados a partir de C, C++ o Rust | No es comparable a nivel de byte, ya que el mismo código fuente puede compilarse de forma diferente según el conjunto de herramientas utilizado. |
| Distribución del código fuente | Árbol de código fuente, además de los metadatos de empaquetado y compilación | Es lo más parecido con lo que se puede comparar, aunque el backend de compilación puede ejecutar código durante la compilación |
Un archivo «wheel» puro de Python contiene el código fuente de Python y los metadatos de empaquetado generados, sin binarios compilados, por lo que comparar una nueva compilación con el archivo «wheel» publicado es, en gran medida, una tarea a nivel de archivos. Un «wheel» creado a partir de extensiones de C, C++ o Rust es un resultado compilado vinculado a una cadena de herramientas y a una plataforma concretas, y su recompilación produce un binario diferente en lugar de uno idéntico. Esa es una limitación real, y se aplica a una parte significativa de lo que instalan los equipos de datos o de aprendizaje automático. Las distribuciones de código fuente se sitúan en un término medio; aunque son menos habituales en el día a día, exponen directamente el código fuente y los datos de compilación, lo que proporciona a la recompilación la mayor cantidad de información con la que trabajar.
Por lo tanto, el enfoque realista para Python es escalonado, en lugar de uniforme. Es sólido para Python puro, útil desde el punto de vista estructural para los sdists y más débil para cualquier cosa que incluya extensiones compiladas. Afirmar que es posible una reconstrucción exacta al byte en todo PyPI supondría exagerar lo que la recompilación puede demostrar una vez que se incluyen resultados compilados o dependientes del entorno.
Cómo afecta la reconstrucción a tus hash fijados
La fijación de hash limita cada dependencia a uno o varios hash de artefactos aprobados explícitamente.
pip-compile --generate-hashes requirements.in
pip install --require-hashes -r requirements.txtEsos hash están vinculados a archivos concretos. Dado que SecureChain recompila los paquetes a partir del código fuente en lugar de volver a servir el artefacto original de PyPI, un paquete recompilado genera un hash diferente al publicado por PyPI, incluso cuando el código fuente subyacente coincide exactamente. Por lo tanto, el cambio supone un auténtico proceso de migración, ya que cada referencia que cubra un paquete recompilado por SecureChain debe regenerarse en función del nuevo índice.
Planifícalo antes de una prueba piloto, en lugar de durante la misma. Primero, regenera los archivos de requisitos según el nuevo índice en un único repositorio; comprueba que la instalación se realice correctamente y que la aplicación funcione igual que antes; a continuación, determina el alcance de la implementación en función del número de repositorios y procesos que actualmente tienen hash fijados. El tamaño de esa lista, y no el concepto de fijación de hash, es lo que determina la magnitud real de la migración.
Una URL de índice, no dos
Para configurar Pip en SecureChain basta con un único ajuste, utilizando el punto final que SecureChain proporciona para tu cuenta:
pip config set global.index-url https://<your-securechain-endpoint>/simple/Utilice index-url, no extra-index-url. pip no tiene en cuenta de qué índice se supone que procede un paquete. Si ambos índices ofrecen candidatos compatibles para el mismo nombre de paquete, pip los evalúa conjuntamente y puede elegir el candidato público de mayor versión, lo que supone precisamente el riesgo de confusión en las dependencias --extra-index-url crea.
Comprueba qué está configurado realmente en un ejecutor de CI, en lugar de fiarte de la documentación. PIP_INDEX_URL y PIP_EXTRA_INDEX_URL establecer en el entorno, anular de forma silenciosa pip.conf, y una imagen base heredada de otro equipo es una forma habitual de que algo así se cuele sin que nadie se dé cuenta.
pip config list
pip config get global.index-urlSe corrigen los errores tras la instalación, no solo se revisan antes
La comprobación abarca el estado de un paquete en el momento de su entrega. La mayor parte del ciclo de vida de una dependencia tiene lugar a partir de ese momento, y descubrir más tarde que algo va mal es una tarea distinta a disponer de una versión parcheada de la que realmente estás utilizando.
Un solo paquete de nivel superior puede incorporar docenas de dependencias transitivas a través del resolutor de pip, la mayoría de las cuales nadie del equipo ha revisado directamente, y cualquiera de ellas puede introducir código ejecutable y nuevas vulnerabilidades en el entorno. SecureChain aplica los mismos procesos de verificación, filtrado y aplicación de parches a todo el gráfico de dependencias, no solo a lo que aparece en requirements.txt.
Se publican nuevas vulnerabilidades CVE en paquetes que ya forman parte de una pila de producción, según un calendario que nadie controla. Hay muchas herramientas que te informan de ellas. SecureChain supervisa esas publicaciones y ofrece soluciones adaptadas a las versiones ya fijadas, que es precisamente lo que la salida de pip-audit y la revisión manual de los avisos de seguridad dejan pendiente en tu mesa.
Con el tiempo, un responsable del mantenimiento deja de publicar nuevas versiones. El repositorio público PyPI sigue alojando las versiones existentes, pero a partir de ese momento no se aplican parches a nada nuevo, independientemente de lo que surja más adelante. El servicio «Endless Lifecycle Support» de TuxCare respalda a SecureChain en este aspecto, adaptando las correcciones a los paquetes que ya figuran en el catálogo, de modo que un equipo no tenga que elegir entre una dependencia sin parches y una reescritura que nadie había previsto.
Comparación de SecureChain con tu propia pila de Python
Genera tu propio árbol de dependencias, calcula qué parte corresponde a Python puro y qué parte a extensiones compiladas, y comprueba cuántos repositorios ya funcionan en modo de verificación de hash. Esa es la imagen real de lo que supondría para tu pila de aplicaciones el cambio a SecureChain para Python, no una estimación genérica.
Para evaluar SecureChain como herramienta de seguridad para paquetes de Python, lo fundamental es comparar estas características concretas con tu propio proceso de trabajo, en lugar de limitarte a una ficha técnica. Si las carencias que aquí se mencionan coinciden con lo que se detectó en tu última revisión de incidentes, solicita un presupuesto de SecureChain para Python y obtén una respuesta clara sobre la cobertura del catálogo para tu árbol de dependencias.
PREGUNTAS FRECUENTES
¿Qué es una alternativa a PyPI?
Un índice que proporciona paquetes de Python a los desarrolladores y a los sistemas de compilación, en lugar de hacerlo directamente a través del PyPI público. Algunas opciones se limitan a replicar o almacenar en caché los paquetes originales, mientras que otras añaden controles como la selección y la recompilación, lo que subsana las deficiencias que deja la simple réplica.
¿Puede «pip install» ejecutar código malicioso?
Sí. Al instalar una distribución de código fuente, se puede ejecutar código del backend de compilación controlado por el paquete mientras se compila este, y un paquete instalado puede ejecutar código posteriormente, en el momento de la importación o a través de mecanismos de inicio, como un ejecutable. .pth archivo, que es precisamente lo que aprovechaban las ruedas de Hades. SecureChain analiza el código fuente de un paquete antes de su entrega, detectando comportamientos sospechosos y bloqueando los paquetes maliciosos antes de que lleguen a un entorno.
¿Sigue coincidiendo un paquete recompilado con su código fuente original?
Depende del tipo de paquete. Los «wheels» de Python puro no contienen binarios compilados, por lo que una nueva compilación se puede comparar con el «wheel» publicado de forma bastante directa a nivel de archivos. Los «wheels» con extensiones compiladas en C, C++ o Rust son resultados de compilación específicos de cada plataforma, y al recompilar uno se obtiene un binario diferente en lugar de uno idéntico, incluso cuando el código fuente es el mismo.
¿El cambio a SecureChain afectará a mis hash fijados?
Sí, se vuelve a compilar cualquier paquete. SecureChain ofrece paquetes recompilados en lugar de volver a servir el artefacto original de PyPI, por lo que los hash difieren de los publicados en PyPI, incluso cuando el código fuente coincide. La regeneración de los archivos de requisitos fijados es un paso fundamental en la migración, no un caso aislado.
¿SecureChain tiene en cuenta las dependencias transitivas, y no solo las que figuran en el archivo requirements.txt?
Sí. Una sola dependencia directa puede acarrear docenas de paquetes que nadie ha revisado directamente, y esos paquetes pueden introducir código ejecutable y vulnerabilidades en el entorno. SecureChain aplica procesos de verificación, filtrado y aplicación de parches en todo el gráfico de dependencias, en lugar de limitarse únicamente a los paquetes de nivel superior que haya enumerado un equipo.
¿Qué ocurre cuando un paquete de Python llega al final de su ciclo de vida?
Nada, y ahí radica el problema. El PyPI público no elimina el paquete ni lo marca como «sin soporte», y las versiones antiguas suelen seguir estando disponibles para su descarga, a menos que se retiren o se pongan en cuarentena por algún otro motivo. Lo que se detiene es el desarrollo original, que deja de producir correcciones de seguridad para el paquete una vez que los mantenedores abandonan el proyecto. SecureChain sigue aplicando parches a los paquetes catalogados más allá de ese punto, por lo que el hecho de que un paquete llegue al final de su vida útil no significa automáticamente que quede expuesto o que haya que apresurarse a sustituirlo.
