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.