Who is accountable when a compromised action leaks repository secrets?

Why This Matters for Security Teams

A compromised action that leaks repository secrets is not just a code review issue. It is an identity and trust failure that crosses platform engineering, application ownership, and governance. The action’s execution authority, the repository’s secret storage, and the downstream systems that accepted the leaked credential all contribute to the blast radius. That is why accountability should be assigned across control owners, not reduced to a single incident responder.

The pattern shows up repeatedly in supply chain and CI/CD incidents, including the Reviewdog GitHub Action supply chain attack and the CI/CD pipeline exploitation case study. The lesson is simple: when a workflow can read secrets, it becomes part of the identity perimeter, whether or not it was designed that way. The OWASP Non-Human Identity Top 10 treats this as a governance problem, not a narrow alerting problem. In practice, many security teams encounter this only after a token has already been reused elsewhere and the original leak path is no longer the most urgent issue.

How It Works in Practice

Operationally, accountability breaks into three lanes. First, platform engineering owns the action trust boundary: what code is allowed to run, which actions are pinned, what permissions they receive, and whether they can reach secret stores at all. Second, the application or service owner owns the secret itself: why it exists, where it is stored, whether it should be static or ephemeral, and whether it can be replaced with workload identity. Third, identity governance owns the policy model: role design, approval flow, revocation, and exception handling.

That division matters because compromised actions often succeed through overly broad just-in-time access, reusable static secrets, or weak runtime checks. NHIMG research shows the scale of the problem in the Guide to the Secret Sprawl Challenge, while the 52 NHI Breaches Analysis shows how identity and access failures compound once a secret escapes its intended boundary. Current guidance suggests using intent-based authorisation for high-risk workflows, where the decision is made at runtime based on what the action is trying to do, not just what repository role it inherited. That is aligned with the direction in the Anthropic AI-orchestrated cyber espionage campaign report, which shows how autonomous systems can chain steps in ways static policy never anticipated.

• Use workload identity for the action where possible, so the workflow proves what it is instead of borrowing a long-lived secret.
• Issue short-lived credentials per task and revoke them automatically when the job ends.
• Log which system granted access, which policy approved it, and which secret was exposed.
• Require the secret owner to trigger rotation, but require the platform owner to remove the trust path that enabled the leak.

These controls tend to break down when self-hosted runners, unpinned marketplace actions, and shared secret stores all exist in the same pipeline because the trust boundary becomes too fragmented to enforce consistently.

Common Variations and Edge Cases

Tighter secret controls often increase delivery overhead, so organisations must balance speed against containment. That tradeoff becomes visible in multi-repo estates, reusable workflows, and temporary exceptions for emergency releases. There is no universal standard for ownership splits in every environment, but best practice is evolving toward clear separation between action trust, secret stewardship, and access policy.

Edge cases matter. If the leaked secret belongs to a third-party service, the application team may own the integration while the vendor account owner owns revocation. If the action was a dependency in a shared platform template, platform engineering may carry primary accountability even when the workload team triggered the run. If the environment uses Ultimate Guide to NHIs — Static vs Dynamic Secrets patterns poorly, the problem often begins long before the compromised action executes.

For governance, the right frame is not blame but control ownership. 230M AWS environment compromise and the Emerald Whale breach both reinforce that once secrets are exposed, downstream abuse follows the path of least resistance. Accountability should therefore map to who could have prevented the leak, who could have limited the credential lifetime, and who could have detected misuse fastest.

Related resources from NHI Mgmt Group

• Who is accountable when exposed machine secrets are found in a public repository or portal?
• Who is accountable when a compromised identity system disrupts public services?
• Who is accountable for exposed NHI secrets after an employee leaves?
• Who is accountable when compromised credentials are used to trigger ransomware?