A single source distribution can force the installer to build that package to obtain metadata, which may reintroduce legacy behavior and execute arbitrary code. In practice, that means one weak link anywhere in the resolved tree can compromise the install flow, even if the top-level package is a wheel and appears safe at first glance.
Why one source distribution changes the installer’s behavior
A dependency tree that is otherwise made of wheels can still be pulled into a very different install path by a single source distribution. The installer now has to inspect and often build that package to learn its metadata and dependencies, which means the final outcome depends on more than just the top-level artifact you expected to install.
That shift matters because wheels are prebuilt and comparatively predictable, while source distributions may require running packaging code during resolution or build. Once the installer enters that path, the install is no longer a simple fetch-and-unpack operation. It becomes dependent on build tooling, build isolation, and whatever logic the package executes to reveal its metadata.
In supply-chain terms, one weak artifact can widen the blast radius for the whole resolution process. A package that appears safe at the root can still inherit risk from a transitive dependency if that dependency is only available as a source distribution. For a concrete example of how Python package ecosystem abuse can turn on installation-time execution, see the PyPI Breach and the LiteLLM PyPI package breach.
Where the real exposure comes from
The core issue is not just that a source distribution is slower or less convenient. It is that metadata discovery can require executing package-provided build steps, and those steps may behave differently from a wheel install. That creates room for legacy behavior, hidden side effects, and unexpected code paths to reappear in what should have been a straightforward dependency resolution.
The risk compounds when teams assume the top-level artifact defines the whole install trust posture. It does not. The installer must trust every artifact in the resolved tree, including the one package that was only published as a source distribution. If that package is compromised, malformed, or simply built with unsafe assumptions, it can affect the entire installation chain before the application ever runs.
- Source distributions can force metadata generation during install.
- Metadata generation can require package code to run.
- Any execution during that stage expands the trust boundary of the install.
That is why Python supply-chain guidance increasingly treats build-time behavior as part of the security surface, not just runtime imports. The broader open source ecosystem has formalised that concern through OpenSSF initiatives and supply-chain integrity work such as SLSA.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Covers controlling software install paths and reducing unsafe build-time behavior in dependencies. |
| CIS 16 — Application Software Security | Applies to supply-chain integrity and unsafe package behavior during build and install. | |
| Recommendation — Prefer verified wheel artifacts and harden software installation settings to reduce unexpected build execution. Review dependency sources and enforce checks that block packages requiring untrusted install-time code. | ||
| NIST CSF 2.0 | PR.IP-2 — Software Integrity and Security | Directly addresses integrity of software and dependencies throughout the build and install process. |
| ID.SR-1 — Supply Chain Risk Management Processes | Relevant because a single sdist can introduce supply-chain risk into an otherwise wheel-based tree. | |
| Recommendation — Validate dependency artifacts and require integrity checks before allowing installation. Assess dependency provenance and reject packages that weaken supply-chain trust assumptions. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Secrets and Credential Management | Relevant when package install-time execution can expose or steal credentials during dependency handling. |
| NHI-10 — Software Supply Chain and Third-Party Risk | Directly matches the risk that one transitive source distribution can compromise the install flow. | |
| Recommendation — Keep credentials out of build contexts and prevent install-time access to secrets. Enforce provenance and artifact verification for every transitive package before installation. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Models the abuse path where a malicious dependency or build artifact compromises installation. |
| Recommendation — Hunt for compromised dependency artifacts and block installation paths that rely on untrusted builds. | ||
Practitioner Guidance
What to verify: Treat “all wheels” as the preferred state, but verify every transitive dependency, not just the package you asked for directly. If any dependency is only available as an sdist, check whether the build step is deterministic, whether it needs network access, and whether it executes arbitrary code during metadata extraction or wheel creation.
Common mistake: Teams often validate the top-level package source and stop there. That misses the fact that dependency resolution can silently switch from passive installation to active build execution because of one transitive source distribution.
What good looks like: The install pipeline is able to prefer wheels, pin reproducible artifacts, and fail closed when a package would require unexpected build-time execution. Where sdist use is unavoidable, the build environment should be tightly isolated and monitored so metadata generation does not become an unreviewed execution path.
Practitioner takeaway: The security boundary is the full resolved tree, not the package you thought you were installing. One source distribution is enough to turn a “safe-looking” wheel install into a build-and-execute event.
Related resources from NHI Mgmt Group
- What breaks when a poisoned dependency is only one level deep in the Cargo tree?
- What happens when open source vulnerability management is attempted without dependency mapping and SBOM visibility?
- What happens when a legitimate looking open-source project is used as a dependency for a malicious package?
- How do organisations decide when to trust an audited open-source dependency?
