Why do source repository compromises still defeat trusted publishing?

Why trusted publishing does not stop repository compromise

trusted publishing changes how the registry trusts a build or release job, but it does not prove that the source repository is healthy. If an attacker can alter code in an approved repo, compromise a maintainer account, or tamper with a workflow trigger, the publisher can still be legitimate while the content being published is malicious.

The practical distinction is between trusted pipeline identity and source integrity. Trusted publishing removes one class of secret abuse, but it does not defend the commit path, the branch protection model, or the review process that decides what code gets built and released.

That is why compromise can succeed even when no registry token is stolen. The workflow still receives authority to publish because the platform sees an allowed event from an allowed repository, and the registry has little visibility into whether the source change itself was benign, rushed through review, or inserted through a compromised maintainer path.

Where the failure actually happens in the release chain

The weakness is usually upstream of the publish step. A malicious commit, a poisoned dependency update, a compromised maintainer session, or an abused pull request merge path can all place attacker-controlled code into the repository before the trusted publishing workflow runs. Once that happens, the publish event only proves that the workflow was entitled to speak for the project.

That is why repository security and publisher security must be treated as separate control planes. Repository controls decide what enters the release candidate; trusted publishing decides whether the release job can mint publication authority without a long-lived secret. The second control does not compensate for weak branch protection, weak review discipline, or stolen contributor access.

Source compromise is also attractive because it preserves normal operational signals. A successful malicious change may look like routine development activity, especially in fast-moving projects that auto-merge dependency updates or rely on broad maintainer trust. The publication step then converts a compromised source state into an externally trusted artifact.

What this means for package and supply-chain security

For package ecosystems, trusted publishing lowers the impact of exposed publishing tokens, but it does not change the fact that the repository is often the true control point. If an attacker can shape the source tree, they can shape the build output, the release notes, and the package consumers’ trust decision, even when the registry-side authentication is working as designed.

That is why release integrity depends on more than the final authentication hop. Signed commits, protected branches, required reviews, workflow pinning, environment isolation, and artifact attestation each reduce a different way of turning repository access into malicious publication. CI/CD pipeline identity security is the broader problem space, and trusted publishing is only one control within it.

It also helps explain why repository compromise and token theft can lead to the same outcome. In both cases, the attacker is trying to get code accepted by a release path the ecosystem already trusts. The difference is whether the abuse happens by stealing the publisher secret or by abusing the legitimate authority of the publisher workflow itself.

Risk and Threat Considerations

Source repository compromise is dangerous because it bypasses the security benefit most teams think they bought with trusted publishing. The package registry may never see a stolen token, yet consumers still receive an attacker-influenced release if the source tree or release workflow has been manipulated.

Failure mechanism: An attacker gains commit, merge, or workflow influence in the repository, then waits for the legitimate publish process to run so the malicious code is released under valid project authority.

Impact: The compromise shifts trust from stolen secrets to abused project authority, which can spread malicious packages, backdoors, or post-install payloads to downstream users at normal release speed.

Practitioner Guidance

What to verify: Treat trusted publishing as a registry control, not a repository-integrity guarantee. Verify that branch protection, mandatory review, workflow file protection, and release approval paths are strong enough to stop a malicious commit from reaching the publish job.

Common mistake: Teams often rotate publishing secrets and assume the problem is solved. If commit authority, maintainer sessions, or CI workflow triggers are still weak, an attacker can still release malware without ever touching a registry token.

Decision rule: If the threat model includes maintainer compromise, dependency poisoning, or merge-path abuse, prioritize source integrity controls before you rely on trusted publishing as evidence of release safety. The correct question is not only “who can publish”, but also “who can cause the publisher to publish”.

Practitioner takeaway: Trusted publishing removes one credential path, but the release remains unsafe if an attacker can still influence the repository state that the trusted workflow packages and ships.

Related resources from NHI Mgmt Group

• What is the difference between Trusted Publishing and storing package credentials in repository secrets?
• What breaks when attackers keep publishing malicious packages under trusted open source names?
• What is the difference between trusted publishing and secrets-based package release workflows when the repository is already compromised?
• What breaks when an AI agent is hijacked but still looks trusted?