The Package Operational Risk table provides a consolidated view of all operational risk issues. Each row represents an issue created when a scanner finding matches a unified policy, linking the operational risk assessment to a specific package, dependency manifest file, repository, and the policy that triggered the issue.
Visible columns (default)
This table describes the visible table attributes. Select Menu settings to access additional attributes.
Column | Description |
|---|---|
Severity | The severity level assigned to the operational risk issue: Critical, High, Medium, Low, Informational, or Unknown. Severity is determined by the composite operational risk score based on maintenance, popularity, and deprecation factors, and may be overridden by a matched unified policy |
Name | The descriptive name of the operational risk issue (such as: High operational risk in lodash version 3.10.1). The Name column serves as the primary identifier for the issue |
Asset Name | The software package asset identifier, linking the operational risk issue to the corresponding software package asset in the Cortex Cloud asset inventory |
Package Manager | The package ecosystem where the dependency was detected (NPM, Maven, Go Modules, NuGet, RubyGems, Composer, Gradle, Yarn, Pip, Pipenv, Bower, Paket) |
Dependency Type | Whether the package is a Direct dependency or a Transitive dependency |
Repository | The repository containing the package with the operational risk issue |
Branch | The repository branch where the operational risk issue was detected (such as |
AppSec Policy | The Application Security policy that generated the package operational issue |
SLA | The Service Level Agreement (SLA) compliance status for the issue. The status is calculated based on the issue's creation timestamp and the configured target resolution window for its specific severity level. Values: On Track, Approaching, Overdue |
Data Source | The VCS provider where the repository is hosted (GitHub, GitLab, GitLab Self Managed, Bitbucket, Bitbucket DataCenter, Bitbucket Server, Azure DevOps) |
File Path | The path to the dependency manifest file containing the operationally risky package, including the affected line |
Status | The current resolution state: New, In Progress, or Resolved |
Created | The timestamp when the issue was first detected |
Assignee | The user assigned to the issue |
Backlog Status | Indicates the backlog classification of the issue. Status values: New, Backlog |
Business Application Names | Business applications in which the package operational risk is present |
Filter and sort the table
Use the filter bar at the top of the Package Operational Risk table to narrow results by any filterable column. Common filtering strategies include:
By Severity: Filter to High and Critical severity to focus on packages with the most significant operational risk factors
By Package Manager: Filter to a specific package ecosystem such as NPM, Maven) to scope review by technology stack
By Dependency Type: Filter to Direct to focus on dependencies explicitly declared in the project, or to Transitive to identify operationally risky packages inherited through the dependency chain
By Repository / Branch: Filter to a specific repository to scope review to a single codebase, or to the main/production branch to focus on operational risk issues that affect production-bound code
By Resolution Status: Filter to New to identify untriaged operational risk issues, or to In Progress to monitor active remediation