Why is rule S2077 reported two different ways?

SQ 8.6.0

When I call issues/search with parameter rules set to ‘java:S2077’ I get an array with 89 instances of S2077 being violated, with type VULNERABILITY, severity CRITICAL, and the message “Ensure that string concatenation is required and safe for this SQL query.” When I call hotspots/search, I get an array of many hotspots, which also have the same message. It seems that rule S2077 is sometimes triggered as a hotspot and sometimes as a vulnerability. Can you explain?

1 Like

Hi,

I’m assuming from the fact that you’re seeing this that you’ve been using SonarQube a while. Just like the SonarQube UX has evolved over time, the rules have as well. We add rules frequently, occasionally deprecate some, and often re-evaluate rules. That means that multiple rules have changed not just severity but also type over the years.

But when a rule changes type or default severity, we don’t update existing issues from that rule. They keep the type & severity they were ‘born’ with. That’s why you’re seeing this disparity.

 
HTH,
Ann

1 Like

Thanks! That explains what I’m seeing – including that some projects don’t report any S2077 cases as vulnerabilities, because those projects were created after the upgrade.

Is there a way to override this? That is, force old issues to change to the new settings? (I can think of several ways to kludge it, but I’m first wondering if this option has already been provided.

Hi,

Nothing has been provided specifically to address this case. What comes to mind is doing a search of issues by rule and a bulk update.

 
HTH,
Ann

Have you tried this? I did, and it leaves things in an inconsistent state, where they don’t show up in any lists and are only accessible through the individual issue keys. See Issues put into inconsistent state by api/issues/bulk_change

Hi,

I haven’t tried it. Generally it should work tho. Aaand I see from your other thread that we’re talking about transitioning to Security Hotspots. We’ve actually segregated Security Hotspots from issues so in retrospect I’m not surprised that that transition didn’t work. I really thought we were talking about Bugs/Vulnerabilities/Code Smells and Security Hotspots just didn’t cross my mind. Very sorry if I’ve steered you wrong.

And I’ve referred your other thread internally.

 
Ann

The situation here is that the default classification of some rules changed. For instance, java:S1104 changed from a minor vulnerability to a minor smell. So, I’m able to bulk-change those with issues/bulk_change, using set_type = ‘CODE_SMELL’ (and do_transition = reopen, which is kind of a kludge since the issues are already open, but bulk_change complains if do_transition isn’t set).

But rules S2077 and S2068 went from being vulnerabilities to hotspots, which, as I first described in this thread, left me with some instances (the “old” issues) tagged as vulnerabilities and other instances (the “new” ones – not really new code, but newly discovered by SQ, presumably due to the upgrade) tagged as hotspots.

There doesn’t seem to be a way to change hotspots into anything else. So I tried going the other way, but that doesn’t seem to work.

One of the kludges I alluded to earlier was:

  1. Copy the quality profile to a temp copy.
  2. Deactivate (in the copy) all the rules that changed from vulnerabilities to hotspots.
  3. Set the project to use the copy made in steps 1-2.
  4. Under project settings → general settings → housekeeping, change the setting to delete closed issues after X days, change it to 0.
  5. Rescan. This will delete all issues for the rules deactivated in step 2.
  6. Undo what was done in steps 3-4.
  7. Rescan. Now they’re back, but as security hotspots.

This works. Like I said, a kludge. And also loses the info about when they were first tagged (is there a way to set the creation date for an existing hotslot?).

If you know a better way, I’d be happy to hear it.