> 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.md). # Pull Request scans Pull request scans are the enforcement point that decides whether risk enters a protected branch at all. A pull request scan runs automatically when a pull request opens or receives a new commit, evaluates the proposed change with every enabled Cortex Cloud Application Security scanner, returns a status check to the version control system, and blocks the merge when a finding matches a policy carrying the Block PR action. Use pull request scans to answer one question with evidence: is the organization actually preventing risk at merge time, or only recording risk after the merge. Pull request scans gate (act as an automated checkpoint for) a proposed code change and produce both a scan status and scan health. The Pull Request Scans inventory presents scan results; the inventory does not resolve issues and offers no rescan action. Issue resolution occurs in the dedicated issue inventory for each issue type. ## Prerequisites | Prerequisite | Requirement | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Application Security module** | The Cortex Cloud Application Security module is active for the tenant | | **VCS integration** | At least one Version Control System integration (GitHub, GitLab, Bitbucket, Azure Repos) is connected, and the integration instance status is **Connected** | | **Webhook subscription** | The webhook subscription for the integration instance is healthy Pull request scans are event-triggered — a failed webhook subscription stops pull request scanning entirely while periodic scanning continues on its schedule | | **Repository onboarding** | The repository is onboarded through the VCS integration | | **Pull request scanning enabled** | **Scan PR** is enabled in the repository scan configuration | | **Scanner enablement** | At least one scanner (IaC, SCA, Secrets) is enabled in the repository scan configuration A repository with every scanner disabled produces no findings and never blocks a merge | | **Blocking policy** | To block a merge, an enabled Unified Application Security Policy carries the **Block PR** action for the **PR Scan** trigger Without such a policy, pull request scans report findings and never block | | **`app_sec_scans_pr_view` permission** | Required to view pull request scan results | | **Data Sources (View/Edit) permission** | Required to open and save the repository **Scan Configuration**, where pull request scanning is enabled Built-in roles carrying the permission are listed in Onboarding data sources A user holding only `app_sec_scans_pr_view` can read scan results and cannot enable the gate | ## Core achievements * **Preventing risk at zero blast radius:** Blocking a finding before the merge denies the finding any deployed attack surface, which no later enforcement point can do * **Returning findings to the author, not to a queue:** Delivering scanner results as a pull request comment at the moment of introduction, where the developer holds the context to fix the finding * **Making the gate auditable:** Recording which policy blocked which pull request, so a governance claim of prevention rests on evidence rather than on configuration * **Detecting a silent gate:** Distinguishing a repository where no pull request was blocked because no risk was introduced from a repository where nothing was blocked because no scan ever ran **Shift-left position:** Pull request scans are the primary enforcement point in the shift-left lifecycle (IDE → **PR** → CI → Periodic → Runtime). A finding blocked at the pull request stage never reaches CI, never reaches the periodic baseline, and never reaches runtime. A finding that passes the pull request gate becomes committed risk that the periodic baseline then reports. Treat a growing periodic baseline as evidence that the pull request gate is too permissive. ## Core concepts Pull request scans use these concepts to evaluate merge-time risk accurately * **Scan status and health:** Status determines the merge outcome. Health reports scan execution * **Change scope:** The scan evaluates the pull request diff, not repository posture * **Scan coverage:** Disabled scanning, forked pull requests, and failed webhooks prevent scans * **Urgency:** Pull request scan issues have **Not Applicable** Urgency until code is deployed Refer to [Reference A: Pull request scan concepts](/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) for more information. ## How to access Pull Request scans Under **Modules** select **Application Security** → **Pull Request Scans** (under Scans). ## Workflow Follow the workflow to configure the gate, validate enforcement, and investigate blocked pull requests. [Open the Pull request scan workflow](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/pull-request-scan-workflow.md). ## References Use [References](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/references.md) for detailed scan information. ## Next step [Pull request scan workflow](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/pull-request-scans/pull-request-scan-workflow.md). --- # 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.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.