Understand package operational risk findings

A package operational risk finding is the raw output of the Cortex Cloud operational risk scanner: one record stating that one open-source package, reached through one root package, carries a maintenance problem. Findings exist before policy evaluation, which makes the Findings tab of the Package Operational Risk page the only surface that answers three questions the issues table cannot — whether the operational risk scanner is running everywhere it should, which detections no policy converted into work, and why the finding count exceeds the issue count.

Navigate to Application Security > Issues > Package Operational Risk, then switch to the Findings tab using the segmented control at the top of the page.

What a finding is, and why the count differs from the issue count

A finding is a detection. An issue is a decision. The operational risk scanner emits a finding for every package that crosses the risk threshold or carries a registry deprecation flag, with no reference to policy. Cortex Cloud then evaluates each finding against the active Unified Application Security Policies, and only findings that match a policy carrying a Create Issue action become issues.

Three consequences follow, and each explains why the Findings tab is not a duplicate of the Issues tab.

A finding count higher than the issue count is normal. Findings that match no policy remain on the Findings tab permanently and never appear on the Issues tab.

One package can produce several findings. The scanner fans out along two independent dimensions, so the finding count is not a package count:

Fan-out dimension	Behavior	Source
Detection type	A package that is both above the risk threshold and flagged deprecated produces one risk finding and one deprecation finding	operationalRiskService.ts:31
Root package	A transitive package reached through several root packages produces one finding per root package	operationalRiskReportGenerator.ts:38

Low-risk packages never become findings at all. The scanner filters packages rated Low before generating any finding, per operationalRiskService.ts:10. The Findings tab therefore reports the population above that threshold rather than every package carrying maintenance risk.

Caution. The Low filter applies to the deprecation detection as well as to the risk detection. A package that the registry marks deprecated but that scores Low on the composite risk signals produces no finding, because the Low filter is applied before both detections run. A deprecated package absent from the Findings tab is therefore possible, and the absence is not evidence that the package is undeprecated.

---

The two detection types

The operational risk scanner produces two distinct finding types under one issue type. The Finding Name column identifies which detection produced a given row, and the distinction determines how much confidence the finding carries.

Finding name pattern	Finding type ID	What the finding states	Confidence
Deprecated package: <name> version <version>	30020001	The package registry carries a deprecation flag set by the maintainer	A declaration. The maintainer has stated the package is finished
<Severity> operational risk in <name> version <version>	30020000	The package scored above the risk threshold on composite maintenance signals	An inference. Derived from behavior rather than from a statement

Finding names are composed at operationalRiskReportGenerator.ts:173 and operationalRiskReportGenerator.ts:185. Type IDs are defined at operationalRiskReportGenerator.ts:28.

Treat the two types differently during audit. A deprecation finding is authoritative and needs no corroboration — the maintainer published the flag. A risk finding is probabilistic and warrants a second signal before capacity is committed, because a narrowly scoped library that solves a fixed problem can score poorly on maintenance signals while remaining complete and safe.

Note. Both detection types carry the identical remediation string, Consider migrating to a more popular and well-maintained package., set as a constant at operationalRiskReportGenerator.ts:91. The remediation field carries no per-package guidance and does not name a successor package. Successor identification is an investigation step, not a field on the finding.

Every finding carries the detection method CAS_OPERATIONAL_RISK_SCANNER, and the rule identifier is composed as APPSEC_OPRISK_ followed by the severity, per operationalRiskReportGenerator.ts:108.

---

Audit scanner coverage and policy gaps

Use the Findings tab when the question concerns the scanner or the policy set rather than an individual dependency. Four audit workflows justify opening the Findings tab instead of the Issues tab.

Verify operational risk scanner coverage. A repository with SCA scanning enabled and zero operational risk findings is a coverage signal worth confirming, not a clean result. Filter findings by Repository and confirm that each repository containing a supported dependency manifest returns findings. Repositories covered only by an ingested third-party SCA scanner produce CVE findings but never operational risk findings, because operational risk analysis is exclusive to the native Cortex Cloud SCA scanner.

Identify policy gaps. Compare the finding population against the issue population. A large detection population producing few issues indicates that no active policy covers the Operational Risk finding type, or that the policy conditions exclude the severities being detected. Resolve a policy gap by extending a Unified Application Security Policy, not by ignoring the findings. For policy configuration, refer to Unified Application Security Policies.

Separate declarations from inferences across the estate. Filter the Finding Name column for the deprecation pattern to isolate the population that carries maintainer-declared abandonment. That subset needs no investigation to confirm the maintenance status and can be scheduled directly, which makes it the highest-confidence modernization queue available.

Establish transitive concentration before planning work. Filter Dependency Type to Transitive and review the finding population. Transitive findings cannot be resolved by the consuming team directly, so a backlog dominated by transitive findings indicates that the modernization work belongs to a root package upgrade cadence rather than to per-package replacement.

Caution. Do not treat the Findings tab as a work queue. A finding is not assignable, carries no SLA, and has no resolution status. Perform remediation on the Issues tab, where the policy-evaluated work items live.

Important. Inline suppression does not apply to package operational risk findings. The inline checkov:skip mechanism supports CVE findings and license findings only, and neither operational risk report generator reads a suppression input or writes a suppression field. Suppress operational risk detections through policy conditions rather than through manifest comments.