Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Public PyPI checks who published a package, not what the package does.
- SecureChain screens and rebuilds packages before they reach your environment.
- Rebuilt artifacts carry new hashes, so pinned requirements files need regenerating.
- Patching carries on after install, across the whole dependency tree.
Public PyPI verifies that uploads are authenticated and authorized for the project, and it publishes a hash for every uploaded file. What it doesn’t do is rebuild those files to prove their contents came from the source repository they point at, or look at whether the code is safe to run. That gap is what usually sends people hunting for a PyPI alternative – something that judges what a package does rather than only where it came from.
This post walks through where SecureChain for Python screens, rebuilds, and keeps patching after install, and where that coverage stops.
What Public PyPI Checks, and What a PyPI Alternative Adds
When pip installs from public PyPI, only a short list of checks applies, and none of them look at what a package will do once it lands in your environment.
Publishing a release requires an authenticated maintainer account. Every uploaded file gets a published hash, and pip does check the download against the hash the index hands it, which catches a mangled transfer. That hash travels with the file from the same source, though, so it proves the artifact arrived intact rather than that anyone vetted what’s inside it. Hash-checking mode is the stricter option, because with --require-hashes an index-supplied hash can’t satisfy the requirement. The artifact has to match a hash you approved locally.
Maintainers who opt into Trusted Publishing get short-lived OIDC credentials instead of a static API token, and PyPI can serve digital attestations that cryptographically bind an artifact to its publishing identity and, with SLSA provenance, to its source location. Those are useful provenance signals, and none of them establish that the artifact itself is benign. Once an authorized publishing credential or workflow is compromised, authentication alone can’t tell you anything about what came down that path, and PyPI’s reporting and quarantine process generally moves once a malicious release is already installable rather than screening artifacts before they go live.
A secure PyPI mirror that only relocates where packages download from inherits the same gap. That isn’t a Python-specific problem either. It’s the blind spot a lot of supply chain tooling never closes, where a package gets weighed against a hash and a CVE feed but never against what it actually does when it runs.
Screening Before Delivery, Not After
SecureChain analyzes the source code of a package before it’s ever delivered to a build agent or a machine belonging to a developer, flagging suspicious behavior and blocking anything that fails inspection. That’s a different point in the pipeline than most tooling works at. A scanner that only sees a dependency after it has been resolved or installed is reporting on something that already exists in the environment. Screening before delivery means a package that fails inspection never reaches the consuming environment at all.
Three incidents from 2026 show why that timing matters. LiteLLM shipped a credential stealer in March after a poisoned Trivy build in its own CI pipeline leaked the project’s PyPI token. In May, durabletask, Microsoft’s Durable Task SDK, was hit through an API token lifted out of GitHub Actions secrets. And in June, Hades reached PyPI with 37 malicious wheel artifacts, counted as 26 packages by Orca and 19 by Socket. Those wheels used .pth startup hooks that fire when the interpreter starts rather than on import, the same trick one of LiteLLM’s malicious releases had pulled three months earlier.
None of the three needed a bug in the application consuming the package. Each one rode an authorized publishing path, and authentication can confirm that a path is authorized without saying anything about whether the artifact coming down it is benign. The same campaign lineage runs back through Shai-Hulud’s spread across npm, which is the point. That pattern is what screening before delivery exists to catch, whichever ecosystem it turns up in next.
Rebuild From Source, and What That Actually Verifies
Most Python packages install from distribution artifacts that PyPI doesn’t independently rebuild to check against the source repository they claim to come from. A wheel can hash consistently, install cleanly, and still contain code the linked repository has never seen, because nothing in the packaging system forces a wheel to match its source.
SecureChain rebuilds packages from verified source in a controlled environment, so what installs traces back to that source instead of an opaque upstream binary. What that verification proves depends on the kind of package.
| Artifact type | Contains | Reconstruction fidelity |
|---|---|---|
| Pure Python wheel | Source files, no compilation | Close match, though zip metadata and timestamps differ |
| Wheel with compiled extensions | Platform-specific binaries built from C, C++, or Rust | Not byte-comparable, since the same source can compile differently across toolchains |
| Source distribution | Source tree plus packaging and build metadata | The most to compare against, though the build backend can run code during the build |
A pure Python wheel carries Python source and generated packaging metadata with no compiled binaries in it, so comparing a rebuild against the published wheel is mostly a file-level exercise. A wheel built from C, C++, or Rust extensions is compiled output tied to one toolchain and one platform, and rebuilding it produces a different binary rather than a matching one. That’s a real limit, and it applies to a meaningful share of what a data or ML team installs. Source distributions sit in between, less common day to day, but they expose the source and the build inputs directly, which gives a rebuild the most to work with.
So the honest framing for Python is tiered rather than uniform. Strong for pure Python, structurally useful for sdists, weaker for anything with compiled extensions. Claiming byte-exact reconstruction across all of PyPI would overstate what rebuilding can prove once compiled or environment-dependent output is in the mix.
What Rebuilding Does to Your Pinned Hashes
Hash pinning restricts each dependency to one or more explicitly approved artifact hashes.
pip-compile --generate-hashes requirements.in
pip install --require-hashes -r requirements.txtThose hashes are tied to specific files. Because SecureChain rebuilds packages from source rather than re-serving PyPI’s original artifact, a rebuilt package produces a different hash from the one PyPI published, even when the underlying source matches exactly. So switching brings a real migration step, since every pin covering a package SecureChain rebuilds has to be regenerated against the new index.
Plan for that before a pilot rather than during one. Regenerate requirements files against the new index in a single repository first, confirm the install succeeds and the application behaves the same way, then scope the rollout against how many repositories and pipelines carry pinned hashes today. The size of that list, not the concept of hash pinning, is what decides how big the migration actually is.
One Index URL, Not Two
Pointing pip at SecureChain comes down to a single setting, using the endpoint SecureChain provides for your account:
pip config set global.index-url https://<your-securechain-endpoint>/simple/Use index-url, not extra-index-url. pip has no concept of which index a package is supposed to come from. If both indexes offer compatible candidates for the same package name, pip weighs them together and can pick the higher-version public candidate, which is exactly the dependency-confusion risk --extra-index-url creates.
Check what’s actually configured on a CI runner rather than trusting the documentation. PIP_INDEX_URL and PIP_EXTRA_INDEX_URL set in the environment silently override pip.conf, and a base image inherited from another team is a common way one of those sneaks in unnoticed.
pip config list
pip config get global.index-urlPatched After You Install, Not Just Screened Before
Screening covers a package’s state at the moment it’s delivered. Most of a dependency’s life happens after that, and finding out later that something is wrong is a separate job from having a patched build of the version you’re actually running.
A single top-level package can pull in dozens of transitive dependencies through pip’s resolver, most of which nobody on the team reviewed directly, and any of which can introduce executable code and fresh vulnerabilities into the environment. SecureChain applies the same verification, screening, and patching across the full dependency graph, not just what shows up in requirements.txt.
New CVEs get disclosed against packages already sitting in a production stack, on a schedule nobody controls. Plenty of tools will tell you about them. SecureChain monitors those disclosures and delivers fixes aligned to the versions already pinned, which is the part that pip-audit output and manual advisory review leave on your desk.
Eventually a maintainer stops releasing. Public PyPI carries on hosting the existing releases, but nothing new gets patched from that point on, no matter what turns up later. TuxCare’s Endless Lifecycle Support backs SecureChain here, backporting fixes for packages already in the catalog, so a team doesn’t have to choose between an unpatched dependency and a rewrite nobody planned for.
Checking SecureChain Against Your Own Python Stack
Pull your own dependency tree, count how much of it is pure Python versus compiled extensions, and check how many repositories already run hash-checking mode. That’s the real shape of what switching to SecureChain for Python would mean for your stack, not a generic estimate.
Evaluating SecureChain as a Python package security tool comes down to matching these specifics against your own pipeline rather than a spec sheet. If the gaps covered here match what your last incident review turned up, request a quote for SecureChain for Python and get a straight answer on catalog coverage for your dependency tree.
FAQ
What is a PyPI alternative?
An index that serves Python packages to developers and build systems instead of public PyPI directly. Some options simply mirror or cache upstream packages, while others add controls such as screening and rebuilding, which closes gaps that plain mirroring leaves open.
Can pip install run malicious code?
Yes. Installing a source distribution can execute package-controlled build backend code while the package builds, and an installed package can run code later at import time or through startup mechanisms such as an executable .pth file, which is what the Hades wheels abused. SecureChain analyzes a package’s source code before delivery, flagging suspicious behavior and blocking malicious packages before they reach an environment.
Does a rebuilt package still match its upstream source?
It depends on the package type. Pure Python wheels contain no compiled binaries, so a rebuild can be compared against the published wheel fairly directly at the file level. Wheels with compiled C, C++, or Rust extensions are platform-specific build output, and rebuilding one produces a different binary rather than a matching one, even when the source is identical.
Will switching to SecureChain break my pinned hashes?
Yes, for any package it rebuilds. SecureChain serves rebuilt packages rather than re-serving PyPI’s original artifact, so the hashes differ from what public PyPI published even when the source matches. Regenerating pinned requirements files is a real step in the migration, not an edge case.
Does SecureChain cover transitive dependencies, not just what’s in requirements.txt?
Yes. A single direct dependency can pull in dozens of packages nobody reviewed directly, and those packages can introduce executable code and vulnerabilities into the environment. SecureChain applies verification, screening, and patching across the full dependency graph rather than only the top-level packages a team listed.
What happens when a Python package reaches end of life?
Nothing, which is the problem. Public PyPI doesn’t remove the package or flag it as unsupported, and old releases generally stay downloadable unless they’re pulled or quarantined for some other reason. What stops is upstream, which is no longer producing security fixes for the package once the maintainers walk away. SecureChain keeps patching cataloged packages past that point, so a package hitting end of life doesn’t automatically mean staying exposed or scrambling to replace it.
