Security Hotspots are as important as Bugs, Vulnerabilities and Code Smells found on PR.
From a cost perspective, the best moment to tackle Security Hotspots is when the PR is created. At this time, everything is still fresh in the mind of the developer who created the PR (similar to issues) and so it's more efficient to do the review now rather than in 3 months.
For this reason, developers should be aware that Security Hotspots were found on their PR so they can review them immediately.
- We want that developers understand the difference between the changes that are needed to fix issues and the review that they have to do to make sure that the PR is clean -> it should be clear in the PR that vulnerabilities and security hotspots are not the same thing and do not require the same action.
As a developer, when my PR is analyzed and the diff contains Security Hotspots:
- I get a notification that my QG successes or fails
- I go to the ALM and check the details of my PR
- I see if my PR contain Security Hotspots and how many they are
- I understand that Security Hotspots are different from issues and that they require a different action: a review
- I understand that I need to perform this review on SQ
When I review the Security Hotspots of my PR :
- If I identify that the Hotspot is not a vulnerability, I mark the Hotspot as safe and I expect that the number of Hotspots decreases in the PR
- If I identify a vulnerability, I fix it in the code, I mark it as fixed on SQ and I expect that the number of Hotspots decreases in the PR
- If I don't know what is the Hotspot (and I need another Hotspot reviewer) or if I don't know if it's a vulnerability or not, I expect to see the same number of Hotspots
As a reviewer of a PR or as a team lead or quality manager who wants to assess the overall quality of the project/product, when the PR is analyzed, I want to check that all Security Hotspots are reviewed meaning that there are no more Security Hotspots in the PR anymore.
We will reuse the existing PR decoration mechanism, and update it to separate clearly vulnerabilities and hotspots to review. BitBucketServer has a limitation of a maximum of 6 items displayable in the decoration, so we will remove one of the two links to SQ to replace it with the hotspots count. We also will reorder items, following this pattern: