Secret scanner misses the identification of login credentials in JS-Code

Rules and Languages
1

In a customer project we do have one JavaScript-file for which we already know that it contains login credentials which are leftover from the development process. The specific snippet are the following lines:

[...] 
FC_DEMO_USER_PASSWORD = 'Firmcloud1!', 
FC_DEMO_USER_NAME = 'customer@firm-cloud.org', FC_SW_USER_PASSWORD = 'Firmcloud1!', 
FC_SW_USER_NAME = 'sandworm@firm-cloud.org', 
[...]

Actually, I do not see that the Developer Edition of the SonarQube server (v2025.1.1) marks these lines as secrets for review under “Issues > Software Quality > Security” or “Security Hotspots”, which I hoped it would do.

I have added the line “**/*.js” to the list of path patterns to include under Administration > Configuration > Languages > Secrets and run a scan on the repository another time. Still, the SonarQube server does not detect these credentials.

Do you have a recommendation which setting I could try to set additionally, or where the lines containing the secret credentials should be listed in the SonarQube server? Or does the secret identification pattern implemented in the server not match to the lines printed above?
Your support would be appreciated.

Yours sincerely.

2

In addition to my post: Is there the possibility to import the results of other secret searching tools, like truffleHog, gitleaks or noseyparker?

17

Hello @FSC,

Thanks for your patience. I took the time to work on your case and I believe you are right.
I’ll let you know once the problem is fixed on our hand.

It’s always possible to load results from external linters using the SARIF format: Importing issues from SARIF reports | SonarQube Server Documentation

Regards
Alex

1 Like
21

Hello @FSC,

Thank you once again for your valuable feedback.

We have updated our analyzer to make rule S2068 case-insensitive, which addresses the false negative you encountered. Additionally, we have aligned the JS/TS implementation with our other languages to support the detection of the keyword “passphrase” by default.

Please let us know if these changes improve your experience or if you have any further suggestions.

Alex

1 Like