Why do data sources still create secrets risk in Terraform?

Data sources are read-only from Terraform’s point of view, but the values they return are still written into state so future plans remain stable. That means a secret fetched from an external system can become a durable copy in state even when it never appears in code.

Why This Matters for Security Teams

Terraform data sources look harmless because they are read-only in configuration, but they still retrieve live values that can be serialized into state. Once a secret lands in state, it becomes a durable copy that may outlive the original system, the deployment, or the access path that fetched it. That is why this is not just a Terraform hygiene issue, but a secrets governance problem.

The risk is amplified by how often infrastructure automation touches sensitive systems. NHIMG research shows that nearly half of exposed secrets now appear outside code repositories, including CI/CD logs and collaboration tools, which is exactly where Terraform workflows often spread data. The pattern is consistent with the broader secret sprawl problem described in the Guide to the Secret Sprawl Challenge, and it aligns with the control concerns in the OWASP Non-Human Identity Top 10.

Teams often assume the danger is limited to hardcoded variables, then discover that a read-only lookup created the exposed copy after the plan, apply, or state archive was already shared. In practice, many security teams encounter this only after the state file has been replicated into backups, remote state backends, or incident response artifacts.

How It Works in Practice

Terraform uses state to preserve resource identity and stabilize future plans. When a data source returns a secret, Terraform may record that value in state even if the HCL never contains the secret directly. That means the secret can persist in plaintext or as retrievable structured data depending on the provider, backend, and downstream tooling.

The core failure mode is not that Terraform can read secrets. It is that Terraform is optimized for repeatability, while secrets are optimized for short-lived exposure. Those goals conflict. A value that should exist only at runtime can become durable because state is designed to be replayed, compared, and shared across teams. This is why the issue is discussed in NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets.

• Use data sources only for non-sensitive lookup values when possible.
• Prefer ephemeral delivery paths for secrets, such as a runtime fetch from a dedicated secrets manager.
• Minimise state exposure by restricting backend access, encryption, and replication paths.
• Review provider documentation carefully, because sensitivity handling is not uniform across ecosystems.
• Test whether a value appears in state, plan output, logs, and exported artifacts, not just in code.

Current guidance suggests treating any secret-returning data source as a potential state contamination event unless proven otherwise. That aligns with the defensive posture in NIST Cybersecurity Framework 2.0, especially for asset visibility, access control, and data protection. These controls tend to break down when remote state is broadly shared across multi-account pipelines because the secret can be copied far beyond the original workspace before anyone notices.

Common Variations and Edge Cases

Tighter secret handling often increases pipeline complexity, requiring organisations to balance repeatable infrastructure builds against the overhead of runtime secret retrieval and access segregation. That tradeoff becomes sharper in multi-team platforms, where different modules, providers, and backends do not behave identically.

There is no universal standard for this yet, but several patterns are recurring. Some providers mark returned attributes as sensitive, which reduces display risk but does not guarantee state exclusion. Some backends encrypt state at rest, which helps with storage risk but does not eliminate exposure to anyone with backend access. Some teams split Terraform responsibilities so that secret provisioning happens outside Terraform, leaving Terraform to consume references or identifiers rather than secret values.

Edge cases matter most when modules are reused across environments. A module that is safe in development can become risky in production if a data source begins resolving credentials, tokens, or certificates instead of metadata. The practical test is simple: if the returned value would be dangerous in a backup, ticket, or debug export, it should not be allowed to become part of durable state. The 52 NHI Breaches Analysis shows how quickly weak identity and secret handling compound once automation spreads that exposure.

Related resources from NHI Mgmt Group

• Why do Terraform and OpenTofu still create secrets risk if the infrastructure model is declarative?
• Why do ephemeral credentials still leave risk in machine access models?
• Why do approved AI tools still create data leakage risk?
• Why do shared service accounts still create risk even when secrets are vaulted?