Terraform State secrets — check state secrets free

Eight findings, six of them errors, came out of a forty-seven line Terraform file that every code scanner in the pipeline had already passed. The engineer who wrote it runs a production AWS account for a payments team in Berlin, and nothing in it looks wrong: no password in the source, a remote S3 backend with encrypt set to true. By most linters' standards it is fine.

The problem is not what is in the code. It is what Terraform does with it.

Terraform writes back everything it sends to a provider. That is the design: state is how drift is detected, so state holds the value actually applied. So terraform.tfstate is a plaintext JSON copy of your infrastructure, and the list of values it copies is not the list you typed.

Three examples from that file. A random_password resource generates a thirty-two character secret, and the generated value is stored in state in cleartext forever — documented behaviour of the random provider, not a bug. A tls_private_key resource writes private_key_pem into state, which is why the hashicorp/tls documentation calls it unsuitable for production keys. A data block reading aws_secretsmanager_secret_version copies the secret out of the secret manager into state on every plan, because every data source result is persisted.

None of those three lines contains a secret. All three put one in state.

The fourth misunderstanding is sensitive = true. It hides the value in plan output and in CI logs. It does not remove it from state: an output marked sensitive and one that is not produce identical state entries. It is a logging control that reads like an encryption control.

Terraform State Secret Leak Lint is a VS Code extension built around that distinction. It reads the .tf file you have open and applies ten rules, every one about what lands in state rather than what appears in the source: nineteen attribute names from password through shared_access_key; the random and TLS providers; seven secret data sources; the backend, checked for encrypt and kms_key_id; the terraform block, checked for the encryption block available since Terraform 1.10; outputs and variables named like credentials without sensitive set; and credential literals in six formats. Each finding carries its line number and what to write instead — for the RDS password, manage_master_user_password, which hands the credential to AWS to rotate.

The repository ships both halves. The forty-seven line dirty.tf returns eight findings: six errors and two warnings. The same stack rewritten so no secret reaches state returns zero. That pair is the whole argument.

Free scanners are not wrong; they answer a different question. They look for a secret written in the code, and here there is none. The question an auditor asks is where production secrets live, and the honest answer for most Terraform repositories is: in the state file, in cleartext, in every historical version of the state object, until somebody rotates them.

The extension is free on the file you have open, all ten rules, no licence key — a complete job on one file. The licence key adds a different axis, not more of the same: the workspace sweep across every .tf file in one pass, and the export that writes findings to a dated Markdown or JSON file you keep as audit evidence.

Hand review runs about $150/hour; reading a mid-size Terraform repository attribute by attribute is most of a working day. The licence is $29 once, one key per person or CI seat.

The same engine runs as a browser page with nothing uploaded, so you can paste the file you are worried about first.