Reference B: Inventory columns

The Pull Request Scans inventory displays the following columns by default. Filterable columns support text-based and enum-based filtering according to the data type.

PR inventory table

Column	Field	Description
Repository	repo_name	The name of the scanned repository, displayed with the VCS provider icon
Organization	organization_id	The VCS organization or group that owns the repository
Pull Request ID	pull_request_id	The identifier of the pull request. Select the value to open the pull request in the VCS provider
Commit	commit_id	The commit that triggered the scan
Git User	user_email	The email address of the user who opened or updated the pull request
Scanned Branch	branch_name	The source branch of the pull request
Scan Date	start_date	The timestamp when the scan started
Issues Found	issues_found	The severity breakdown of the issues found: Critical, High, Medium, Low
PR Status	status	The policy evaluation result that determined the merge outcome
Scan Health	scan_health	The execution health of the scan
Business Application Names	business_application_names	The business applications associated with the scanned repository. The column is filterable but not sortable, because a repository can belong to several applications. The column reports application names and does not report application criticality

The following columns are hidden by default. Enable additional columns from the column settings icon in the inventory toolbar.

Column	Field	Description
Blocking Policy	blocking_policy_name	The policy that blocked the pull request. Select the value to open the policy in Policy Management
Pull Request Title	pull_request_title	The title of the pull request, which is also the title of the scan side panel
Provider	vcs_source	The VCS provider: GitHub, GitLab, Bitbucket
Scan ID	scan_id	The unique identifier of the scan
Findings Types Breakdown	findings_types_breakdown	The breakdown of findings by scanner type
Findings Severity Breakdown	findings_severity_breakdown	The severity breakdown of the findings by severity
Issues Types Breakdown	issues_types_breakdown	The breakdown of issues by scanner type

Scan Date filter

Scan Date (start_date) records when the scan started. Where the filter is available, it restricts the inventory to scan results that started within the selected range.

Apply the filter when an assessment covers a defined period. Without a range, the inventory returns every retained scan result.

The filter reports scan results, not repositories. It cannot establish the gated repository population.

PR scan side panel

Select a scan row to open the side panel. The panel title displays the pull request title (for example, Create yarn.lock).

Overview tab properties:

• Organization — The VCS organization or group.
• Repository — The scanned repository name.
• Scanned Branch — The source branch of the pull request.
• Scan Health — The scan health status with a status icon.
• PR Status — The PR scan result status with a status icon.
• Commit ID — The commit SHA that triggered the PR scan.
• Issues By Type — Breakdown of issues by scanner category.
• Findings By Type — Breakdown of findings by scanner category.
• Scan Date — The timestamp when the scan started.
• Issues — Severity breakdown (Critical, High, Medium, Low) with total count.
• Findings — Severity breakdown (Critical, High, Medium, Low) with total count.

Issue category tabs:

• Vulnerabilities — CVE vulnerability issues for the selected scan.
• Configurations — IaC misconfiguration issues for the selected scan.
• Secrets — Secrets issues for the selected scan.
• Package Integrity — Presents two tables: Licenses and Package Operational Risk.
• Malicious Packages — Malicious package issues for the selected scan.

Each tab presents an Issues view and a Findings view, selected from the control in the upper right of the tab.

PR scan actions

No management actions (such as rescan) are available for PR scans. PR scans are triggered by pull request events in the VCS provider and cannot be retriggered from the scan management console. Re-evaluation occurs when a new commit is pushed to the pull request.

For the complete pull request scan workflow — enabling pull request scanning per repository, verifying that the gate fires across the portfolio, investigating a blocked pull request and its blocking policy, and diagnosing a gate that stopped firing — see Pull request scans.