> 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/code-security/code-security-scanners/software-composition-analysis-sca-scanners/package-operational-risk-scanner/understand-package-operational-risk-findings.md).

# 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.

```mermaid
flowchart LR
    A[Package assets from the SCA scan] --> B[Filter out packages rated Low]
    B --> C[Risk detection: score above threshold]
    B --> D[Deprecation detection: registry flag set]
    C --> E[Findings tab shows every finding]
    D --> E
    E --> F[Policy evaluation]
    F --> G[Issues tab shows only findings that matched a Create Issue policy]
```

***

## 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.


---

# 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/code-security/code-security-scanners/software-composition-analysis-sca-scanners/package-operational-risk-scanner/understand-package-operational-risk-findings.md?ask=<question>&goal=<endgoal>
```

`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.