Python wheels replaced eggs as the standard binary distribution format years ago. They are faster to install, more predictable, and better supported. But from a security perspective, wheels have verification gaps that most Python developers never think about.
When you run pip install requests, pip downloads a wheel file from PyPI, checks its hash against the package metadata, and installs it. That process sounds secure, but the devil is in the details.
How Wheel Verification Actually Works
A wheel file is a ZIP archive with a specific naming convention and internal structure. It contains the package code, metadata, and a RECORD file that lists every file in the wheel along with its SHA-256 hash.
When pip installs a wheel, it verifies the RECORD hashes to ensure the archive contents have not been tampered with during extraction. This protects against corruption, but not against a malicious publisher. The hashes in RECORD are generated by whoever built the wheel. If the builder is malicious, the hashes simply verify that you received the malicious code intact.
PyPI itself provides hash verification at the download level. When you use a requirements.txt with --hash mode or a lockfile with hashes, pip verifies the downloaded wheel against the expected hash. This is a meaningful security control, but it is opt-in. The default pip install does not perform this verification.
The Signing Problem
For years, PyPI supported PGP signatures on uploaded packages. Maintainers could sign their uploads, and consumers could theoretically verify those signatures. In practice, almost nobody did. The PGP ecosystem is notoriously difficult to use correctly, key management is a nightmare, and pip never integrated signature verification into its default workflow.
PyPI deprecated PGP signature uploads in 2023. The replacement is Sigstore-based signing through the Trusted Publishers mechanism. This is a significant improvement -- it ties package provenance to the CI/CD pipeline that built it, using OpenID Connect rather than long-lived PGP keys. But adoption is still in early stages, and verification is not yet part of the default pip behavior.
Platform Wheels and Binary Risk
Platform-specific wheels (those with tags like cp311-cp311-manylinux_2_17_x86_64) contain compiled binary code. This is necessary for packages with C extensions, but it means you are trusting pre-compiled binaries from the package maintainer.
You cannot easily audit compiled code. A source distribution (sdist) can at least be reviewed before building, but a wheel contains the final binary. If the build environment was compromised, or if the maintainer included malicious code in the binary but not the source, a wheel-only installation would be vulnerable.
The manylinux standard defines which system libraries a wheel can link against, but it does not provide any security guarantees about the wheel contents. A wheel that conforms to manylinux can still contain a cryptocurrency miner or a reverse shell.
The Build Environment Problem
Many popular Python packages use complex build systems involving Cython, CFFI, or direct C extension compilation. The build environment for these packages often includes compilers, system libraries, and build scripts that run arbitrary code.
When PyPI serves a pre-built wheel, you are trusting that the build environment was not compromised. For packages that use CI/CD (like GitHub Actions) to build and publish wheels, the Trusted Publishers mechanism provides some provenance verification. But many packages are still built on developer workstations and manually uploaded.
There is no standard mechanism for reproducing wheel builds. If you download a particular numpy wheel, you cannot easily verify that it was built from the tagged source code without modification. Reproducible builds in the Python ecosystem are technically possible but not widely practiced.
Practical Security Measures
Always use hash verification. Generate your requirements.txt with pip-compile from pip-tools, which includes hashes by default. The --require-hashes flag in pip refuses to install packages without hash verification.
Prefer Trusted Publisher packages. When choosing between packages, favor those that use PyPI Trusted Publishers mechanism. This provides verifiable provenance linking the package to a specific CI/CD pipeline and source repository.
Pin exact versions. Never use >= or ~= version specifiers in production deployments. Pin exact versions and update deliberately after review. Version ranges mean pip will automatically install new, potentially malicious versions.
Audit source distributions when possible. For security-critical dependencies, consider building from source distributions rather than installing pre-built wheels. This allows code review and ensures the binary matches the published source. Set --no-binary for specific packages in pip to force source builds.
Use a private package index. Tools like Artifactory, Nexus, or devpi can proxy PyPI and cache approved package versions. This provides an additional control point where you can scan packages before they reach developer workstations.
Monitor for new releases. When a package you depend on publishes a new version, review the changes before updating. Automated tools can diff package contents between versions and flag suspicious additions.
The Attestation Future
PyPI is moving toward build attestations that cryptographically link packages to their source code and build process. When fully deployed, this will allow pip to verify not just that a package has not been tampered with since publication, but that it was built from a specific commit in a specific repository by a specific CI/CD pipeline.
This is a significant improvement over the current state, but it requires widespread adoption by package maintainers and integration into default pip verification behavior. Until then, the practical measures listed above are your best defense.
How Safeguard.sh Helps
Safeguard.sh monitors your Python dependencies at every level -- from PyPI publication to wheel integrity to vulnerability tracking. We verify package provenance, detect suspicious version updates, and maintain a continuous inventory of your Python supply chain. When combined with our SBOM generation, you get complete visibility into what is running in your Python applications, including the compiled C extensions hidden inside platform wheels.