False negative: typescript:S6418 : Hard-coded secrets are security-sensitive

Enterprise Edition v2025.1.1 (104738)
MQR Mode

Here’s the code, from an environment.ts file, that I think should be triggering the typescript:S6418 rule

PASSWORD: “052d3917-7592-40a1-8877-1f9302be02c4”,
password: “052d3917-7592-40a1-8877-1f9302be02c4”,
Review this potentially hard-coded password.

// these should raise sonar warning typescript:S6418
GOOGLE_API_KEY: “e1033a77-6f44-4fee-a6c9-5be735cd5d5d”

The “password” is flagged, but not the GOOGLE_API_KEY.

Note that the uppercase PASSWORD is also not flagged, so apparently typescript:S2068 is case sensitive.

I’ve verified that this rule is enabled in the security profile that I’m using for this project:

By adding uppercase copies of the “password” patterns, I was able to get a match on the uppercase PASSWORD, but a similar change to the secrets rule didn’t get any matches.

Is there other logic involved, beyond a simple pattern match on the variable name?

Hello @Paul_Harapiak! Thanks for your detailed feedback :smile:

The case-sensitivity issue for S2068 has been fixed in the v10.23.0 of the JS/TS plugin. Unfortunately, your SonarQube Server v2025.1.1 is using the v10.21.1 of the plugin. It’s fixed in the SonarQube Server v2025.3.0 onward and will be part of the next LTA release.

As for the GOOGLE_API_KEY issue, S6418 does not only check the variable/attribute name. It also checks that the Shannon entropy (i.e. the “randomness”) of the potential secret is high enough, to make sure that it looks like a real secret and not something like xxxx-xxxx-xxxx-xxxx.

This entropy threshold is defined in the randomnessSensibility parameter of the rule. You can change this value, but it is set to 5 by default. Here the entropy of e1033a77-6f44-4fee-a6c9-5be735cd5d5d is around 3.75, and therefore considered a false-positive by S6418.

For now, you can change this randomnessSensibility parameter of S6418 in your quality profile (doc). But we will investigate whether this default value is too high or not, we may be able to lower it without detecting too many false-positives.

If you have any other questions, please let us know! Feedback like yours improves the product a lot :smile:

1 Like

Thanks for the info, Gabin, I’ll work with that.

I’d say that if a generated GUID fails the randomness threshold, then it’s set to high :slight_smile:

1 Like