Security and platform teams are accountable for identifying replaceable secrets and driving the migration to OIDC where supported. The goal is to remove static credentials from workflows that can rely on short-lived federation tokens instead. That responsibility usually sits with the teams that own CI/CD governance, secret hygiene, and cloud access patterns.
Why This Matters for Security Teams
Replacing GitHub Actions secrets with OIDC is not just a hygiene task. It is a control shift from static credentials that can be copied, reused, and forgotten to short-lived federation that narrows blast radius. That matters because workflow compromise, runner abuse, and supply chain intrusion often turn one exposed secret into repeated cloud access. NHI Management Group’s research on the State of Secrets Sprawl 2026 shows how fast secrets exposure continues to grow across modern delivery pipelines.
For security teams, the accountability question is about ownership of the migration path, not just inventorying a secret store. Platform engineering, cloud security, and CI/CD governance usually need to identify which workflows still depend on long-lived keys, then define the replacement trust model. That aligns with the OWASP Non-Human Identity Top 10, which treats non-human credentials as a governance problem, not a simple configuration issue. In practice, many security teams encounter secret removal only after a workflow leak, token replay, or runner compromise has already turned the credential into an incident.
How It Works in Practice
The operational goal is to replace secrets that authenticate GitHub Actions jobs with federated identity based on OIDC. In practice, a workflow exchanges a short-lived OIDC token for a cloud provider token or role session at runtime, instead of reading a static access key from repository or environment secrets. That means the workflow authenticates as a workload, not as a stored credential.
This model works best when the owning team maps each workflow to a specific cloud trust policy, repository, branch, and environment. The identity assertion should be narrow enough that only the expected repository and ref can assume the target role. Current guidance suggests treating this as policy-as-code rather than manual exception handling, because access decisions need to be checked at request time, not reviewed later.
- Inventory every GitHub Actions secret and classify whether it can be replaced by OIDC federation.
- Define per-workflow trust relationships with least privilege and clear audience and subject claims.
- Use short-lived tokens and avoid broad, reusable cloud keys wherever federation is supported.
- Remove the static secret only after the workflow is validated against the new trust path.
This also improves incident response because revocation shifts from rotating a reused key to breaking a specific trust path. NHI Management Group’s CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack both illustrate how quickly pipeline credentials become attacker infrastructure once they are exposed. These controls tend to break down in legacy workflows that depend on third-party actions, unsupported cloud targets, or shared roles with overly broad trust conditions.
Common Variations and Edge Cases
Tighter federation often increases migration overhead, requiring organisations to balance reduced secret exposure against workflow complexity and cloud-policy maintenance. That tradeoff is real when hundreds of repositories, multiple cloud accounts, or reusable composite actions are involved. Best practice is evolving, but there is no universal standard for every environment yet.
Some workflows cannot move immediately because the target platform does not support OIDC, the trust boundary is unclear, or the job still needs a legacy integration that only accepts static credentials. In those cases, the accountable team should treat the secret as a temporary exception with a retirement date, compensating controls, and explicit owner approval. The right question is not whether a secret exists, but whether it has a justified lifespan.
Edge cases also appear when teams assume private repositories are safe or when secret rotation is confused with secret removal. NHI Management Group’s Ultimate Guide to NHIs is useful here because it distinguishes static from dynamic credentials, which is the real governance boundary. The accountability model should therefore sit with the teams that own CI/CD standards, cloud trust policy, and secret lifecycle management, while application teams remediate within their own workflows.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets in CI/CD are high-risk NHI credentials that should be replaced. |
| OWASP Agentic AI Top 10 | Autonomous workflows need short-lived, context-bound access rather than reusable secrets. | |
| CSA MAESTRO | Agentic and automated pipelines need governed identity and trust boundaries. | |
| NIST AI RMF | AI risk governance extends to automated workflows that can misuse static credentials. | |
| NIST Zero Trust (SP 800-207) | PS-3 | Zero trust requires strong workload identity and least-privilege access for each request. |
Use runtime identity checks and ephemeral tokens for automated workflows that execute with tool access.
Related resources from NHI Mgmt Group
- Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?
- Who is accountable when an attacker uses GitHub Actions and OIDC tokens to publish compromised packages?
- Who is accountable when automated threat hunting triggers remediation actions across SOC and engineering workflows?
- Why do collaboration tools create such a large secrets risk?
