I am currently evaluating SonarCloud for code security needs and have come across an issue I am hoping to clarify.
During my analysis of a .NET code repository, I noticed that SonarCloud does not seem to detect secrets or credentials within the app config file. This file often contain sensitive information such as database connection strings or API keys, I was expecting SonarCloud to flag them if any secrets were present.
Could anyone please confirm if:
SonarCloud is able to detect secrets within these types of configuration files?
There are any specific settings or configurations I need to apply in order to enable this detection?
If this functionality is not currently supported, is it something that will be added in future releases?
I was hoping Sonar would flag the fact that my connection string contains a user ID and password, as these credentials should not be committed to the codebase.Sometimes developers may accidentally commit non-prod or prod secrets, so I want to avoid that risk.
I ran some tests and the detection seems to work when your example is included in a web.config file (a Security Hotspot is raised), but not in app.config files.
After double-checking on my side, it looks like the problem is not how the file is called but the actual secret inside it.
password=Password1234! looks “too fake”, so our analyzer doesn’t raise an issue on it to avoid noise and false-positive fatigue. If you try with a more “real-looking” password like password=NkhAL5M26YAt, it should raise an issue in your code.
Hello!
Just to follow up one more time from our side.
Like my colleague @gabin.laigle mentioned earlier, this secret would be detected if it was not looking like a fake secret (in that case we would raise the vulnerability S6703).
Because of your feedback we were also able to identify that the Security Hotspot S2068 indeed does not raise on app.config files. I created a ticket to improve this in the future.
Thanks a lot for your feedback and for helping us to improve our product.
Wow - you are basically saying you ignore simple passwords! That seems crazy!
Real world systems unfortunately can (and do) sometimes have very silly passwords set - they absolutely should be caught!
Surely it is better to raise it and let the developer (or security hotspot expert if you wanted it classed as such) to choose to mark it safe than to simply ignore it on the basis that it is too simple and presumably probably not real because of course everyone has secure passwords
Have you met real people?
“back in the day” I worked somewhere that our dev SQL Server had an sa password…but our production one did not - and yes, that was a decision of a real person!
To clarify, some of our rules are designed to minimize false positives (such as S6703), while others like S2068 cast a wider net and trigger more broadly. In this case, we recognize that our current detection (on the latter rule) missed the issue, and we’re working to address it.
Ultimately, we agree that this password should be detected—just by different rules depending on their intended scope and sensitivity.
P.S. If you’d like to see what kind of “simple passwords” these rules (S6XXX) tend to ignore out of the box, check out the code!
Thanks for your response. I get that you would ignore placeholders / variable substitutions, but I really am shocked that you are ignoring any passwords at all just for being “too simple” or even for using repeated characters - I have known of pople using passwords for example where you have to change them every 3 months say, so you just add another repitition of the final character so all you have to remember is the original password + count of repititions rather than a new password every time.
Does this make it any less real a password no? Is it a terrible idea? Absolutely? Is it real? For sure!
Security is one of the areas, IMO, where you need to be strictest of all - so ignoring interpolation or placeholders fine, but ignoring “letmein” or “simple” or too short passwords - no no no. Let the client mark them as false positives but please do not assume that nobody could possibly be using short/simple/repeated passwords in the real world - anything that people CAN do, they WILL do!
Thanks for your feedback! I understand your concerns, and I think we’re already addressing what you’re looking for. As I mentioned, we have rules in place that will trigger in both of the scenarios you described. We also have a more specific rule designed to minimize false positives.
It’s important to note that overly broad rules with a high rate of false positives can actually increase risk, since people may start ignoring the alerts. Our approach aims to maintain effective detection while reducing unnecessary noise.
Sure thing - though arguably ignoring alerts is a choice so “more fool them” that do, but at least they are accountable for choosing the risk associated with making that choice, whereas the tooling simply ignoring passwords it thinks are too simple is not a choice for the user and they would likely be wholly unaware of this…so that’s where the increased risk comes from - trusting the tool and being unaware that it will not detect simple (but real!) passwords.
The main thing is that you cover this somewhere, in some rule - the danger is that this gets disabled/refactored at some point and you fall back to the code you pointed me to which will ignore essentially the least secure passwords that people may be using!
We can probably leave it there though if you are confident you have (and will always have) even the simple cases covered.
