Investigate and remediate CVE vulnerability issues - Administrator Guide - Cortex Cloud Posture Management - Cortex CLOUD

Cortex Cloud Posture Management Documentation

Product
Cortex Cloud Application Security > Cortex CLOUD
License
Cloud Posture Management
Creation date
2025-01-22
Last date published
2026-06-04
Category
Administrator Guide

Select any row in the Vulnerabilities table to open the issue side panel. The side panel provides detailed context for investigation, prioritization, and remediation.

Details

Issues include general, Urgency, code evidence, and code to cloud details.

General details

The top section of the side panel displays the following fields:

Field

Description

Severity

The severity level of the CVE vulnerability

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, Backlog)

Urgency details

The Urgency details section provides the contextual risk signals that determine the urgency classification of the CVE vulnerability issue. Urgency extends beyond static severity by incorporating runtime, business context, and SCA-specific signals such as exploit intelligence and reachability analysis.

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

EPSS Score

The Exploit Prediction Scoring System probability indicating the likelihood of exploitation in the wild within the next 30 days. A higher EPSS score increases the urgency classification

KEV Status

Indicates whether the CVE is listed in the CISA Known Exploited Vulnerabilities catalog. CVEs listed in the KEV catalog are confirmed to be actively exploited and receive elevated urgency

Reachability

Indicates whether the vulnerable function in the package is reachable from the application code. A reachable vulnerability represents a confirmed exploitable path, increasing urgency. A non-reachable vulnerability indicates the vulnerable code path is not invoked

Has Fix

Indicates whether a fixed version of the vulnerable package is available. Vulnerabilities with available fixes are prioritized for remediation

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 vulnerability has access to sensitive data

Leverage Privileged Capabilities

Indicates whether at least one deployed asset affected by the vulnerability has the ability to leverage privileged capabilities

Affected Assets

The number of deployed cloud assets affected by the vulnerability

Is Deployed

Indicates whether the vulnerability affects any deployed assets. A deployed vulnerability represents a higher risk than a vulnerability 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 related to deployment context are populated only when the SCA asset is traced to deployed cloud resources through the Code-to-Cloud mapping. If no Code-to-Cloud trace exists, deployment-related urgency signals display as Not Applicable. SCA-specific signals (EPSS Score, KEV Status, Reachability, Has Fix) are always available regardless of Code-to-Cloud traceability.

CVE details

The CVE details section provides vulnerability intelligence for the detected CVE:

  • CVE ID: The Common Vulnerabilities and Exposures identifier with a link to the NVD entry.

  • CVSS Score: The CVSS v3.1 base score and severity rating.

  • EPSS Score: The Exploit Prediction Scoring System probability with percentile ranking.

  • KEV Status: Whether the CVE is listed in the CISA Known Exploited Vulnerabilities catalog.

  • Attack Vector: The attack vector classification (Network, Adjacent, Local, Physical).

  • Attack Complexity: The complexity required to exploit the vulnerability (Low, High).

  • Published Date: The date the CVE was published in the NVD.

  • Description: The full CVE description from the NVD advisory.

Package details

The Package details section provides dependency context for the vulnerable package:

  • Package Name: The name of the vulnerable open-source package.

  • Installed Version: The version of the package currently declared in the dependency manifest.

  • Fix Version: The minimum package version that resolves the vulnerability.

  • Root Package: The top-level dependency that transitively introduces the vulnerable package (for transitive dependencies).

  • Dependency Path: The full dependency chain from the root package to the vulnerable package.

  • Package Manager: The package manager ecosystem (npm, Maven, PyPI, Go Modules, NuGet, RubyGems).

  • License: The open-source license of the vulnerable package.

Code evidence

The Code evidence section displays the source code context of the vulnerable dependency:

  • Repository Name: The name of the repository containing the vulnerable dependency.

  • File Path: The full path to the dependency manifest file with a link to the VCS provider.

  • Code Block: The dependency manifest snippet with highlighted lines indicating the specific vulnerable package declaration.

  • Commit Details: The Git author, commit hash, and commit timestamp of the commit that introduced the vulnerable dependency.

Code to cloud graph

The Code to cloud graph visualizes the traceability path from the dependency manifest in the repository to the deployed cloud resource. The Code to Cloud graph enables you to understand the blast radius of the vulnerability by identifying which production assets inherit the vulnerable package.

Prioritize CVE vulnerability issues

Effective prioritization of CVE vulnerability issues requires evaluating multiple contextual signals beyond static severity. Application Security provides two complementary prioritization mechanisms: Urgency-based prioritization and Severity-based prioritization.

Urgency-based prioritization

Urgency incorporates runtime, business context, and SCA-specific signals to surface the CVE vulnerabilities that pose the greatest operational risk. Prioritize CVE vulnerability issues using the following urgency hierarchy:

Urgency Level

Criteria

Recommended Action

Top Urgent

The vulnerability has a high EPSS score, is listed in the KEV catalog, the vulnerable function is reachable, and the vulnerability affects a deployed, internet-exposed asset in a production environment with critical application criticality

Upgrade the package immediately. Escalate to a Case. Apply compensating controls if no fix version is available

Urgent

The vulnerability has a high CVSS score, a fix version is available, and the vulnerability affects a deployed asset in a staging or production environment, or the affected asset accesses sensitive data

Upgrade the package within the current SLA window

Not Urgent

The vulnerability has a low EPSS score, the vulnerable function is not reachable, 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 and no SCA-specific signals (EPSS, KEV, Reachability) are available. 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 CVE vulnerability based on the CVSS score. Use severity as the baseline filter:

Severity

Remediation Priority

Critical

Immediate remediation required. The vulnerability enables remote code execution, privilege escalation, or data exfiltration with low attack complexity

High

Remediate within the current sprint. The vulnerability exposes a significant attack vector

Medium

Schedule for remediation. The vulnerability requires specific conditions to exploit

Low

Address during routine maintenance. The vulnerability has minimal security impact

Informational

No action required. The finding is advisory

Take action on CVE vulnerability issues

The Vulnerabilities page supports the following actions for individual issues and bulk selections: change resolution status, assign an issue, open fix PR and apply upgrade guidance.

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 vulnerable package has been upgraded and verified.

Assign an issue

Assign a CVE vulnerability 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]

Open a fix pull request

For CVE vulnerability issues where an automated fix is available, Cortex Cloud can generate a pull request that upgrades the vulnerable package to the fixed version directly in the source repository. The fix pull request action 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. Select Open Fix PR.

  4. Select a naming method: automated (default) or custom PR title and branch name.

  5. Select Create Fix PR.

Cortex Cloud generates a pull request in the source repository with the package version updated to the fix version in the affected dependency manifest file.

Note

The Open Fix PR action is available only for CVE vulnerability issues detected through periodic scans where an automated fix exists. The action is not available for issues detected through PR scans. Verify that the Is Fixable indicator is True before attempting to open a fix pull request.

Apply upgrade guidance

For CVE vulnerability issues, the side panel provides package upgrade guidance specific to the vulnerability and package ecosystem. Upgrade guidance is accessed from the Actions tab in the issue side card.

  1. Select an issue in the table to open the side panel.

  2. Select the Actions tab in the side card.

  3. Review the Fix Version field in the Actions tab.

  4. The upgrade guidance includes:

    • The minimum package version that resolves the CVE

    • The dependency path from the root package to the vulnerable package (for transitive dependencies, upgrade the root package)

    • The package manager command to perform the upgrade

Example: upgrade guidance for a vulnerable npm package

  1. Identify the vulnerable package and the fix version in the issue details (such as lodash 4.17.20 → 4.17.21).

  2. Update the package version in the dependency manifest (package.json).

  3. Run npm install or npm update lodash to apply the upgrade.

  4. Verify the upgrade resolves the vulnerability by running a local scan using the Cortex CLI.

Example: upgrade guidance for a transitive Maven dependency

  1. Identify the root package that introduces the vulnerable transitive dependency using the Dependency Path field.

  2. Upgrade the root package to a version that resolves the transitive vulnerability.

  3. If the root package does not have a fixed version, add a direct dependency override in the pom.xml to force the fixed version of the vulnerable package.

  4. Run mvn dependency:tree to verify the vulnerable version is no longer present in the dependency tree.

Understand SLA compliance

Each CVE vulnerability 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. 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.

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