What is the difference between trusted publishing and secrets-based package release workflows when the repository is already compromised?

How the two release models differ once the repository is already compromised

trusted publishing and secrets-based release workflows solve different problems. Secrets-based publishing depends on a stored token or key living in the repository or CI environment, so a compromise often turns into secret theft first and package abuse second. Trusted publishing removes that static release secret, but it does not remove trust in the workflow logic, the build environment, or the artifact path.

The important distinction is that trusted publishing narrows one class of failure, leaked release credentials, while secrets-based workflows add that credential as an extra attack surface. If the repository itself is hostile, neither model is safe by default. The deciding factor becomes whether the attacker can alter workflow steps, inject code into the release path, or influence what artifact is produced and signed for publication.

In other words, trusted publishing changes the authentication model for release, not the integrity of the repository. A compromised repo can still authorise a bad outcome if the pipeline trusts the repo’s workflow definition, generated files, or build inputs too much.

What a compromise changes in the publish path

With secrets-based release, an attacker who gains repository control may try to read the release secret directly, exfiltrate it through build logs, or replace the release step so the secret is used against the attacker’s target. That makes the secret itself a high-value asset. Once stolen, it can often be replayed outside the repository until it is rotated or revoked.

With trusted publishing, the attacker usually does not need to steal a long-lived token. Instead, they focus on CI/CD pipeline identity and publishing controls, because the release authority is granted to the pipeline under specific trust conditions. If those conditions are weak, a malicious workflow can still stage a bridge script, swap the built artifact, or publish from an approved pipeline path.

This is why repository compromise changes the question from “can the secret be stolen?” to “can the build and release path be bent?” If the answer is yes, trusted publishing reduces credential exposure but does not prevent malicious release intent.

What practitioners should conclude about trust, control, and blast radius

Trusted publishing is strongest when the workflow definition, branch protection, build inputs, and artifact provenance are already well controlled. It is weaker when release jobs are editable by the same actors who can commit code, because then the trust boundary is only as strong as the repository governance behind it. Secrets-based workflows fail faster and more obviously under compromise, but they also expose a reusable credential that can be abused elsewhere.

For release integrity, the key practitioner question is whether the pipeline can be altered to produce an attacker-chosen artifact while still satisfying the platform’s publication rules. If yes, moving from secrets to trusted publishing improves hygiene, but it is not a complete compromise control. The release system still needs change control, approval separation, and tight scoping around what the workflow can execute.

When you compare the two models under compromise, the real trade-off is this: secrets-based publishing makes credential theft the obvious failure mode, while trusted publishing makes workflow trust and artifact integrity the critical failure mode. The latter is usually the better design, but only when the surrounding CI/CD controls are strong enough to resist repo takeover.

Risk and Threat Considerations

Repository compromise turns release automation into an execution channel for the attacker. The main risk is not just secret exposure, but malicious publication through a legitimate pipeline, where the attacker preserves the appearance of normal release activity while changing what gets built or uploaded.

Failure mechanism: A hostile committer or compromised maintainer account can edit workflow logic, add a bridge script, or redirect the build so the pipeline publishes an attacker-controlled artifact under an approved release event.

Impact: Consumers may receive a trojanised package, the release process may appear valid to reviewers, and any stolen release secret from a secrets-based workflow can be reused until rotation or revocation.

Practitioner Guidance

What to verify: Treat trusted publishing as safe only when the workflow file is protected at least as tightly as the release credential would have been. Verify branch protections, required reviews for workflow changes, and whether the build job can mutate its own release logic.

Decision rule: If the repository can modify the release workflow, assume compromise can reach publication even without a stolen secret. In that case, prioritise workflow immutability, artifact provenance, and separation of duties before worrying about secret storage alone.

Common mistake: Teams often remove the static token and assume the release channel is now trustworthy. That is only true when the repository, runner, and build inputs are controlled well enough that an attacker cannot change what the pipeline publishes.

Practitioner takeaway: Trusted publishing reduces secret exposure, but repository compromise shifts the dominant risk to pipeline trust and artifact integrity, so the release path must be defended as a production control plane.

Related resources from NHI Mgmt Group

• What is the difference between Trusted Publishing and storing package credentials in repository secrets?
• How can security teams tell the difference between routine package maintenance and a compromised release pattern?
• What is the difference between a compromised package repository and a socially engineered GitHub delivery path?
• What is the difference between role-based access and row-level access in review workflows?