Secrets not getting scanned in Sonarqube community edition

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension) – Community Build v25.10.0.114319

  • how is SonarQube deployed: zip, Docker, Helm

  • what are you trying to achieve - We added the password as a plain text value in the ARM template (.json) file and executed the SonarQube scan through the Azure DevOps (ADO) pipeline. However, the exposed password in the JSON template was not detected or reported as a vulnerability. We are using the following additional properties in the SonarQube scan configuration within the ADO pipeline.

          sonar.scanner.skipJreProvisioning=true

      sonar.sourceEncoding=UTF-8

      sonar.json.activate=true

      sonar.text.inclusions.activate=true

      sonar.text.inclusions=\*\*/\*.bicep,\*\*/\*.json

      sonar.inclusions=\*\*/\*.bicep,\*\*/\*.json,\*\*/\*.properties

      sonar.text.inclusions=\*\*/\*.env

  • what have you tried so far to achieve this

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

2

Hi @Prabhuguna,

Thanks for reaching out, and welcome to the Community!

Secrets detection is available in Community Build, but looking at your config, there are a couple of things to fix.

You have sonar.text.inclusions defined twice, the second overrides the first:

sonar.text.inclusions=**/*.bicep,**/*.json   ← this gets overridden
...
sonar.text.inclusions=**/*.env               ← only this takes effect

So right now, only .env files are covered by sonar.text.inclusions. Your .json files aren’t in scope for secrets scanning via that path. Merge them into a single value:

sonar.text.inclusions=**/*.bicep,**/*.json,**/*.env

One thing to note, the engine doesn’t flag arbitrary "password": "somevalue" fields, it matches against a catalog of specific secret patterns (AWS keys, Azure SAS tokens, connection strings, API tokens, etc.).

For your test to work, use a realistic-looking credential that matches one of the built-in patterns, for example an Azure Storage connection string or a Base64-encoded token. Can you share some test code so we can see what you’re trying to trigger?

Community Build ships with basic secrets detection. Developer Edition adds 400+ patterns covering 340+ rules. If the specific secret type you’re testing isn’t in the Community Build’s pattern catalog, it simply won’t be detected regardless of configuration. See the edition comparison for details.

For ARM templates, two analyzers run side by side: the ARM analyzer (which finds security misconfigurations like open firewall rules, missing encryption) and the JSON analyzer (which enables secrets scanning when sonar.json.activate=true). Your sonar.json.activate=true is correct for this, but the file still needs to contain a pattern the secrets engine recognises.

When sonar.text.inclusions.activate=true, only files tracked by git are included in the secrets scan. Make sure your ARM template file is committed to the repository, not gitignored.

Run your analysis with debug logging to confirm which files are being picked up:

sonar.verbose=true

Look for lines like Analyzing language associated files and files included via "sonar.text.inclusions" that are tracked by git, that’ll tell you which files the secrets engine is looking at.

Hope that helps.

Best regards,

Stevan

3

Thanks for your detailed response. I really appreciate it.

I made a few changes to the YAML configuration, and now SonarQube is detecting secrets as vulnerabilities. However, this seems to apply only to secrets that are hardcoded directly within the ARM template properties.

Secrets defined as default values in the parameter section of the ARM template do not appear to be detected as vulnerabilities in the portal. For example:

“pattoken”: {

“type”: “string”,

“defaultValue”: “xxxxx”,

“metadata”: {

}

}

Since the secret value is nested under the defaultValue property, is it possible that SonarQube does not consider it during secret detection? I am observing a similar behavior with Bicep templates as well.

Could you please clarify whether this is an expected limitation or behavior?

Also, could you share any documentation or articles that provide details on the secret detection patterns and supported secret types in the SonarQube Community Build Edition?

Thanks in advance for your help.

4

Hi @Prabhuguna,

Glad the initial fixes helped! To answer your follow-up:

Why defaultValue on a string parameter isn’t flagged

There are actually two detection engines working here, and both have a reason for this behaviour:

ARM IaC structural rule (S6648): This rule specifically checks for non-empty defaultValue on secure parameters, but only when the parameter type is securestring or secureObject. A type: string parameter with a defaultValue is considered compliant by design, because plain strings can legitimately have defaults.

Secrets detection engine: This scanner works purely on raw text content, matching against ~340 specific credential patterns (GitHub PATs, AWS keys, Azure SAS tokens, etc.). It doesn’t understand JSON structur, it just looks for recognisable token formats anywhere in the file. A real GitHub PAT (ghp_...) or Azure storage key in a defaultValue would be flagged. A generic placeholder like xxxxx or a simple password string won’t match any specific service pattern, so it’s intentionally filtered to keep false-positive rates low.

The ARM best-practice for sensitive parameters is to type them as securestring rather than string.

  • This prevents the value from being logged or displayed in deployment outputs
  • It causes S6648 to flag any non-empty defaultValue, ensuring you don’t accidentally commit a default secret
"pattoken": {
  "type": "securestring",
  "defaultValue": ""
}

Does that make sense?

Best regards,

Stevan

5

Hello @stevan.vanderwerf - Thank you for your response and it makes sense. I added the sample PAT token to the template parameters as a string type, but it is still not being detected during the SonarQube scan. As per your recommendation, I also added the storage key as a plain-text variable; however, it is not appearing in the vulnerability report either..

6

Hello @Prabhuguna,

Thanks for the update.

Can you post some sample code of what you are trying to trigger so I can try to replicate the issue?

Best regards,

Stevan