Who is accountable for OpenTofu secret handling in CI/CD pipelines?

Why This Matters for Security Teams

OpenTofu secret handling in CI/CD is not just a tooling question. It is an accountability question because the pipeline, state backend, and secret source each control a different part of the exposure boundary. If any one of those is weak, secrets can leak into logs, state files, build artifacts, or runner memory even when the code itself looks clean. That is why guidance on OWASP Non-Human Identity Top 10 and NHIMG research on the Guide to the Secret Sprawl Challenge both emphasise that the control point is usually the machine identity, not the human who merged the change.

Practitioners often get this wrong by treating secrets as a developer hygiene issue instead of a shared operational risk across platform engineering, security, and application delivery. In reality, the team that owns the pipeline decides how credentials are injected, the team that owns the backend decides how state is protected, and the team that owns the secret source decides who can mint, read, and revoke values. GitGuardian's State of Secrets Sprawl 2026 shows how quickly exposures persist when revocation is slow, especially in CI/CD and supply chain paths. In practice, many security teams encounter secret leakage only after a runner, state bucket, or deployment token has already been reused in the wild, rather than through intentional design review.

How It Works in Practice

Accountability should follow the control surface. The pipeline owner is accountable for how OpenTofu runs, which identities it uses, and whether secrets are passed as short-lived runtime inputs or baked into environment variables, files, or remote state. The backend owner is accountable for encryption, access policy, versioning, and recovery of state that may contain sensitive values. The secret source owner is accountable for issuing, scoping, rotating, and revoking credentials. That separation matters because a secure plan depends on all three being aligned, not on one team assuming another has already locked it down.

Current best practice is to combine workload identity with just-in-time secret delivery. For CI/CD, that usually means the runner authenticates with a machine identity, requests a narrow, ephemeral token, and receives only the secret needed for that task and that window. Static credentials should be avoided where possible because long-lived tokens expand blast radius and make post-incident cleanup unreliable. The CI/CD pipeline exploitation case study shows how quickly an attacker can pivot once a build system is trusted broadly.

• Use a dedicated pipeline identity for OpenTofu execution, not a human admin account.
• Keep deployment access separate from secret administration so the same actor cannot both request and approve sensitive values.
• Store state in a backend with strong access controls and encryption, because state may contain outputs that behave like secrets.
• Prefer runtime injection from a secret manager over checked-in variables, local files, or shared runner environments.
• Rotate and revoke automatically after each pipeline task when the workflow supports it.

Where this breaks down is in shared runners with broad egress, long-lived state locks, or legacy workflows that require manual approval and reuse of the same credentials across multiple environments, because those conditions defeat task-level isolation.

Common Variations and Edge Cases

Tighter secret controls often increase delivery overhead, requiring organisations to balance build speed against containment. That tradeoff becomes sharper in multi-environment pipelines, disaster recovery workflows, and teams that centralise secret issuance while decentralising deployment ownership. In those cases, accountability is still split by control surface, but operational responsibility may sit with a platform team that implements the guardrails while application teams consume them under policy.

There is no universal standard for this yet, but current guidance suggests one useful rule: the team that can change how secrets enter, persist, or leave the pipeline should be accountable for the risk they create. If OpenTofu reads credentials from remote state, the state owner inherits part of the obligation. If a secret manager is used, the secret operations team must define TTL, rotation, and revocation. If a platform team controls the runner image, it owns hardening, logging, and memory hygiene. NHIMG's 52 NHI Breaches Analysis reinforces a recurring pattern: failures usually come from unclear ownership across handoffs, not from a single missing control.

In regulated environments, teams should document this split in a RACI or control matrix, then test it with incident scenarios such as leaked backend credentials, compromised runner tokens, or a poisoned dependency that exfiltrates state. That is the point where policy becomes operational and accountability becomes measurable.

Related resources from NHI Mgmt Group

• How do organisations reduce false positives in secret detection pipelines?
• Who is accountable when a workload secret is exposed in CI/CD?
• Why do CI/CD pipelines create secret governance risk?
• What breaks when SCIM provisioning code uses unsafe secret handling?