How to scan other project files for hard-coded secrets?

SonarQube Cloud
1

What is needed

I would like other project files to be scanned for hard coded secrets. One example in a Java project would the application.properties file.

Setup

On my branch there is a new file in the root called sonar-project.properties with this content:

sonar.projectKey=my_project
sonar.sourceEncoding=UTF-8
sonar.maven.scanAll=true

pom.xml contains:

                <plugin>
                    <groupId>org.sonarsource.scanner.maven</groupId>
                    <artifactId>sonar-maven-plugin</artifactId>
                    <version>4.0.0.4121</version>
                </plugin>

There is a Sonar workflow file as well: .github/workflows/sonar_cloud.yaml with this step:

run: mvn -e -X -f pom.xml -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=my_project

This step runs when I commit a change to my branch.

Observations

I committed an application.properties file with this line:

password.secret.key=mySecretRootAccess!@#$%

SonarCloud

SonarCloud reports no issues at all but I expected to report on the hard-coded password.

SonarQube for IDE

In my IntelliJ IDE, SonarQube for IDE for this file reports: This file is not automatically analyzed.
Looking at the SonarQube for IDE logs I see:

Trigger: BINDING_UPDATE
[BINDING_UPDATE] 4 file(s) submitted
File 'application.properties' excluded: file is classified as Java resource in project structure
Configuring analysis with org.sonarlint.intellij.java.JavaAnalysisConfigurator

I expect the file to be automatically analyzed.

When I manually trigger the SonarQube for IDE analyses in the IDEA, I see few other issues reported but not this particular line. Here are some examples of issues reported for other lines:

Google API keys should not be disclosed
Slack bot tokens should not be disclosed
Credentials should not be hard-coded

I expect the line with password.secret.key=mySecretRootAccess!@#$% to be reported on but that is not the case.

Any help would be appreciated.
Thanks!

3

Hello,

First you should know it is possible to customize the files that are considered by the Secret Detection engine in SonarQube Server or Cloud thanks to 2 properties:

  • sonar.text.inclusions.activate
  • sonar.text.inclusions

This configuration has an impact only on these secret rules.

application.properties files are normally used in the context of Spring and we have a pretty good coverage of Spring in general. I’m not aware of an entry called password.secret.key that could appear by default in an application.properties file. That could explain why we don’t detect what you expect. Also we have some heuristics in place to avoid making noise. The fact that the key and the value contain both “secret” and that “mySecretRootAccess!@#$%” is looking like a fake secret can be the root cause of the unexpected false-negative.
In you case, if a rule should be triggered, it would be that one: S6418: Hard-coded secrets are security-sensitive

I’m curious to know if you are evaluating Sonar’s capabilities or if you are facing a real life use case of false-negative. Can you clarify in which context you are?

Thanks
Alex

4

Hello Alex

Yes, we are facing a real-life use case of false-negative.
Here it is: vertex-ai.credentials.json.base64=....

This credential was committed to GitHub. We would like to prevent this in the future.

I tested different configurations, even tested with the sonar.text.inclusions configuration, and used the password.secret.key property to make it easy for SonarQube to spot the issue with hard-coded secret, but that did not work at all.

Do you know how to configure SonarQube to sport these hard-coded secrets so that we don’t have to look for a different tool?

Thanks!

5

Thanks for your patience.

Detecting such secrets is possible, but it requires a custom configuration rather than being available by default. The SonarQube Server (Enterprise Edition) includes a feature called Custom Secret, which enables you to define specific patterns for detection.

With this pattern config:

matching:
  pattern: .*\.credentials\..*\.base64.*

… you get what you expect:

image
image3970×1526 375 KB

That said, I believe it would make sense to detect based64-encoded credentials out of the box.
I’ll discuss it with our eng. team and see if we can provide this feature out of the box for SonarQube Server and Cloud.

Alex