Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?

Why This Matters for Security Teams

GitHub Actions sits on the boundary between source control, build automation, and deployment authority, which makes accountability easy to blur and costly to ignore. When a workflow can read secrets, write artifacts, or push code, the real risk is not the runner itself but the trust boundary that was approved without enough review. The OWASP Non-Human Identity Top 10 treats secret handling and privilege scope as first-class attack surfaces, and NHIMG’s CI/CD pipeline exploitation case study shows how quickly a workflow mistake can become a production incident. In practice, many security teams encounter secret exposure only after a workflow has already been merged, executed, and reused across repositories, rather than through intentional design review.

How It Works in Practice

Accountability should follow control over three things: who defined the workflow, who approved its permissions, and who owns the secrets or deployment target it can touch. If a workflow is allowed to comment, publish, deploy, or modify contents, that authority must be mapped to an identifiable service owner and a named approver. Security teams should treat workflow files as executable policy, not just automation scripts.

That means reviewing:

• Trigger conditions, especially pull_request_target, workflow_dispatch, and reusable workflows
• Secret exposure paths, including environment variables, job outputs, artifacts, and logs
• Token scope, with GitHub token permissions reduced to the minimum needed for the job
• Change control for workflow edits, including branch protection and code owner review

Current guidance suggests using short-lived credentials where possible and separating read-only build steps from privileged release steps. The strongest practice is to keep untrusted code away from secret-bearing jobs, then use explicit approvals for any step that can write, publish, or deploy. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets reinforces why long-lived secrets in automation create unnecessary blast radius, while the Reviewdog GitHub Action supply chain attack illustrates how a trusted action can become the delivery path for exposed credentials. These controls tend to break down in large monorepos and reusable workflow estates because ownership is split across platform teams, application teams, and release engineers, so no single reviewer sees the full permission picture.

Common Variations and Edge Cases

Tighter workflow governance often increases release overhead, requiring organisations to balance delivery speed against the risk of secret leakage or unintended code execution. The most common edge case is a reusable workflow owned by one team but invoked by many others: in that model, accountability is shared, but the calling team still owns the decision to pass secrets or elevated tokens.

Another frequent exception is contributor-authored pull requests from forks. Best practice is evolving, but there is no universal standard for this yet: the safest approach is to avoid exposing write-capable secrets to untrusted fork context and to route privileged actions through approval-gated jobs. Organizations should also be cautious with self-hosted runners, because a compromised runner can persist beyond a single job and become a pathway to lateral movement. NHIMG’s Shai Hulud npm malware campaign shows how supply chain compromise can turn normal automation into a secret-exposure event. When workflow permissions are inherited through templates, composite actions, or org-wide defaults, accountability usually fails at the point where nobody can name the exact owner of the privileged step.

Related resources from NHI Mgmt Group

• Who is accountable when a workflow flaw exposes session secrets and code execution?
• Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?
• Who is accountable when a workflow platform vulnerability leads to code execution?
• Who is accountable when a vulnerability exposes hardcoded secrets in server output?