our security department is involved in configuring the quality profiles for each language used.
They insist that a number of rules defined by them is running as a subset in each quality profile.
It started in 2017, they simply selected all rules that contain the tag “cwe”.
In the meantime there were only small changes, but now it’s time for an extensive overhaul -
think of all the security related changes in recent Sonarqube versions.
It’s like that =
i.e. a Java rule as “Unused assignments should be removed” that has the tag cwe and category code smell creates findings that have to be discussed with the security department - this causes displeasure among developers. AFAIK modern java compilers strip off dead code.
Now my pragmatic approach would be to strip of all rules that have the tag cwe but not the category vulnerability (i.e. code smell) and activate all rules that have the category vulnerabililty instead, means i would additionally also use the non cwe rules that have the vulnerability category.
CWE – Common Weakness Enumeration (CWE™) is a formal list or dictionary of common software weaknesses that can occur in software’s architecture, design, code or implementation that can lead to exploitable security vulnerabilities.
According to which criteria are the CWE rules categorized by Sonarsource (code smell, vulnerability …) ?
I assume all cwe top 25 have the tag cwe and category vulnerability, right ?
I’ve put this posting to the clean code discussions category to get helpful arguments from other Sonarqube users and Sonarsourcers.
Is my pragmatic approach - choosing the rules with category vulnerability instead of useless discussions about rules categorized as code smell by Sonarsource - the right way or do i miss something ?
would have been tagged CWE. Is it a “vulnerability”? Well, that probably depends on what the obsolete function is and whether or not it was obsoleted because of exploits/vulnerabilities. But it’s likely that such a rule would have been classed as a Code Smell on our side.
Rubric
Bug: Something that’s wrong or potentially wrong.
Code Smell: Something that will confuse a maintainer or cause them to stumble in their reading of the code.
Vulnerability: Something that’s wrong which impacts the application’s security and therefore needs a fix.
Hotspot: An optional protection is missing and the developer needs to do a review before deciding whether to apply a fix.
So if using an obsolete function is just “Something that will confuse a maintainer or cause them to stumble…” then why does it merit a CWE entry? Security folks are paranoid vigilant. Talk for very long to one and they’ll tell you just about anything can be a vulnerability. That’s why null pointer dereference has a CWE listing (CWE-476).
Oh right. How to handle this pragmatically. IMO it would be sensible of the security department to ignore Code Smells. But would I turn those rules off? Probably not. After all, you still want to be alerted to
At least, that’s my personal take and historical recollection. But its been a while since I was writing rules. And there’s been a lot of work on rules since then. So maybe someone with more recent experience will also speak up.
Exactly, that’s the point, paranoia all around
Declaring code smells as security relevant will lead / leads to developers “working around”.
That’s also my and the developers point.
Don’t want code smells to be removed, the developers themselves want code smells checked too, but without useless discussions with a (sometimes paranoid) security team.
The question is, upon what does Sonarsource categorize a cwe as a code smell or vulnerability ?
