Nowadays, developers should be aware of security aspects for the code they produce. And we think that SonarQube can help them becoming familiar with security all along the development process and even help them learning best practices.
In this regards, Security Hotspots can be highly valuable for the developers.
SonarQube should invite developers to have a look at hotspots from the early beginning of the code quality journey, and provide a UX that presents hotspots at the right time and in a convenient way for developers.
As a developer, I expect to see that security hotspots have been detected in the code of the project I’m working on so that:
- I understand that I should pay attention to some sensitive pieces of code (use case: education)
- I can possibly detect true vulnerabilities, and this way make sure that these security issues are fixed before I merge my PR / release my branch (use case: fix security issues)
This MMF focuses on the use cases where developer is taking a look at the master / a long-lived branch before releasing.
When releasing a project:
As a developer who doesn’t know about Security, I want that:
- SonarQube helps me understand what hotspots are
- SonarQube helps me identify and focus on the hotspots that are in my code
- SonarQube helps me to understand why the piece of code is sensitive = identified as hotspot
- SonarQube help me to understand that hotspots can lead to concrete issues
- SonarQube help me to understand what’s the link between those hotspots and well-known attacks or weaknesses such as “SQL Injection”, “Weak Cryptography”, “Authentication”
As a developer who understand what hotspots are, I want to:
- Review the hotspots:
- Identify hotspot as vulnerabilities so that they should be fixed before releasing (make the QG fails)
- Dismiss hotspots because no fix is required
- Ask for a confirmed security reviewer to review those hotspots.
As a developer not interested by security, I want to continue my release without taking care of the hotspots
- The concept of hotspots is added to SQ default landing page, which will now also display the number of open hotspots in the instance
- The project overview changes to now display the number of open hotspots and hotspots on new code together with vulnerabilities as part of a security domain
- The issues pages (global and project) clearly display by default hotspots in addition to the other types of issues:
- Hotspots appears in a different way then the other issues, to show that hotspots are not true issues
- Additional explanations are provided for hotspots: an explanation and a link to the documentation the first time the user selects the hotspots, and an info tooltip that remains.
- The "Standard" facet is expanded as soon as you filter on hotspots
- Assignee is displayed so that developers can see and change the assignee
- The measures page shows the number of hotspots in the security domain, and the user can drilldown into the files hierarchy, see the number of hotspots on folders and files and see hotspots in the code
- The code page also shows the number of hotspots on folders and files, and displays hotspots in the code
- Project activity offers a new custom graph that presents the evolution of open hotspots. The graph will not part of the standard ones, since hotspots are likely to be reopened by auditors as part of the normal lifecycle.
Make sure to activate comment mode to see where the changes are (top bottom right).
Link to the mockups https://invis.io/DKRA6CXMS3R#/355164153_Overview