You might not see any Vulnerabilities for more or less the same reasons as for Hotspots, but it may be more surprising for Vulnerabilities because you may see some Vulnerabilities reported in the Project homepage, while there are none in the Security Reports. This is because the language analyzer may not yet provide the "Security Standards" metadata required for issues to be visible on the Security Reports. This metadata is basically the link between a Rule (and its issues) and the "OWASP Top 10" or "SANS Top 25" categories. Without this link, there is no way to associate an already existing Vulnerability to the Security Standard categories and so to display security issues correctly in the reports. Every analyzer version released by SonarSource after July 2018 should feed the "Security Standards" and be compatible with the Hotspot issue type.
## I'm a developer. Should I care about Hotspots?
-Probably not. Hotspots, as such, aren't really actionable. They simply mark *potential* problems, so there's really nothing to do immediatly on the code. That's why you don't receive notifications when Hotspot issues are raised, and why Hotspots aren't shown in the Issues page by default.
+Probably not. Hotspots, as such, aren't really actionable. They simply mark *potential* problems, so there's really nothing to do immediately on the code. That's why you don't receive notifications when Hotspot issues are raised, and why Hotspots aren't shown in the Issues page by default.
## What if my Hotspot really marks a Vulnerability?
If you look at the code where a Hotspot is raised and realize that there really is a problem, click on the current status (probably `Open`) to register that you've *Detect*ed a Vulnerability at that point in the code. Once you do, it will be converted to a Vulnerability, and the developer who last touched the line will receive "new issue" notifications (if she's signed up to get them).
projects / sonarqube.git / commitdiff