Notifications
Clear all
Topic starter
01/07/2026 2:02 am
TL;DR: GitHub Actions jobs often rely on static AWS keys and API tokens, but short-lived OIDC exchange plus destination-bound credential injection can remove secrets from the environment and narrow blast radius, according to Riptides. The real governance gap is that CI workloads still behave like identity-less secret consumers unless teams bind them to policy and visibility.
NHIMG editorial — based on content published by Riptides: Your GitHub Actions Job Deserves a Real Identity
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should teams govern GitHub Actions jobs that deploy to production?
A: Treat GitHub Actions jobs as governed workloads with their own identity, policy, and audit scope.
Q: Why do CI pipelines make secret exposure harder to control than service accounts?
A: CI pipelines are short-lived, highly variable, and often execute untrusted dependency code, so secrets can be exposed during a single run even when the build later fails.
Q: What breaks when GitHub Actions jobs still rely on static API keys?
A: Static keys create a wide exposure window because any code that reaches the runner can usually read them, reuse them, or print them into logs.
Practitioner guidance
- Map CI jobs into the identity model Classify each pipeline that can reach production assets as a governed workload, then document which repositories, branches, and actors are allowed to trigger it.
- Replace exported secrets with runtime-bound access Remove long-lived AWS keys, webhook tokens, and API credentials from job environment variables and stored secrets where possible.
- Enforce connection-level policy for deploy jobs Block outbound traffic to destinations that are not in policy, including attacker-controlled endpoints, and verify that the runner can attribute each allowed connection to a specific workflow and actor.
What's in the full article
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- The exact GitHub Actions OIDC exchange flow used to mint a short-lived SPIFFE identity.
- The kernel-level credential injection path that keeps secrets out of the job environment.
- The sample Verifier policy fields for repository owner, branch, and audience conditions.
- The end-to-end setup steps for connecting a workflow to the control plane.
👉 Read Riptides' analysis of GitHub Actions workload identity and secretless CI →
GitHub Actions workload identity: are your CI controls keeping up?
Explore further
01/07/2026 2:22 am
CI jobs are part of the identity perimeter, not a tooling exception. A workflow that can sign code, push artifacts, and reach internal APIs has the same governance weight as a production workload. Treating it as a secret consumer leaves the programme blind to who acted, what was allowed, and what was exposed. The practical conclusion is that CI must be governed as a workload class inside the identity model.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity blind spots become governance blind spots when workloads are not individually bound to policy.
A question worth separating out:
Q: How can security teams tell whether CI identity controls are actually working?
A: Look for two signals: secrets no longer appear in job environments or logs, and every outbound connection is linked to an approved workflow, repository, and actor. If the team cannot trace those links, the CI programme still treats identity as an afterthought rather than a control plane.
👉 Read our full editorial: GitHub Actions jobs need workload identity, not static secrets
