SQL calls that are flagged with S2077 in SQ 7.0 (Community) aren’t flagged in 8.5. I realize S2077 is now a hotspot, but I’m able to get other hotspots from 8.5 so that’s not the issue.
For instance, code that forms a String s by concatenating some literals, variables, and method calls, then calls c.prepareStatement(s) (where c is a Connection object) gets flagged in 7.0 but not 8.5.
Has the interprocedural analysis in 8.5 improved (over 7.0) so that it can detect that the pieces concatenated to form s are all locally generated, so no injection is possible? Or is it something else?
I’m sorry, it’s Java – the rule is squid:S2077 in 7.0 and java:S2077 in 8.5. (I see people here tend to refer to rules by only the second part, so I assume you make those unique, i.e., you never have rules A:C and B:C at the same time. Is that not the case?)
So you’re saying you CAN have A:C and B:C, but only if they’re essentially the same rule, applied to different languages A and B?
Although I’m specifically interested in Java, it seems my question is a generic one about how potential violations of S2077 are possibly getting filtered out. So an answer to this question might be useful for people using the other languages you listed.
For rules about general programming concepts, you can certainly have the same rule across languages. For instance, Java’s not the only language where it’s a good idea to have a default clause in your switch.
Fair point. But while the concepts flow seamlessly across languages, the implementations do not.
So investigation starts with the language the user’s working in, and if it’s relevant discussions follow internally about whether to make rule-level changes.
So if the answer to my question turns out to be relevant to C# as well, would we then want to add a C# tag, so that a C# user searching for threads about that rule would find it too? Or should people searching for a specific rule leave their language out of the search query, to catch multi-language cases like this? (Either way would work; just wondering what the preferred approach is on this site.)
I think I can answer my own question: at some point, SQ broke backwards compatibility in the web API for hotspots. So now when one calls the issues/search API call specifying rule java:S2077, it returns a count of 0, falsely implying there are no violations of that rule when, in fact, there are.
But then the UI is inconsistent. If I call issues/search with a non-existent rule key (“java:S9876”) and the countonly flag, I get a count of ALL issues. It does that rather than, say, return an error. But if I call issues/search with a rule classified as a hotspot, it returns 0, rather than behave like the other case (ignore the rule number and return the total issue count).
Returning 0 gives the misleading information that there are no violations of this rule, rather than the fact that violations of this rule are inaccessible through that call.
