Include additional Spring Boot properties in java:S6437

Rules and Languages
,
1

After Upgrading SonarQube Server from 9.9 to 2025.1, I played around a bit with the secret detection. On this journey I came across java:S6437. The rule exists since a while now but got a lot of enhancements since 9.9.

Since we have a lot of Spring Boot related projects I checked the coverage of credentials in Spring Boot properties files. The coverage is really really good so far. But I found some possible enhancements.

The following properties described in the Common Application Properties :: Spring Boot reference where not found by SonarQube:

spring.artemis.embedded.cluster-password=verysecure
spring.couchbase.authentication.jks.password=verysecure
management.prometheus.metrics.export.pushgateway.token=verysecure
spring.couchbase.authentication.jks.private-key-password=verysecure
spring.couchbase.authentication.pem.private-key=verysecure
spring.couchbase.authentication.pem.private-key-password=verysecure
spring.kafka.admin.ssl.key-store-key=verysecure
spring.kafka.ssl.key-store-key=verysecure

The following property was also not recognized as a hardcoded secret. It might be a bit more tricky as the ‘my-registration’ part is dynamic. It is the name of the actual client registration and there can be multiple of them in a config file.

spring.security.oauth2.client.registration.my-registration.client-secret=verysecure

I also found that default values in placeholders are not detected by the rule. Given the following example:

management.dynatrace.metrics.export.api-token=verysecure
management.dynatrace.metrics.export.api-token=${someprop:verysecure}

The first line is correctly marked as a hardcoded secret. The second one is not marked as hardcoded secret, as it contains a placeholder. But the placeholder contains a default value. So it is possible that we end up with the hardcoded secret, when “someprop” is not defined at runtime. Maybe it is posible that default values can also be marked as hardcoded secrets by the rule.

Regards
Daniel

7

Hi @furti

Thank you for your feedback!
I created a ticket Jira for improving the S6437 rule with new properties.

Regarding placeholders with default values:
We believe that using placeholders is a step in a good direction. It means that the developer is aware about the mechanism of replacing the placeholder in different environments. We believe that default values are for local development. If we raise the issues on placeholders with default values, then the rule will be annoying for the developers and they will start to ignore the rule. We would like to avoid this situation.

Best
Marcin Stachniuk

9

Hi @Marcin_Stachniuk

thanks for your reply.

I understand the problem with the local environment. And it is perfectly fine for me if this is kept as it is today.
Maybe a few things that might be considered here.

From my experience, at least in our company we often times work with dedicated properties per environment. And then we have a application-local.properties that would contain the hardcoded credentials. In this case you already raise issues for local development credentials.

And in some situations even for local development you need to access external systems. For example we have a system that needs to fetch data from Jira or Confluence. Would be too complex to setup confluence and Jira locally. So it needs to call the dev instance of Jira. Now I can’t add the credentials to the properties as they work in a live environment.

And I see this a lot. Thinking that those are only credentials for development. But they work in an environment that is accessible over the Network by anybody.

For those reasons our policy is to have no credentials at all in the source code.

11

Hi @furti

In that case (someone have a real JIRA secret in application-local.properties) then another rule: Secrets static code analysis should detect it. It is important that this secret is real, the verysecure value will be not detected.

This implement your policy about not having credentials in the source code.

Best
Marcin Stachniuk