What is the difference between Trusted Publishing and storing package credentials in repository secrets?

Why This Matters for Security Teams

The difference is not just operational convenience. It is a change in trust model. trusted publishing uses an identity assertion at release time, usually through OIDC, so the package ecosystem can verify who is releasing without handing over a long-lived secret. Repository secrets, by contrast, place a reusable credential in a storage location that becomes a standing target for misuse, theft, and unintended reuse.

That matters because package publishing is part of the software supply chain, where a single compromised credential can affect many downstream consumers. Security teams that treat both approaches as equivalent often miss the larger control objective: reducing standing secret exposure and tying release authority to a verifiable workload identity. That aligns with the control intent reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, authentication, and integrity protection.

The practical issue is not whether a token can be protected. It is whether it needs to exist at all outside the release event. In practice, many security teams encounter credential abuse only after a repository secret has already been copied, reused, or exfiltrated, rather than through intentional release governance.

How It Works in Practice

Trusted Publishing typically works by establishing a federated trust relationship between the package repository and the CI or release system. The publisher does not store a long-lived token in the repository. Instead, the platform vouches for the workflow identity at the moment of release, and the package service exchanges that identity for a short-lived publishing grant. This reduces credential lifecycle burden and narrows replay opportunity.

Repository secrets follow a different pattern. A maintainer stores a token, API key, or similar credential in the repository or in the CI system. The build or release job retrieves that secret at runtime and uses it to authenticate to the package registry. This is straightforward to implement, but it increases exposure because the same secret may be accessible to multiple workflows, people, or automation paths.

Operationally, the distinction affects governance as much as technical design:

• Trusted Publishing supports stronger release provenance because the action is bound to an authenticated workload identity.
• Repository secrets require rotation discipline, scope review, and leak monitoring because the credential itself is the asset.
• Short-lived credentials reduce the impact of accidental disclosure, but they still depend on correct federation and trust configuration.
• Static secrets can be simple for legacy pipelines, yet they expand the attack surface described in the OWASP Non-Human Identity Top 10, especially where service identities and automation secrets are weakly governed.

From an identity standpoint, this is a non-human identity problem as much as a publishing problem. The release workflow is effectively an identity that needs scoping, lifecycle management, and assurance. Best practice is evolving, but current guidance strongly favors ephemeral assertions over stored credentials wherever the platform supports it. These controls tend to break down when older CI systems cannot support federated identity or when organisations allow broad repository write access because release automation and human maintenance paths have not been separated.

Common Variations and Edge Cases

Tighter release controls often increase setup overhead, requiring organisations to balance faster adoption against stronger assurance. Some ecosystems support Trusted Publishing natively, while others still rely on repository secrets because federation is not available, package tooling is inconsistent, or release workflows are too customised to refactor quickly. That is a real tradeoff, not a sign that one model is universally wrong.

There is no universal standard for this yet across every registry and build platform. In some environments, a phased approach is most realistic: start by reducing the number of stored secrets, scope any remaining tokens to the minimum required action, and move release paths toward federated identity as the platform matures. For human account assurance and step-up authentication around release approvals, NIST SP 800-63 Digital Identity Guidelines can help teams distinguish between identity proofing, authentication strength, and session assurance.

Edge cases also matter. Emergency hotfix releases, self-hosted runners, mirrored registries, and multi-tenant build environments may require temporary exceptions or additional guardrails. The key question is whether the exception is documented and bounded, or whether it silently becomes the default. Where package signing, provenance checks, and identity controls are layered together, teams get better resilience; where they are mixed with ad hoc secrets handling, the release path becomes harder to audit and easier to abuse.

Related resources from NHI Mgmt Group

• What is the difference between static secrets and federated workload credentials?
• What is the difference between short-lived credentials and dynamic secrets?
• What is the difference between storing secrets securely and governing them well?
• What is the difference between sandboxed execution and trusted repository mutation?