> 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/package-operational-risks-findings-reference/reference-c-operational-risk-finding-field-model.md).

# Reference C: Operational risk finding field model

Each finding carries the following fields, read from `operationalRiskReportGenerator.ts:70`. Fields are grouped by the section of the finding record that carries them.

**Normalized fields — the package and the manifest**

| Field                                  | Description                                       |
| -------------------------------------- | ------------------------------------------------- |
| `xdm.detection.method`                 | Always the operational risk detection method      |
| `xdm.file.path`                        | The dependency manifest that declares the package |
| `xdm.file.position.start.line`         | The first line of the package declaration         |
| `xdm.file.position.end.line`           | The last line of the package declaration          |
| `xdm.software_package.package_manager` | The ecosystem that declared the package           |
| `xdm.software_package.dependency_type` | Direct or Transitive                              |
| `xdm.software_package.is_deprecated`   | Whether the registry marks the package deprecated |
| `xdm.software_package.registry_url`    | The package registry entry                        |
| `xdm.software_package.repository_url`  | The source repository of the package              |

**Extended fields — the maintenance signals**

| Field                      | Description                                                |
| -------------------------- | ---------------------------------------------------------- |
| `package_maintenance`      | The maintenance rating collected from the registry         |
| `package_popularity`       | The adoption rating collected from the registry            |
| `is_ai_ml`                 | Whether the package is classified as an AI or ML component |
| `software_package_name`    | The package carrying the risk                              |
| `software_package_version` | The package version                                        |

**Extended fields — dependency lineage**

| Field                     | Description                                                       |
| ------------------------- | ----------------------------------------------------------------- |
| `root_package_name`       | The direct dependency through which the package entered the build |
| `root_package_version`    | The root package version                                          |
| `root_package_start_line` | The first line of the root package declaration                    |
| `root_package_end_line`   | The last line of the root package declaration                     |
| `main_manifest_file_path` | The primary manifest for the ecosystem                            |

**Extended fields — detection provenance**

| Field              | Description                                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------------- |
| `check_id`         | Composed as `APPSEC_OPRISK_` followed by the severity                                             |
| `rule_description` | The generated sentence naming the dependency type, package, version, manifest, line, and severity |
| `manual_fix`       | The constant migration suggestion                                                                 |
| `rule_category`    | Always `Code`                                                                                     |

**Important.** `xdm.detection.rule_id` is written as an empty string on every operational risk finding, per `operationalRiskReportGenerator.ts:81`. Unlike license findings, which carry a stable BC\_LIC rule identifier, operational risk findings identify the detection through `check_id` and the finding name instead. Do not build a filter or an integration on the rule ID field for this finding type.

**Important.** The field names above belong to the version 1 finding payload. A second generator, `operationalRiskReportGeneratorV2.ts`, emits equivalent information under a different structure, placing detection data under `rule.properties` and package data under `provenance.properties`, and reads the risk level from an `operational_risk` asset property rather than from a normalized field. The information content is equivalent; only the field paths differ.

**Note.** The maintenance and popularity signals also appear on license findings for the same package, because both scanners read the same package asset metadata. A package carrying both a license finding and an operational risk finding is a stronger replacement candidate than either finding indicates alone. For the license finding model, refer to Understand license miscompliance findings.


---

# 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/package-operational-risks-findings-reference/reference-c-operational-risk-finding-field-model.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.