Reference A: Pull request scan concepts

Scan status gates the merge; scan health reports execution

Pull request scans carry two independent signals, and reading one for the other produces incorrect conclusions about enforcement.

Scan status — displayed as PR Status — reports the policy evaluation result: whether the scan passed, failed, or detected issues that no policy blocked. Scan status determines the merge outcome and is written back to the version control system as a status check.

Scan health reports the execution health of the scan: whether every scanner completed, some scanners failed, or the scan is still executing.

The two signals are independent, and the dangerous combination is a passing status on degraded health. A pull request that reports Passed while scan health reports Partially was gated on incomplete evidence — a scanner that never executed cannot block anything. Confirm both signals before treating a merge as governed.

Note: For every PR status value and its merge consequence, see Reference D: PR status values. For every scan health value, see Reference C: Scan health values.

A pull request scan evaluates the change, not the repository

A pull request scan analyzes the files in the pull request diff against the target branch. A vulnerability that already exists elsewhere in the repository and is untouched by the pull request does not appear in the pull request scan result.

This scoping is what makes the pull request gate enforceable: a developer is accountable for the change under review, not for the accumulated backlog. The consequence is that a pull request scan result is never a statement about repository posture. Read repository posture from Branch periodic scans.

The inventory lists scan results, one per commit

The Pull Request Scans inventory displays one row per scan result. Every commit is a new scan and appends a new row; a new commit on an open pull request does not replace the row produced by the preceding commit.

The inventory therefore does not display one row per pull request. A row count is a count of commit scans, and the count diverges from the pull request count in exactly the repositories where enforcement is most active — the repositories where a blocked author pushes a corrected commit.

Important: A count of Blocked rows counts blocked commit scans. A pull request that received five commits and was blocked on three of them contributes three Blocked rows, so the row count overstates the number of blocked pull requests wherever a pull request was blocked on more than one commit. To count pull requests, count distinct Pull Request ID values rather than rows. Apply this correction to every prevention measurement taken from this inventory, including the assessment in Verify that the gate is firing across the portfolio.

Not every pull request produces a scan

The absence of a scan row is not evidence that a pull request was clean. Cortex Cloud does not scan a pull request in any of the following cases, and none of them produces a row, a status check, or a warning in the inventory:

• Pull request scanning is disabled for the repository in the scan configuration.
• The pull request originates from a forked repository. Pull requests opened from a fork are ignored.
• The pull request was opened by Cortex Cloud — an automatic fix pull request or a tagging bot branch. Cortex Cloud does not scan the pull requests Cortex Cloud creates.
• The webhook did not arrive, because the webhook subscription for the integration instance is failing.

Important: Counting the pull request scans that reported does not measure the pull requests that were gated. Because an unscanned pull request is indistinguishable from an absent pull request in this inventory, verify enforcement from the repository configuration and the version control system rather than from row counts alone. Forked-repository contributions in particular pass through ungated no matter how the policy set is configured — govern that path with branch protection rules in the version control system.

Issues from pull request scans carry no Urgency

Urgency combines exploit intelligence with Code-to-Cloud deployment context. Unmerged code is not deployed, so the deployment-dependent signals cannot be computed and the Urgency engine returns Not Applicable for pull request scan issues by design.

Prioritize pull request scan issues by severity, by the business criticality of the affected repository, and — for secrets — by validation status. Do not read Not Applicable as low risk. For the Urgency model, see Urgency.