They should track where a package came from, how it was imported, and which developer or workflow identities were exposed along the way. When public infrastructure is used for both delivery and command and control, provenance and runtime trust must be evaluated together instead of as separate reviews.
Why package provenance must cover both source and runtime trust
When GitHub and PyPI both participate in delivery, provenance is not just “which repository did this come from?” It is the chain of custody from source commit to published artifact to the way the package is consumed, mirrored, or executed. That means teams have to treat repository trust, package registry trust, and downstream execution trust as one control problem, not three separate reviews.
A package can look legitimate at the registry layer while still carrying risk from a compromised workflow, a leaked publishing credential, or an attacker-inserted release process. That is why governance has to follow the artifact across both systems and preserve evidence about who published it, how it was signed or transferred, and whether the package retained the expected contents between build and install.
For teams operating in Python ecosystems, that cross-system view is especially important because package publication, repository automation, and developer credentials often overlap. A good provenance model asks not only “is this the right package name?” but also “is this the right build path, from the right identity, using the right release process?” The Ultralytics PyPI compromise is a clear example of why GitHub-side workflow trust and PyPI-side publishing trust have to be assessed together.
What good provenance governance should record
Provenance governance should capture the minimum facts needed to reconstruct trust decisions later. At a practical level, that includes the source repository, the commit or release tag, the build workflow, the publishing identity, the package hash or signature where available, and any approvals or exceptions that allowed the artifact to move forward. If any one of those is missing, you have a gap in the chain, even if the package is otherwise consumable.
This is also where teams should separate “published by a trusted workflow” from “safe to use forever.” A package may be built correctly and still become unsafe if credentials used in the pipeline are overexposed, if publishing secrets are long-lived, or if the repository branch protections do not match the release path. The PyPI admin GitHub token leak 2024 shows why the publishing identity and its secrets deserve the same scrutiny as the package contents themselves.
Teams should also remember that provenance is not only about origin, it is about persistence. A malicious or careless artifact can keep circulating after the original issue is fixed, so governance should include how packages are revoked, yanked, superseded, or rotated in dependency locks and internal mirrors. PyPI secrets exposure 2023 is a reminder that a published package can preserve sensitive material long after the intended release moment.
How to govern the GitHub to PyPI trust boundary
The trust boundary is the release pipeline itself. If GitHub Actions, release automation, or maintainer credentials can publish to PyPI, then the workflow identity becomes part of the package’s security posture. Teams should govern that identity with the same seriousness they apply to privileged human accounts: narrowly scoped permissions, short-lived credentials where possible, and explicit controls around who can trigger a release or update a publishing secret.
It is also useful to treat public infrastructure as a shared threat surface. When the same systems are used for code delivery and for malicious command and control, defenders should assume an attacker may exploit normal developer workflows rather than bypass them outright. That makes release integrity, secret hygiene, and post-publish monitoring part of the same control set. TrapDoor supply chain campaign 2026 illustrates how malicious packages can ride ordinary ecosystem trust and still steal credentials or seed further abuse.
Where package provenance depends on CI/CD automation, teams should also verify that build-time and publish-time identities are distinct from day-to-day developer identities. If the same credential can both modify source and publish the artifact, the provenance trail becomes weaker and incident response becomes harder. Miasma and Hades Supply Chain Worms show why credential reuse and propagation across ecosystems can turn a single compromise into a broader trust failure.
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 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Package provenance and build integrity are the core subject here. |
| Recommendation — Adopt provenance controls that tie each release to a verified build path and attestable artifact. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Publishing and release credentials are central to the GitHub-to-PyPI trust chain. |
| AC-6 — Least Privilege | Release workflows should not have more privilege than required to build and publish. | |
| Recommendation — Rotate and tightly scope publishing credentials used to release packages. Limit release workflow and maintainer permissions to the minimum needed. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Leaked publishing tokens directly weaken package provenance and release trust. |
| NHI-07 — Long-Lived Secrets | Long-lived registry and CI credentials are a common provenance failure mode. | |
| Recommendation — Scan, rotate, and revoke any secrets exposed in build or release paths. Replace durable publishing secrets with short-lived or tightly governed credentials. | ||
Practitioner Guidance
What to prioritise: Tie release governance to the identity that published the package, not just the repository that hosted the code. If you cannot explain which workflow, which credential, and which approval path produced the artifact, provenance is incomplete.
What to verify: Check that the GitHub release path, the PyPI publication path, and the dependency consumer path all point to the same expected artifact hash or signature. Mismatches between those three views are usually more important than cosmetic metadata differences.
Common mistake: Treating “publicly visible source” as equivalent to “trusted source.” A clean repository does not compensate for a compromised publishing workflow, and a trusted registry entry does not prove the artifact still reflects the intended source state.
Practitioner takeaway: Good provenance governance follows the package across identities, systems, and release steps, because the attack surface is the handoff between them, not any single platform in isolation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org