Trusted publishing should come first when the attacker used registry and workflow trust to spread, because it narrows the path of re-entry. Secrets rotation is still essential, but if branch and workflow trust remain broad, refreshed credentials can be stolen again. The order is contain the trust path, then rotate the secrets it touched.
Why the order matters after a trust-based compromise
When an attack abused registry trust, workflow trust, or publishing trust, the first job is to close the path the attacker used to re-enter or re-spread. That usually means trusted publishing, branch protection, workflow hardening, and tokenless or narrowly scoped delivery paths. If you rotate secrets first but leave the same trust chain open, the attacker can often come back through the automation path even after credentials change.
That is why the choice is not “trusted publishing or secrets rotation” as separate clean-up tasks. It is a sequence decision. The attacker already proved the trust boundary was too loose, so the highest-value move is to reduce the chance that any refreshed secret can be re-stolen or reused in the same way.
For teams dealing with CI/CD compromise, this is especially important when publishing tokens, pipeline secrets, or build identities were involved. The remediation focus should follow the abuse path, not the most visible artifact on the incident list.
What trusted publishing changes in practice
Trusted publishing replaces shared long-lived secrets with stronger trust assertions, so publication or deployment depends more on identity and policy than on a reusable token sitting in a repo or runner. That narrows blast radius because the attacker loses the easy credential-reuse path. It also improves auditability, since a publish event is tied to a clearer trust decision rather than a static secret that may have been copied elsewhere.
CI/CD Pipeline Identity Security Guide is the most natural internal reference for this shift, because it covers keyless OIDC federation, publishing tokens, and trust policy in the pipeline itself. For a broader identity lifecycle lens, Guide to the Secret Sprawl Challenge and Secrets Management Guide both reinforce the same principle: reduce dependence on reusable secrets before you try to preserve them by rotating them.
Trusted publishing is not a magic shield. It works best when branch protections, workflow approvals, runner trust, and artifact signing are tightened together. Otherwise you may move the weak point from the secret itself to the surrounding automation path.
When secrets rotation is still essential
Rotation remains mandatory when the attacker may already possess tokens, API keys, certificates, or other reusable secrets. Any credential that could authenticate again should be treated as compromised until proven otherwise. The point is to break replay, revoke stolen material, and invalidate access that survives the cleanup of the original entry point.
That said, rotation is only durable when the surrounding trust chain is also repaired. API Key Management Guide is useful here because it frames rotation together with revocation, scoping, and expiry, not as a one-step reset. If the secret was long-lived or widely distributed, Guide to NHI Rotation Challenges is a practical reminder that rotation at scale often fails when dependencies, ownership, and expiry windows are not mapped first.
For teams that need a broader lifecycle view, NHI Lifecycle Management Guide helps connect rotation with provisioning, offboarding, and visibility. That matters after compromise because a rotated secret that still exists in forgotten systems is not really gone.
How to decide which action comes first
If the attack path depended on trusted workflow execution, publishing trust, branch bypass, or runner abuse, fix trust first. If the compromise was limited to a discrete secret with no broader automation weakness, rotate first, but still verify the trust boundary quickly after. In most real incidents, both are needed, but the order should follow the highest-probability re-entry path.
OWASP Non-Human Identity Top 10 is a useful external anchor for this decision because it treats overprivilege, secret leakage, and insecure authentication as linked failure modes rather than isolated hygiene issues. The same logic appears in the OWASP Cheat Sheet Series, which is especially helpful when teams need implementation detail on authentication, session, and secret handling after an incident.
For teams that want a control-based view, NIST SP 800-57 Key Management is relevant when the exposed material behaves like a key or token with lifecycle risk. It supports the same judgement: shorten exposure first, then replace the compromised credential with a better-controlled trust model.
Risk and Threat Considerations
When trust paths stay broad after compromise, attackers can often reuse the same automation, branch, or publishing path to regain access even after passwords or tokens are rotated. That creates a repeat-compromise pattern: the secret changes, but the attacker’s access route does not.
Failure mechanism: The attacker abuses a still-trusted pipeline, workflow, or registry relationship to obtain fresh credentials, publish malicious artifacts again, or pivot into adjacent systems after rotation.
Impact: Re-entry becomes easier, incident containment slows down, and organisations may believe the compromise is closed when the underlying abuse path is still active.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secret theft and reuse are central to the post-compromise cleanup decision. |
| NHI-04 — Insecure Authentication | Trusted publishing replaces weak reusable trust with stronger authentication assertions. | |
| NHI-07 — Long-Lived Secrets | Rotation urgency is driven by the risk of long-lived credentials surviving compromise. | |
| Recommendation — Rotate and revoke exposed secrets after closing the re-entry path. Replace reusable publishing secrets with stronger authentication-backed trust. Shorten credential lifetime and retire long-lived secrets immediately. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation, revocation, and lifecycle control are directly implicated. |
| IA-9 — Service Identification and Authentication | CI/CD and publishing trust often rely on service-to-service authentication paths. | |
| Recommendation — Revoke and reissue compromised authenticators under controlled lifecycle rules. Tighten service authentication so automated publishing cannot rely on broad trust. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen tokens or weak trust paths can let attackers authenticate again after rotation. |
| Recommendation — Harden authentication and invalidate abused tokens before restoring access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised credentials and access paths require rapid lifecycle control. |
| Recommendation — Remove compromised access paths and reissue credentials with tighter scope. | ||
Practitioner Guidance
What to prioritise: Treat the trust boundary as the containment problem and the secret set as the eradication problem. If branch, workflow, or publishing trust is still open, close that path before assuming rotation alone has reduced risk.
What to verify: Confirm which credentials were actually reachable from the abused path, whether they were reused elsewhere, and whether publishing or deployment can still happen without the old trust model.
Practitioner takeaway: The correct order is usually to remove the attacker’s repeat-entry mechanism first, then rotate everything that mechanism could have touched.
Related resources from NHI Mgmt Group
- Should organisations prioritise registry scoping or secrets rotation first after this kind of issue?
- Should organisations prioritise token rotation or dependency pinning first after this kind of attack?
- How do teams decide whether to prioritise secrets rotation or access visibility first?
- Should teams prioritise secret discovery or rotation first after exposure?