Investigate and remediate code weakness issues

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 → Change Status → [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 → Change Assignee → [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 → Change Severity → [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.

1. Select the issue row to open the side panel.
2. Select the Actions tab in the side card.
3. Review the Manual Fix Suggestion field in the Actions tab.
4. 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();