Actualizado el
La PEP 770 ya es estándar: reserva .dist-info/sboms para describir lo que esconden los wheels, y desde entonces ha ganado herramientas y adopción.
En agosto de 2025 se habló mucho de cómo Python afrontaba las dependencias fantasma, a raíz de un informe técnico de Seth Larson y de la cobertura posterior, como la de Slashdot. Conviene aclarar algo: la PEP 770 no era ya una simple propuesta, sino un estándar aceptado, con estado Final desde el 11 de abril de 2025. Pasado más de un año, toca ver qué ha ocurrido con ella.
El problema de fondo sigue siendo el mismo. Muchos paquetes de Python empaquetan componentes compilados que no son Python, escritos en Rust, C o C++, y las herramientas de análisis de composición de software no los ven. La propia PEP cita el caso de Pillow, que incluye 16 bibliotecas compartidas que herramientas como Syft y Grype no logran identificar. Sin metadatos, un escáner de vulnerabilidades no puede saber qué hay dentro.
La solución es deliberadamente modesta: reservar el directorio .dist-info/sboms dentro de los archivos de distribución para guardar documentos SBOM. Además, usa un directorio en lugar de un campo de metadatos, de modo que no hace falta coordinar el despliegue de una nueva versión de metadatos entre instaladores, constructores y el propio índice de paquetes.
Lo más interesante es lo que vino después. En su balance del 22 de diciembre de 2025, Larson cuenta que auditwheel 6.5.0, publicado a principios de noviembre, genera ya SBOM de forma automática según la PEP 770. Las imágenes manylinux adoptaron esa versión poco después, así que cibuildwheel y multibuild incluyen los datos por defecto. Su análisis encontró 332 proyectos de PyPI con SBOM en sus wheels; el primero, greenlet, suma 205 millones de descargas mensuales.
También hubo adopción fuera de PyPI. Miro Hroncok lideró la incorporación de la PEP 770 en Fedora y Red Hat para reducir falsos positivos en los escáneres de vulnerabilidades, usando URL de paquete precisas del estilo pkg:rpm/redhat/.... Y en marzo de 2026, sbomify señalaba que Hatchling 1.28.0 y posteriores la soportan de forma nativa mediante la opción sbom-files de pyproject.toml.
Nuestra lectura: lo valioso no es el formato, sino que los datos aparezcan sin esfuerzo del mantenedor. Que la generación ocurra en la herramienta de construcción, y no en manos de voluntarios con poco tiempo, es lo que convierte un estándar en práctica real. Queda por ver cuánto de la larga cola de proyectos acaba cubierto, pero el camino de adopción por defecto parece el correcto.
Artículos relacionados de LaRebelión
GLM-5.3, el modelo abierto chino que se acerca a Mythos en exploits
Por qué el estado es lo más difícil del diseño de software y cómo domarlo
ThreatsDay: inspeccionar un modelo puede ejecutar código y 543.699 secretos siguen vivosFuente original: Python Enhancement Proposals (python.org)
Elaborado con apoyo de IA y revisado por la redacción