> 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/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/references/reference-a-pull-request-scan-concepts.md). # 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](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/references/reference-d-pr-status-values.md). For every scan health value, see [Reference C: Scan health values](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/references/reference-c-scan-health-values.md). ## 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. --- # 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/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/references/reference-a-pull-request-scan-concepts.md?ask=&goal= ``` `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.