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