Select any row in the Package Operational Risk table to open the issue side panel. The side panel provides detailed context for investigation and remediation.
Overview tab
The Overview tab provides a comprehensive summary of the package operational risk issue, consolidating lifecycle details, precise source code context, risk analysis, and actionable remediation guidance to streamline your investigation.
Timestamp: When the issue was created and last updated
Status: The issue status. Values: New, In Progress, Resolved. You can set the status as required
Assignee: The entity assigned to mitigate the issue. You can assign the issue
Description: Provides details about the package integrity issue, including the location where the package was detected (such as specific repository, file path, and line number) and the operational risks identified
Impact: The impact that the issue could potentially have on your SDLC
Asset details: Includes Asset (The impacted asset. Clicking on the asset opens the asset side card without needing to navigate away to the asset section) and Asset Type (The specific asset type in which the IaC resource was identified)
Evidence: Provides evidence and contextual details within your SDLC containing the package operational risk:
Issue source
Data Source: The system or integration from which the issue data was originally pulled (such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to the data source itself
Category: Package Operational Risk is the immutable value
AppSec Policy: The violated security standard that led to the creation of the issue. Includes a link to the policy
Scanning context
Scanner Type: Code. The value is immutable
Scanner Source: Cortex AppSec. The value is immutable
Package Manager: The package manager (such as PIP, npm, Maven) in which the vulnerability was detected
Package Registry URL: The URL of the package registry (e.g., npm, PyPI, Maven Central) from which the vulnerable package was obtained
Code location
Repository Name: The name of the version control repository where the issue was located
Branch: The specific branch within the repository containing the issue
File Path: The exact location of the issue within the repository file structure
Commit Hash: The commit hash of the most recent commit that modified the code where the issue was detected
Commit Time: The timestamp of the most recent commit that modified the code where the issue was detected
Risk analysis
Risk Factors: Specific attributes or conditions that contribute to an issue's likelihood or the severity of its impact
Remediation: Suggested mitigation for the package operational risk.
Important
Package operational risk issues do not have urgency signals based on exploit intelligence. Unlike CVE vulnerability issues, operational risk issues assess the health and sustainability of a package, not active security vulnerabilities. Urgency signals such as EPSS score, KEV status, and reachability analysis do not apply to operational risk evaluation. However, the package operational risk level (High, Medium, Low) is used as a contextual signal in the urgency calculation of CVE vulnerability issues detected in the same package.
War Room tab
The War Room tab displays the issue details in markdown format, including:
Package name and version.
Operational risk severity and contributing factors.
Detection rule identifier.
Repository and file path context.
Actions tab
The Actions tab provides remediation guidance for the operational risk issue.
Remediation guidance: Operational risk issues display the guidance: "Consider migrating to a more popular and well-maintained package.".
No automated fix PR: Unlike CVE vulnerability issues, operational risk issues do not support automated fix pull requests. Remediation requires evaluating alternative packages, assessing compatibility, and performing a manual migration to a healthier dependency.
Prioritize package operational risk issues
Effective prioritization of package operational risk issues requires evaluating the operational risk severity, deprecation status, and dependency type. Operational risk issues are supply chain health risks; prioritize based on the maintenance and popularity indicators of the detected package.
Critical Severity: The package is deprecated and has a high operational risk score. The package is no longer maintained, receives no security patches, and poses immediate supply chain risk. Immediate migration required. Identify and migrate to an actively maintained alternative package.
High Severity: The package has a high operational risk score due to low maintenance activity, limited community engagement, or outdated support. The package may not receive timely security patches or bug fixes. Schedule migration within the current sprint. Evaluate alternative packages with better maintenance and popularity indicators
Medium Severity: The package has a moderate operational risk score. Some maintenance or popularity indicators are below healthy thresholds, but the package is not abandoned. Monitor the package health. Schedule evaluation during the next maintenance cycle
Low Severity: The package has a low operational risk score. Maintenance and popularity indicators are within acceptable thresholds. No immediate action required. Continue monitoring through periodic scans
Deprecated Status: The package is deprecated and no longer maintained. The package will not receive security patches, bug fixes, or compatibility updates. Continued use introduces unpatched vulnerability exposure and compatibility degradation. Immediate migration. Replace the deprecated package with the recommended successor or an actively maintained alternative
Not Deprecated Status: The package is not deprecated. Evaluate the operational risk severity for maintenance and popularity health indicators. Prioritize based on the operational risk severity (High, Medium, Low)
Direct Dependency: The operationally risky package is explicitly declared in the project dependency manifest. Direct dependencies are under the direct control of the development team. Migrate the direct dependency to a healthier alternative. Update the dependency manifest file directly
Transitive Dependency: The operationally risky package is inherited through the dependency chain. Transitive dependencies are introduced by direct dependencies and are not directly controlled by the development team. Identify the root direct dependency that introduces the transitive package. Evaluate whether upgrading the root dependency resolves the transitive operational risk
Take action on package operational risk issues
The Package Operational Risk page supports the following actions for individual issues and bulk selections.
Note
Automated fix pull requests are not available for package operational risk issues. Remediation requires human judgment to evaluate alternative packages, assess API compatibility, and perform the migration.
Change resolution status: Update the resolution status to track remediation progress.
Select an issue in the Package Operational Risk table.
Right-click to open the context menu.
Select the target resolution status:
New — The issue has not been triaged.
In Progress — Package evaluation or migration is underway.
Resolved — The operationally risky package has been replaced with a healthier alternative, or the risk has been accepted with documented justification.
Enter a Resolution Comment (optional) to document the action taken.
Assign an issue: Assign a package operational risk issue to a specific user for triage and remediation.
Select the issue row in the Package Operational Risk table.
Open the issue side panel.
Select the Assignee field.
Search for and select the target user.
Escalate to a Case: For package operational risk issues that require cross-team coordination or extended remediation timelines, escalate the issue to a Case.
Select the issue row in the Package Operational Risk table.
Right-click to open the context menu.
Select the option to create or link to a Case.
The Case captures the issue context, assigned owner, and SLA tracking in the centralized Cases workflow.