Quality gate passed without fixing vulnerability

We are on SonarQube Developer Edition, version 8.9.6.

According to SonarQube, we had 7 vulnerabilities in our project. All of them were the same issue as seen in the error message below:

However, since last week, the project is passing the quality gate and all these 7 issues are now marked as “Closed (Fixed)” and no longer show up in the report. The concerned part of the codebase is unchanged, but according to the Activity tab, all these issues suddenly became ok since May 5.

These are the quality profiles in use:

Is there any way for me to find out how or why these issues were marked as fixed and how to reopen them? Is there any audit trail available to see what happened here?

Thank you.


Unfortunately, there’s nothing easy I can point you to to track this down. Here are the things you should start by looking at:

  • Is the same profile still used to analyze the project? (You’re using Sonar way, so I guess so)
  • Is the rule still active in the relevant profile? (Sonar way isn’t editable, so I guess so
  • Have the Exclusions been edited in the UI to completely ignore those files?
  • Have the Exclusions been edited in the UI to ignore all issues on those files?
  • Have the Exclusions been edited in the UI to ignore issues from that rule on those files?
  • Have exclusions been set in the analysis parameters?
  • Have exclusions been set on the command line?
  • Have inclusions been set anywhere that don’t include the files?
  • Has sonar.sources been edited to omit those files? Note that this can be set in analysis properties and also overridden on the command line


1 Like

Thanks for the pointers @ganncamp. I couldn’t find anything off based on them though.

When I go to the Code section, I can see all the typescript source files there, so the files themselves are not excluded from the analysis I suppose.

And I couldn’t find anything unusual in the Project Settings > Analysis Scope > [Exclusions] sections either.

Exclusions are not set in the command line parameters either. The only arguments supplied in the command line are:
sonar-scanner -Dsonar.host.url="" -Dsonar.login="" -Dsonar.projectKey="" -Dsonar.sources="" -Dsonar.branch.name=""

The analysis parameters that you referred to, where can I find them?


There should be a sonar-project.properties file in project root.


Ah, ok. I don’t have such a file in the project root, so all those settings are passed as command line params.

When I click on an older issue’s timestamp, I see it’s history (when it was opened, modified, closed etc), but not much details about it. Is there any way to drill down into the history of these events to see exactly what happened?

It’s baffling why these issues decided to stopped being issues from a particular day :confused:


I guess I should have asked earlier about the rules in question. Vulnerabilities aren’t typically going to close themselves. But what you’re showing here is a Code Smell, and it could have been legitimately closed by E.G. adding a use of the z2 variable later in the code.

…And to answer your question, what you’re looking at is all the details we have. There’s nowhere to “drill down” to.


Ah :frowning:

For us, both the number of code smells (3.5k to 100) and the number of vulnerabilities (8 to 0) reduced. And all this happened on a particular date last week and there was no code change to fix any of these. These issues still exist in the code.

Thanks for your inputs!


You should double-check your analysis logs. Ideally you’ll compare a before and after. Also, are there any warnings on your project homepage?


1 Like

We do have a warning about Node.js version. But we did the Node.js upgrade a while ago and the issue I mentioned started from last week.


And by analysis logs, do you mean “sonarqube_installation_folder/logs”?


The analysis log is what’s output from the analysis command.