> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/application-security-posture-management-aspm/manage-code-weakness-issues/investigate-and-remediate-code-weakness-issues.md). # Investigate and remediate code weakness issues {% tabs %} {% tab title="" %} 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 | {% hint style="info" %} ### 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 {% endhint %} **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): ```programlisting query = "SELECT * FROM users WHERE username = '" + user_input + "'" cursor.execute(query) ``` After (secure): ```programlisting 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): ```programlisting document.getElementById("output").innerHTML = userInput; ``` After (secure): ```programlisting 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): ```programlisting String filePath = request.getParameter("file"); File file = new File("/uploads/" + filePath); ``` After (secure): ```programlisting 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(); ``` {% endtab %} {% endtabs %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/application-security/application-security-posture-management-aspm/manage-code-weakness-issues/investigate-and-remediate-code-weakness-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.