Code issue severity in Amazon Q Developer code reviews
Amazon Q defines the severity of the code issues detected in your code so you can prioritize what issues to address and track the security posture of your application. The following sections explain what methods are used to determine the severity of code issues and what each level of severity means.
How severity is calculated
The severity of a code issue is determined by the detector that generated the
issue. Detectors in the Amazon Q Detector Library are each assigned a severity using the Common
Vulnerability Scoring System (CVSS
The following table outlines how severity is determined based on the level of access and level of effort required for a bad actor to successfully attack a system.
| Level of Effort | ||||
|---|---|---|---|---|
| Not exploitable | Requires access to system | Internet with high LoE | Over internet | |
|
Level of access |
||||
| Full control of system or its output | N/A | High | Critical | Critical |
| Access to sensitive information | N/A | Medium | High | High |
| Can crash or slow down the system | Low | Low | Medium | Medium |
| Provides additional security | Info | Info | Low | Low |
| Best practice | Info | N/A | N/A | N/A |
Severity definitions
The severity levels are defined as follows.
Critical – The code issue should be addressed immediately to avoid it escalating.
Critical code issues suggest that an attacker can gain control of the system or modify its behavior with moderate effort. It is recommended that you treat critical findings with the utmost urgency. You also should consider the criticality of the resource.
High – The code issue must be addressed as a near-term priority.
High severity code issues suggest that an attacker can gain control of the system or modify its behavior with high effort. It is recommended that you treat a high severity finding as a near-term priority and that you take immediate remediation steps. You also should consider the criticality of the resource.
Medium – The code issue should be addressed as a midterm priority.
Medium severity findings can lead to crash, unresponsiveness, or unavailability of the system. It is recommended that you investigate the implicated code at your earliest convenience. You also should consider the criticality of the resource.
Low – The code issue does not require action on its own.
Low severity findings suggest programming errors or anti-patterns. You do not need to take immediate action on low severity findings, but they can provide context when you correlate them with other issues.
Informational – No recommended action.
Informational findings include suggestions for quality or readability improvements, or alternative API operations. No immediate action is necessary.
