Select any row in the Code Weaknesses table to open the issue side panel. The side panel provides detailed context for investigation and remediation.
Investigate a code weakness issue
General details
The top section of the side panel displays the following fields:
Field | Description |
|---|---|
Severity | The severity level of the code weakness |
Status | The current resolution status (New, In Progress, Resolved) |
Assignee | The user assigned to the issue |
SLA | The SLA compliance status, calculated from the issue creation date and the severity-based target resolution window |
Backlog Status | The backlog classification of the issue (New, Active, Stale) |
Urgency details
The Urgency Details section provides the contextual risk signals that determine the urgency classification of the code weakness issue. Urgency extends beyond static severity by incorporating runtime and business context.
Signal | Description |
|---|---|
Urgency Level | The computed urgency classification: Top Urgent, Urgent, Not Urgent, or Not Applicable. The urgency level is determined by the combination of all contextual signals |
Application Criticality | The highest criticality level among all applications linked to the affected assets. If no application is attached, the value is "None." Link the affected asset to the relevant application to ensure accurate urgency calculation |
Application Environment | The highest-risk environment among all applications associated with the issue (Production, Staging, Pre-Staging, Dev, Testing) |
Access Sensitive Data | Indicates whether at least one deployed asset affected by the code weakness has access to sensitive data |
Leverage Privileged Capabilities | Indicates whether at least one deployed asset affected by the code weakness has the ability to leverage privileged capabilities |
Affected Assets | The number of deployed cloud assets affected by the code weakness |
Is Deployed | Indicates whether the code weakness affects any deployed assets. A deployed code weakness represents a higher risk than a code weakness that exists only in code |
Internet Exposed | Indicates whether at least one affected deployed asset is accessible from the internet, increasing the likelihood of exploitation |
Important
Important: Urgency signals are populated only when the SAST asset is traced to deployed cloud resources through the Code-to-Cloud mapping. If no Code-to-Cloud trace exists, urgency signals display as Not Applicable
Code weakness details
The Code Weakness Details section provides classification and context for the detected weakness:
CWE ID: The Common Weakness Enumeration identifier with a link to the CWE entry
CWE Name: The human-readable name of the weakness category (such as SQL Injection, Cross-site Scripting)
OWASP Category: The OWASP Top 10 category the code weakness maps to
Language: The programming language of the affected source code file
Data Flow: The data flow trace from the source (user input entry point) to the sink (vulnerable function call), when available. The data flow trace enables developers to understand the full path of tainted data through the application
Code evidence
The Code Evidence section displays the source code context of the code weakness:
Repository Name: The name of the repository containing the code weakness
File Path: The full path to the affected file with a link to the VCS provider
Code Block: The source code snippet with highlighted lines indicating the specific code weakness
Commit Details: The Git author, commit hash, and commit timestamp of the commit that introduced the code weakness
Code-to-Cloud graph
The Code-to-Cloud graph visualizes the traceability path from the source code file containing the code weakness in the repository to the deployed cloud resource. The Code-to-Cloud graph enables you to understand the blast radius of the code weakness by identifying which production assets inherit the vulnerable code
Understand SLA compliance
Each code weakness issue is tracked against an SLA target based on the issue severity. The SLA status is displayed in the issue side panel under General Details.
SLA Status | Description |
|---|---|
Within SLA | The issue is within the severity-based remediation window |
Approaching | The issue is nearing the SLA deadline. Prioritize remediation |
Overdue | The issue has exceeded the SLA deadline. Escalate or reassign |
The SLA calculation uses the issue creation timestamp and the configured severity-to-target-days mapping. Resolved issues stop the SLA clock at the resolution timestamp
Prioritize code weakness issues
Effective prioritization of code weakness issues requires evaluating multiple contextual signals beyond static severity. Cortex Cloud provides two complementary prioritization mechanisms:
Urgency-based prioritization
Urgency incorporates runtime and business context to surface the code weaknesses that pose the greatest operational risk. Prioritize code weakness issues using the following urgency hierarchy:
Urgency Level | Criteria | Recommended Action |
|---|---|---|
Top Urgent | The code weakness affects a deployed, internet-exposed asset in a production environment with critical application criticality, and the weakness is in a high-risk CWE category (such as CWE-89 SQL Injection, CWE-78 OS Command Injection) | Remediate immediately. Apply the fix and escalate to a Case |
Urgent | The code weakness affects a deployed asset in a staging or production environment, or the affected asset accesses sensitive data | Remediate within the current SLA window |
Not Urgent | The code weakness exists only in code (not deployed), or the affected asset is in a development or testing environment with low application criticality | Schedule for remediation during the next maintenance cycle |
Not Applicable | No Code-to-Cloud trace exists for the affected asset. Urgency signals cannot be computed | Establish Code-to-Cloud traceability by linking the repository to the relevant application |
Severity-based prioritization
Severity reflects the inherent risk of the code weakness based on the detection rule and CWE classification. Use severity as the baseline filter:
Severity | Remediation Priority |
|---|---|
Critical | Immediate remediation required. The code weakness enables remote code execution, SQL injection, or authentication bypass with low attack complexity |
High | Remediate within the current sprint. The code weakness exposes a significant attack vector such as XSS or path traversal |
Medium | Schedule for remediation. The code weakness requires specific conditions to exploit or has limited impact |
Low | Address during routine maintenance. The code weakness has minimal security impact |
Informational | No action required. The finding is advisory |
Take action on code weakness issues
The Code Weaknesses page supports the following actions:
Change resolution status
Update the resolution status to track remediation progress.
From the main issues table: Right-click on an issue in the table → → [Select a status]
From the side-card: Status field → [Select a status]
Status values: New: The issue has not been triaged; In Progress: Remediation is underway; Resolved: The code weakness has been fixed and verified.
Assign an issue
Assign a code weakness issue to a specific user for remediation.
From the main issues table: Right-click on an issue in the table → → [Select a user]
From the side-card: Assignee field → [Select a user]
Change severity
Modify the severity level of a code weakness issue.
From the main issues table: Right-click on an issue in the table → → [Select a severity]
Note: This action can only be performed from the main issues table and is not available in the issue side panel.
Apply fix guidance
For code weakness issues, the side panel provides fix guidance specific to the weakness type and programming language. Fix guidance is accessed from the Actions tab in the issue side card.
Select the issue row to open the side panel.
Select the Actions tab in the side card.
Review the Manual Fix Suggestion field in the Actions tab.
The fix guidance includes:
A description of the code weakness and the secure coding pattern that resolves the weakness
Language-specific remediation code samples demonstrating the secure alternative
The specific function, method, or code pattern that requires modification
Example: fix guidance for a SQL Injection weakness (CWE-89)
Replace dynamic string concatenation in SQL queries with parameterized queries or prepared statements.
Before (vulnerable):
query = "SELECT * FROM users WHERE username = '" + user_input + "'" cursor.execute(query)
After (secure):
query = "SELECT * FROM users WHERE username = %s" cursor.execute(query, (user_input,))
Example: fix guidance for a Cross-Site Scripting weakness (CWE-79)
Apply output encoding to all user-controlled data rendered in HTML context.
Before (vulnerable):
document.getElementById("output").innerHTML = userInput;
After (secure):
document.getElementById("output").textContent = userInput;
Example: fix guidance for a Path Traversal weakness (CWE-22)
Validate and sanitize file path inputs to prevent directory traversal.
Before (vulnerable):
String filePath = request.getParameter("file");
File file = new File("/uploads/" + filePath);
After (secure):
String filePath = request.getParameter("file");
Path resolvedPath = Paths.get("/uploads").resolve(filePath).normalize();
if (!resolvedPath.startsWith("/uploads")) {
throw new SecurityException("Path traversal attempt detected");
}
File file = resolvedPath.toFile();