Secret analysis not picking up plaintext passwords in Terraform

Rules and Languages Report False-positive / False-negative...
, ,
1

Hello,

My company is running SonarQube v25.8.0.112029 CE in a docker container.

We have a problem with Terraform files containing non-critical passwords (but secrets nonetheless) in them.

However, the Secrets rules do not pick them up. I have extented the Sonar Way for Secrets, deliberately turned on the Secrets Profile for the project… the console output shows the “text and secrets analyzer” is being run over those files… but it is not being reported.

I’m talking about cases like this:

resource "aws_db_instance" "dev-test-instance-xyz" {
  allocated_storage      = 20
  storage_type           = "gp3"
  identifier             = "dev-test-instance-xyz"
  engine                 = "postgres"
  engine_version         = "15"
  instance_class         = "db.t3.micro"
  username               = "dev-user"
  password               = "ui!ExampleGeneratedTncokmzxawdNkb2"
}

The only clue I found as to why such an obvious misstep might be occurring is this:

"Database passwords should not be disclosed" not always detecting (Sebastien’s response)

I haven’t been able to “force” SonarQube to enforce the rules on my .TF files. I’ve added them in Admin > Languages > Secrets, and from my console output the files must be correctly being considered:

15:01:48.187 INFO  Starting the text and secrets analysis
15:01:48.195 INFO  51 source files to be analyzed for the text and secrets analysis
15:01:48.485 INFO  51/51 source files have been analyzed for the text and secrets analysis
15:01:48.494 INFO  Sensor TextAndSecretsSensor [text] (done) | time=1191m

So I’m stuck with this glaring omission. What must I do?

Thanks in advance.

Sonar Community Roundup, August 16 - August 22
3

Hello @fernandopj82, welcome to Community!

In our secret detection offering in SonarQube, this would not be raised by the TextAndSecretsSensor, but by a specific Terraform rule, since this is a very specific secret (a hard-coded value in the password argument of an aws_db_instance resource).

It should be raised by our language-specific rule S6437. While we plan to add it, this rule is currently, as of August 2025, not available for Terraform in the product.

Also, note that we may not want to raise an issue on your specific example to avoid noise, as your password looks like a placeholder.

Thanks a lot for your feedback, it helps us put a higher priority on implementing this feature. Let us know if you need anything else!

Best,
Gabin

1 Like
4

Hello Gabin, thank you for your feedback.

Since this scenario is not currently available as a predefined rule, do you believe it is possible for me to create a new custom rule for a Terraform Profile of our own?

Also, yes, the password string I typed was random, but I inserted an obvious text in it for any reader not to think I pasted an in-use password.

1 Like
5

While I’m at it, Gabin can you confirm I could contribute to this S6437 implementation in Terraform by submitting a PR to sonar-iac/iac-extensions/terraform at master · SonarSource/sonar-iac ?

There are some PRs that did implementations of that rule in other languages, such as SONARIAC-1090 S6437 Hardcoded secrets in mysql, msqladmin and mysqldump by mstachniuk · Pull Request #924 · SonarSource/sonar-iac I can use those as guides.

1 Like
6

Thanks for your answers Fernando! We don’t support custom rules for Terraform, and custom rules are more for context-specific rules (e.g. rules that would bring value only to a specific organization).

Since this rule could benefit every user, an actual addition to the product would be a better fit. Your contribution would be more than welcome!

If you want to have a look at it, here are some details:

  1. You’re right! You would need to create a new check here, and the associated tests here.
  2. The Docker implementation is indeed an example, but it’s a bit too specific with all the command parsing logic. A better-suited example may be the Azure Resource Manager implementation (source, tests, test resources). You can also have a look at the other Terraform checks to see how we usually write them.
  3. The goal of S6437 would be to raise an issue on every resource-specific argument that we know is sensitive. For example, the most basic logic would be to raise an issue if a resource is of type aws_db_instance, and has a hardcoded value in the password argument. You can tackle only this specific case (and some others you may want), and we can later add support for more resource types!

If you need any help or guidance, let me know! You can also ping me on GitHub: GabinL21 (GabinL21) · GitHub

Best,
Gabin

1 Like
7

Thanks for those useful directions, Gabin. I’ll spare some time to tackle this, as my company would benefit from just as others.

I’ll ping you when I submit a PR.

Thanks again for your support.

1 Like
10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.