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