The mistake is assuming pyproject.toml removes execution risk entirely. It improves packaging clarity, but installers may still encounter source distributions in the dependency tree and fall back to building them to determine metadata. If any dependency is only available as an sdist, the install path can still execute arbitrary code during resolution or build time.
Why pyproject.toml helps, but does not make installs inherently safe
pyproject.toml is an important packaging improvement because it makes build requirements and project metadata more explicit. The common mistake is treating that structure as a safety guarantee. Installers still have to resolve dependencies, and if any dependency is only available as an sdist, the build step can execute code while deriving metadata or preparing the package.
That means the trust boundary has not moved out of the install path. It has only become clearer. A modern installer can prefer wheels, read declared metadata, and follow build standards, but it still cannot assume every transitive dependency is already in a harmless, prebuilt form. The risk appears when a dependency chain forces a fallback to source.
For teams, the key distinction is between packaging clarity and execution safety. A project can be well described and still pull in an sdist from a dependency, a private index, or a build backend that runs code during resolution. The presence of pyproject.toml should be treated as one control layer, not as proof that installation is non-executable.
Where the execution risk actually lives in the dependency tree
The dangerous assumption is often made at the top level, but the real exposure is usually transitive. Your own project may publish clean wheels and a tidy pyproject.toml, yet a downstream dependency can still force source builds. That is especially relevant when metadata is not fully available in a wheel-only form, when a backend must be invoked to inspect dependencies, or when an installer needs to build from source to continue resolution.
In practice, the risk is not that every installation runs arbitrary code, but that some installs cannot be completed without invoking package build logic. That logic may be legitimate, but it is still code execution. If the source package, build backend, or build environment is compromised, the install process becomes an attack surface rather than a passive file copy.
Teams should also separate repository hygiene from artifact trust. A dependency tree that looks compliant at the project level can still contain packages that are not safe to treat as inert artifacts. When you see source builds in the chain, you should assume the install pipeline may need build-time scrutiny, not just metadata validation.
The supply-chain pattern is well illustrated by incidents such as the PyPI Breach and the LiteLLM PyPI package breach, where package ecosystem trust was abused to reach developers and their environments.
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 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 6 — Access Control Management | Controls software install trust paths and restricts unverified execution sources. |
| CIS 16 — Application Software Security | Covers supply-chain hardening and validation of software components before deployment. | |
| Recommendation — Require approved artifact sources and restrict installs that would execute untrusted build steps. Validate packages, dependencies, and build inputs before allowing them into production workflows. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Addresses secure software acquisition and handling of build-time trust decisions. |
| SR — Supply Chain Risk Management | Directly applies to dependency-source trust and build-time exposure in package installs. | |
| Recommendation — Define package intake rules that distinguish metadata clarity from execution-safe installation. Assess dependency provenance and require controls for source builds in the supply chain. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Secret Leakage and Exposure | Relevant where package installs can expose developer or build secrets during malicious execution. |
| Recommendation — Block install paths that could expose secrets during dependency resolution or source builds. | ||
Practitioner Guidance
What to verify: Check whether your install path can still fall back to sdists anywhere in the dependency graph, not just in the top-level package. If you rely on lockfiles or build isolation, confirm they cover transitive packages and do not merely document them.
Decision rule: If a package may be built from source during install, treat it as potentially executable code and require the same review posture you would use for build-time dependencies. If you need deterministic installs, prefer prebuilt wheels, pinned hashes, and sources with predictable metadata.
Common mistake: Teams often equate “uses pyproject.toml” with “safe to install.” The better mental model is that pyproject.toml improves clarity and build standardisation, but safety still depends on what the resolver must execute to complete the install.
Practitioner takeaway: pyproject.toml reduces ambiguity, not execution risk. If resolution can still trigger source builds, the install path remains a code-execution boundary that must be governed explicitly.
Related resources from NHI Mgmt Group
- What do security teams get wrong about using package version checks as their main supply chain defense?
- What do teams get wrong about using cookies and tokens to keep sessions safe?
- What do teams get wrong about using Sanctum or Breeze for B2B SaaS?
- What do security teams get wrong about using AI agents for threat hunting?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
