While running an analysis, {instance} raises an issue every time a piece of code breaks a coding rule. The set of coding rules is defined through the associated [quality profile](/instance-administration/quality-profiles/) for each language in the project.
+### Issue Types
+
+There are three types of issues:
+
+1. **Bug** – A coding error that will break your code and needs to be fixed immediately.
+1. **Vulnerability** – A point in your code that's open to attack.
+1. **Codesmell** – A maintainability issue that makes your code confusing and difficult to maintain.
+
+### Issue Severity
+
Each issue has one of five severities:
1. **BLOCKER**
But there are times when a simple laundry list of contributing locations isn't enough to understand an issue. For instance, when a null pointer can be dereferenced on some paths through the code, what you really need are issue flows. Each flow is a _set_ of secondary locations ordered to show the exact path through the code on which a problem can happen. And because there can be multiple paths through the code on which, for instance a resource is not released, {instance} supports multiple flows.
-
-## Lifecycle of Code Smell, Bug, and Vulnerability Issues
+## Issues lifecycle
### Statuses
After creation, issues flow through a lifecycle, taking one of five possible statuses:
Issues are automatically reopened (status: Reopened) when:
* an issue that was manually Resolved as Fixed(but Resolution is not False positive) is shown by a subsequent analysis to still exist
-### Security Hotspot Issue Lifecycle
-Security Hotspot issues have a dedicated lifecycle. They aren't considered actionable, and must be reviewed by a user with the "Administer Security Hotspots" permission.
-
-## Lifecycle of Security Hotspot Issues
-Security Hotspot issues have a dedicated lifecycle. They aren't considered actionable, and must be reviewed by a user with the "Administer Security Hotspots" permission.
-
-### Statuses
-After creation, Security Hotspot issues flow through a dedicated lifecycle, taking one of four possible statuses:
-
-* **Open** - set by {instance} on new issues
-* **Resolved** (Won't Fix) - set automatically by {instance} when a Security Auditor Accepts the fix done by a developer on a Manual Vulnerability or when an Open Hotspot or Manual Vulnerability is Cleared by a Security Auditor.
-* **To Review** - set automatically when a developer requests a security auditor to Review the fix she has done on a Manual Vulnerability
-* **Reopened** - set when a developer Dismisses an Open Manual Vulnerability or when a Security Auditor manually reopens issues in order to run a new audit on already Resolved issues
-
-Security Hotspot issues are only ever closed if the code containing the Security Hotspot is deleted. A Security Hotspot may also become Removed if the rule which identified the hotspot is removed from the project's Quality Profile.
-
## Understanding which Issues are "New"
To determine the creation date of an issue, an algorithm is executed during each analysis to determine whether an issue is new or existed previously. This algorithm relies on content hashes (excluding whitespace) for the line the issue is reported on. For multi-line issues, the hash of the first line is used. For each file (after detection of file renaming), the algorithm takes the base list of issues from the previous analysis, and tries to match those issues with the raw issue list reported by the new analysis. The algorithm tries to first match using the strongest evidence, and then falls back to weaker heuristics.
* **Severity change** - This is the middle ground between the first two options. Yes, it's a problem, but it's not as bad a problem as the rule's default severity makes it out to be. Or perhaps it's actually far worse. Either way, you adjust the severity of the issue to bring it in line with what you feel it deserves. Requires Administer Issues permission on the project.
* **Resolve** - If you think you've fixed an open issue, you can Resolve it. If you're right, the next analysis will move it to closed status. If you're wrong, its status will go to re-opened.
-Additionally, Security Hotspots allow the following:
-
-* **Detect** - Confirms a Security Hotspot as a true issue and manually opens a Vulnerability. Requires Administer Security Hotspots on the project.
-* **Clear** - Marks a Security Hotspot or manually opened Vulnerability as being without issue and shouldn't be fixed. Requires Administer Security Hotspots on the project.
-* **Request Review** - Request that a Security Auditor review changes made to remediate a manually opened Vulnerability.
-* **Reject** - After review ,reject the remediation for a manually opened Vulnerability and return it to an open issue. Requires Administer Security Hotspots on the project.
-
If you tend to mark a lot of issues False Positive or Won't Fix, it means that some coding rules are not appropriate for your context. So, you can either completely deactivate them in the quality profile or use issue exclusions to narrow the focus of the rules so they are not used on specific parts (or types of object) of your application. Similarly, making a lot of severity changes should prompt you to consider updating the rule severities in your profiles.
As you edit issues, the related metrics (e.g. New Bugs), will update automatically, as will the Quality Gate status if it's relevant.
--- /dev/null
+---
+title: Security Hotspots
+url: /user-guide/security-hotspots/
+---
+
+## What is a Security Hotspot?
+
+Unlike Vulnerabilities, Security Hotspots aren't necessarily issues that are open to attack. However, Security Hotspots highlight security-sensitive pieces of code that someone focused on security needs to review. Upon review, that security-focused developer or reviewer might find that a Security Hotspot is in fact a Vulnerability that needs to be fixed.
+
+## Why are Security Hotspots Important?
+
+Security Hotspots help focus the efforts of developers or reviewers who are manually checking security-sensitive code. Reviewing Security Hotspots allows you to:
+
+* **Fix security issues** – Reviewing Security Hotspots gives you the opportunity to detect true vulnerabilities and ensure issues are fixed before merging pull requests or releasing your branch.
+* **Learn about security** – {instance} explains why your code was identified as a Security Hotspot and the link between your Hotspots and well-known attacks or weaknesses such as SQL Injection, Weak Cryptography, or Authentication. Knowing this makes developers aware of when they're working on security-sensitive code and helps them avoid creating Vulnerabilities.
+
+## Security Hotspot Lifecycle
+Security Hotspots have a dedicated lifecycle and must be reviewed by a user with the "Administer Security Hotspots" permission.
+
+### Status
+
+Through the lifecycle, a Security Hotspot takes one of the following statuses:
+
+* **Open** - set by {instance} on new Security Hotspots
+* **Resolved** (Won't Fix) - set automatically by {instance} when a reviewer accepts the fix done by a developer on a Manual Vulnerability or when a reviewer clears an open Hotspot or manual Vulnerability.
+* **To Review** - set automatically when a developer requests a review on a manual Vulnerability.
+* **Reopened** - set when a developer dismisses an open manual Vulnerability or when a reviewer manually reopens a resolved Security Hotspot in order to run a new audit on it.
+
+A Security Hotspot is only closed if the code containing it is deleted. A Security Hotspot's status will be "Removed" if the rule in the project's Quality Profile identifying it is removed.
+
+### Actions
+
+Security Hotspots allow the following actions:
+
+* **Detect** - Confirms a Security Hotspot as a true issue and manually opens a Vulnerability. Requires "Administer Security Hotspots" permission on the project.
+* **Clear** - Marks a Security Hotspot or manually opened Vulnerability as being without issue and shouldn't be fixed. Requires "Administer Security Hotspots" permission on the project.
+* **Request Review** - Request that a reviewer analyzes changes made to fix a manually opened Vulnerability.
+* **Reject** - After review, reject the fix for a manually opened Vulnerability and return it to an open issue. Requires "Administer Security Hotspots" permission on the project.
+
+### Workflow
+
+If a reviewer with "Administer Security Hotspots" permission determines a Hotspot is actually a Vulnerability, the reviewer changes the status from its current state (probably **Open**) to **Detect**. This converts the Security Hotspot to a Vulnerability, and the developer who last touched the line will receive "new issue" notifications (if she's signed up to get them).
+
+Once a Vulnerability is *Detect*ed at a Security Hotspot location, the following occurs:
+
+1. The Security Hotspot is assigned to the appropriate developer, and the developer makes a fix.
+2. The developer must then **Request Review** *via the UI*. The request moves the Vulnerability back to Security Hotspot.
+3. The reviewer either **Accepts** or **Rejects** the fix.
+ * Accepting the fix marks the Security Hotspot "Won't Fix."
+ * Rejecting the fix turns the Security Hotspot back into a Vulnerability and puts it back in the developer's queue.
+
+### Marking a Hotspot "Won't Fix"
+The `Won't Fix` designation indicates that a Hotspot has been reviewed and there is no way, as of now, to exploit this piece of code to create an attack.
url: /user-guide/security-reports/
---
-## What do the Security Reports show?
-The Security Reports are designed to quickly give you the big picture on your application's security, with breakdowns of just where you stand in regard to each of the [OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10), and [SANS Top 25](https://www.sans.org/top25-software-errors) categories, and [CWE](http://cwe.mitre.org/)-specific details.
+## What do Security Reports show?
+Security Reports quickly give you the big picture on your application's security, with breakdowns of just where you stand in regard to each of the [OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10), and [SANS Top 25](https://www.sans.org/top25-software-errors) categories, and [CWE](http://cwe.mitre.org/)-specific details.
+
The Security Reports are fed by the analyzers, which rely on the rules activated in your quality profiles to raise security issues. If there are no rules corresponding to a given OWASP category activated in your Quality Profile, you will get no issues linked to that specific category and the rating displayed will be A. That won't mean you are safe for that category, but that you need to activate more rules (assuming some exist).
-## What's the difference between a Hotspot and a Vulnerability?
+## What's the difference between a Security Hotspot and a Vulnerability?
Vulnerabilities are points in the code which are open to attack.
Security Hotspots are security-sensitive pieces of code that should be carefully reviewed by someone with a security auditor hat. This person can be:
* a member of the development team who is more sensitive to security problems
* someone outside the development team contracted for the purpose of reviewing these Hotspots.
-The main goal of Security Hotspots is to help focus the efforts of the security auditors who manually review application source code. The second goal is to educate developers and to increase their security-awareness.
-Having a Hotspot in your application does not mean there is a problem. What it does mean is that a human, preferably a security auditor/expert should look over the code to see if the sensitive piece of code is being used in the safest manner.
-
-## Why are some Hotspot and Vulnerability rules very similar?
-They are overlapping on purpose. The Hotspot rule is supposed to include all matches of the Vulnerability rules, and cases where the taint analysis engine is not able to detect vulnerabilities. For example, switching from one language to another (XML, JNI, etc...) or using some third party libraries will prevent the taint analysis from finding vulnerabilities. A Vulnerability rule highlights security threats only when it has a high level of confidence, which means that it will always miss some of them. Whereas a Hotspot rule guides secure code reviews by showing code where those issues might lurk, even if it could not detect any vulnerability.
-
-## Why don't I see any Hotspots?
-They are three reasons you might not see any Hotspots:
-* it is possible you really have none of them because the code has been written without using any security-sensitive API.
-* it is possible that Hotspot rules are available, but not yet activated in your Quality Profile, and so naturally no issues are raised
-* it is more likely that the analyzer for the langauge you're using does not yet offer Hotspot rules, and so it doesn't raise any Hotspots regardless of the quality of how many are actually there, but this last option will disappear over time.
-
-## Why don't I see any Vulnerabilities?
-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 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).
-
-## What happens after my Hotspot becomes a Vulnerability?
-Once you've *Detect*ed that there really is a problem at a Hotspot location, it will be assigned to the appropriate developer, who will make a fix, and must then `Request Review` *via the UI*. That request moves the issue from Vulnerability back to Hotspot. From there, it's up to the security auditor to either `Accept` or `Reject` the fix. Accepting the fix will mark it `Won't Fix`, and rejecting it will turn it back into a Vulnerability, putting it back in the developer's queue.
+The main goal of Security Hotspots is to help focus the efforts of someone manually review application source code. The second goal is to educate developers and to increase their security-awareness.
+Having a Hotspot in your application does not mean there is a problem, but that someone should review the code to see if the sensitive piece of code is being used in the safest manner.
-## What does it mean for a Hotspot to be marked "Won't Fix"?
-The `Won't Fix` designation is used to indicate that a Hotspot has been reviewed and there is no way, as of now, to exploit this piece of code to create an attack.
+For more details, see [Security Hotspots](/user-guide/security-hotspots/)
+## Why are some Security Hotspot and Vulnerability rules very similar?
+They are overlapping on purpose. The Security Hotspot rule is supposed to include all matches of the Vulnerability rules, and cases where the taint analysis engine is not able to detect vulnerabilities. For example, switching from one language to another (XML, JNI, etc...) or using some third party libraries will prevent the taint analysis from finding vulnerabilities. A Vulnerability rule highlights security threats only when it has a high level of confidence, which means that it will always miss some of them. Whereas a Security Hotspot rule guides secure code reviews by showing code where those issues might lurk, even if it could not detect any vulnerability.
+## Why don't I see any Vulnerabilities or Security Hotspots?
+You might not see any Vulnerabilities or Security Hotspots for the following reasons:
+* You don't have any because the code has been written without using any security-sensitive API.
+* Vulnerability or Security Hotspot rules are available but not activated in your Quality Profile so no Security Hotspots or Vulnerabilities are raised.
+* The analyzer for your language might only currently offer a few rules and won't raise any or only a small number of Vulnerabilities or Security Hotspots.
"/user-guide/fixing-the-water-leak/",
"/user-guide/project-page/",
"/user-guide/issues/",
+ "/user-guide/security-hotspots/",
"/user-guide/rules/",
"/user-guide/security-rules/",
"/user-guide/built-in-rule-tags/",
"/user-guide/applications/",
"/user-guide/portfolios/",
"/user-guide/issues/",
+ "/user-guide/security-hotspots/",
"/user-guide/rules/",
"/user-guide/security-rules/",
"/user-guide/built-in-rule-tags/",
"/user-guide/applications/",
"/user-guide/portfolios/",
"/user-guide/issues/",
+ "/user-guide/security-hotspots/",
"/user-guide/rules/",
"/user-guide/security-rules/",
"/user-guide/built-in-rule-tags/",
projects / sonarqube.git / commitdiff