PR Scanning

How It Works

ZeroPath PR scanning analyzes the code changes in your pull requests and merge requests, catching security issues before they’re merged. Scans run automatically when a PR is opened or updated, and results appear directly in your VCS.

Diff-Focused Analysis

Only changed files and surrounding context are analyzed — fast and targeted. Large diffs are handled gracefully: the AI agent can inspect specific file diffs through tools rather than requiring the entire diff inline, so even very large pull requests receive full agent-based analysis.

Differential Comparison

Scans both target and PR branches, surfacing only new findings in the PR.

Parallel Security Tools

SAST, SCA, Secrets, and IaC run simultaneously on changed code. If the AI analysis times out or encounters an error, findings from independently completed tools (such as secrets and SCA) are preserved.

AI Validation

Every finding is validated in the context of the diff to minimize false positives.

Supported Platforms

Platform	Trigger	Check Status	Inline Comments
GitHub (Cloud & Enterprise Server)	GitHub App webhook	GitHub Check Runs	Yes
GitLab (Cloud & Self-hosted)	Merge Request webhook / Pipeline webhook	Commit Statuses / Pipeline	Yes
Bitbucket (Cloud & Data Center)	Pull Request webhook	Build Statuses	Yes
Azure DevOps Services	Service hook	Build Statuses	Yes

All four platforms support the full PR scanning feature set: automatic triggering, status reporting, and inline code review comments.

Want to verify that your PR fixes a known vulnerability? See Fix Verification to learn how to reference issues in your PR description.

What Gets Analyzed

PR scanning is strictly diff-focused. It does not re-scan your entire codebase on every PR.

Fetch the Diff

Retrieves the unified diff from your VCS API (falls back to git diff if needed). When the PR branch shares no common ancestor with the target branch (for example, orphan branches or force-pushed histories), ZeroPath automatically falls back to a direct tree comparison so the scan can still proceed.

Identify Changed Files

Maps every changed hunk to its file and line numbers.

Run Security Tools in Parallel

On changed files only:

SAST — static analysis on both target and PR branches, surfacing only new findings. If your organization has configured custom natural-language SAST rules, those rules are also enforced on the changed code — the same rules that run during full scans are applied to the files touched by the PR, so violations are caught before merge.
SCA — dependency analysis when manifests/lockfiles changed (AI pre-screen skips if not relevant)
Secrets — scans the diff for hardcoded credentials
IaC — checks changed infrastructure files

Filter to Changed Regions

Only findings that directly overlap with actually changed lines in the diff are reported — there is no proximity buffer, so nearby-but-unrelated findings are excluded. New files are included entirely; deleted files are excluded.

Validate & Report

AI validation removes false positives. When a previously reported issue is re-evaluated and determined to be a false positive, it can be automatically resolved. Results are posted to your VCS as check statuses and inline comments.When a PR is updated after a previous scan was skipped (for example, because the earlier diff was not security-relevant), ZeroPath excludes the skipped scan from the refresh baseline. This ensures the incremental comparison covers the full set of PR changes rather than only the most recent update.Findings that you have confirmed as true positives through investigation are never auto-resolved by PR scans. If a confirmed finding is absent from a PR scan refresh, it is carried forward rather than marked as resolved, ensuring confirmed vulnerabilities stay visible until explicitly addressed.If a finding was previously marked as resolved but is detected again in a subsequent PR scan refresh, ZeroPath automatically re-opens it. Re-detection is treated as evidence that the vulnerability is still present, consistent with how re-detection is handled during full scans. Findings resolved because they were determined to pre-exist on the base branch are not re-opened by this logic.

Check Status & Feedback

Results are reported through multiple channels:

VCS Check Status
Inline Comments
PR Summary
Merge Notifications
Patch Status Tracking

A pass/fail check status is posted on your PR. This integrates with branch protection rules so you can require ZeroPath checks to pass before merging.

Status	Meaning
Success	No security-relevant issues found (or only below threshold)
Failure	Confirmed vulnerabilities found above configured threshold
Neutral	Scan timed out or merge queue entry (does not block merges by default). Timeout statuses are posted consistently across all supported VCS platforms, including for scans that time out while queued. If a transient network error occurs while posting the final check status, ZeroPath automatically retries so the check does not get stuck in a pending state. When a pull request enters a GitHub merge queue, ZeroPath posts a `neutral` check on the merge-group commit so the queue can proceed — the PR was already scanned when it was opened or updated, so a separate scan of the merge commit is not required.
Skipped	Infrastructure error (deliberately not a failure to avoid blocking merges). Error messages are specific to the failure type — for example, distinguishing repository access issues from transient service errors — for easier troubleshooting.

For organizations using credit-based billing, a PR scan may be skipped if the organization has insufficient credits. When this occurs, the check is marked as a failure with a message indicating the reason, and (if enabled) a comment is posted on the PR explaining why the scan was not run. Contact your organization administrator to add more credits.When you triage an issue (for example, marking it as false positive or resolved) on a PR that has been updated and rescanned, ZeroPath refreshes the check status on the PR’s current head commit rather than the scan where the issue was originally detected. This ensures that triage actions immediately reflect in the branch protection check your team sees, even after subsequent commits have been pushed to the PR.

Blocking Pull Requests

The default ZeroPath check name is ZeroPath Security Scan. If your organization uses a custom or white-labeled integration, require the exact check name that appears on a test PR.

GitHub

Use GitHub branch protection rules to require the ZeroPath check before merging.

Create a ZeroPath check run

Enable PR scanning and Check status posting in ZeroPath, then open or update a test pull request so GitHub has seen the ZeroPath Security Scan check at least once.

Open branch protection

In GitHub, go to your repository’s Settings > Branches, then add or edit the branch protection rule for the branch you want to protect, such as main.

Require the ZeroPath check

Select Require status checks to pass before merging, search for ZeroPath Security Scan, and select it. If GitHub asks for the expected source, choose the ZeroPath GitHub App rather than “any source”.

Save and test

Save the rule, push a commit to the test PR, and confirm GitHub blocks the merge until the ZeroPath check reports success.

GitHub branch protection docs

See GitHub’s official steps for requiring status checks in a branch protection rule.

GitLab

Use GitLab’s merge checks to require the pipeline that contains the ZeroPath status to succeed before merging.

Create a ZeroPath status

Enable PR scanning and Check status posting in ZeroPath, then open or update a test merge request so GitLab shows ZeroPath Security Scan in the merge request’s pipeline or status area.

Open merge request settings

In GitLab, go to the project and select Settings > Merge requests.

Require successful pipelines

In Merge checks, select Pipelines must succeed, then save your changes. GitLab will block the merge until the relevant pipeline, including the ZeroPath status, is successful.

Verify the gated pipeline

Push a commit to the test merge request and confirm the ZeroPath Security Scan status appears in the pipeline that GitLab evaluates for the merge request. If you run both branch and merge request pipelines, make sure the ZeroPath status is attached to the merge request pipeline GitLab uses for the merge gate.

GitLab successful pipeline docs

See GitLab’s official steps for requiring a successful pipeline before merge.

GitLab external commit status docs

See how GitLab represents statuses from external systems inside pipelines.

Bitbucket

Use Bitbucket merge checks to require successful build statuses before merging.

Create a ZeroPath build status

Enable PR scanning and Check status posting in ZeroPath, then open or update a test pull request so Bitbucket shows the ZeroPath Security Scan build status on the latest commit.

Open branch restrictions or merge checks

For Bitbucket Cloud, open the repository settings and go to Branch restrictions under Workflow. For Bitbucket Data Center, open Repository settings > Merge checks or Repository settings > Required builds.

Require successful builds

In Bitbucket Cloud, add a branch restriction for the protected branch and enable Minimum number of successful builds for the last commit with no failed builds. Set the minimum to at least 1.

Enforce the merge check on Bitbucket Cloud

On Bitbucket Cloud Premium, enable Prevent a merge with unresolved merge checks so the successful-build requirement blocks merging. Without that setting, Bitbucket warns users about unresolved merge checks but may still allow the merge.

Require the ZeroPath build on Data Center

In Bitbucket Data Center, enable Minimum successful builds or add a Required builds rule for the ZeroPath build key if your instance supports required builds.

Save and test

Push a commit to the test PR and confirm Bitbucket blocks the merge until the latest commit has a successful ZeroPath build status.

Bitbucket Cloud merge check docs

See Bitbucket Cloud’s official steps for requiring successful builds before merge.

Bitbucket Data Center merge check docs

See Bitbucket Data Center’s official merge check and required build documentation.

Azure DevOps Services

Use Azure Repos branch policies to require the ZeroPath status before completing a pull request.

Create a ZeroPath status

Enable PR scanning and Check status posting in ZeroPath, then open or update a test pull request so Azure DevOps Services receives the ZeroPath Security Scan status.

Open branch policies

In Azure DevOps Services, open the repository’s Repos > Branches page, select the target branch, and open Branch policies.

Require the ZeroPath status

Add a status policy for the ZeroPath status context used in your environment. Configure it as required if the branch should block merges until the scan passes.

Save and test

Push a commit to the test pull request and confirm Azure DevOps blocks completion until the ZeroPath status reports success.

Azure DevOps PR scans require an Azure DevOps Services connection in ZeroPath. See the Azure DevOps integration guide for OAuth and PAT setup.

ZeroPath posts inline comments directly on the affected diff lines showing:

The vulnerability type and severity
A description of the issue and its impact
If auto-patching is enabled, a fix suggestion that can be applied with one click

Inline comments are formatted to render correctly on all supported platforms, including Bitbucket and Azure DevOps, which do not support collapsible HTML sections. On these platforms, ZeroPath automatically converts comment markup into standard markdown so the content is always readable.When a previously reported finding is no longer detected in a subsequent scan of the same PR, ZeroPath automatically resolves the corresponding inline comment, keeping your review thread clean and up to date. The original comment text is struck through and replaced with a “Resolved” banner indicating the issue was not detected in the latest scan. On platforms that support it, the review thread is also collapsed or marked as resolved. Comment threads are also resolved automatically when you mark the underlying issue as false positive, resolved, or any other closed state from the ZeroPath dashboard, API, or via a bot command. This works across GitHub, GitHub Enterprise Server, GitLab, Bitbucket, and Azure DevOps Services, so your PR review stays in sync with your triage decisions.Each inline finding comment includes a quick-tips footer showing how to triage the finding directly from the comment thread — for example, replying with @ZeroPath false-positive because ... or @ZeroPath accepted-risk because .... The footer also links to the full Bot Commands reference. This footer appears on GitHub and GitLab only.Inline comments are enabled by default and can be disabled per repository.

Bot Commands

You can drive ZeroPath directly from your PR or merge request by mentioning the bot in a comment — triage findings, assign tickets, generate patches, rescan, bypass checks, or ask natural-language questions. The bot acknowledges immediately and updates the same comment in-place when the action completes. When the job finishes, ZeroPath also posts a follow-up reply in the same thread with a summary of the result (or an error message if the job failed), so the outcome is visible inline without navigating to the dashboard. A few common examples:

PR comment

@ZeroPath fp issue 2 because input is sanitized upstream
@ZeroPath assign issue 3 to alice@example.com
@ZeroPath generate patch issue 2
@ZeroPath rescan force
@ZeroPath retriage because we added input validation
@ZeroPath bypass

The rescan force command bypasses the cache and runs a full scan instead of an incremental refresh, even if a scan for the current commit already exists. This is useful when you want to re-analyze the entire PR from scratch rather than building on previous results. The bypass command overrides a failing ZeroPath PR check so it no longer blocks the merge. On GitHub, the bot directs you to use the Bypass Check button on the check run in the PR’s checks tab. On Azure DevOps, the bot performs the bypass directly by marking the PR’s scans as bypassed and posting a succeeded status, clearing the branch-policy merge gate. The bypass command requires the Bypass PR Check permission. When a command includes an explicit target (such as issue 2), that target always takes priority — even if the command is posted as a reply under a different finding’s comment thread. The thread context is used as a fallback only when no target is written in the command text. For example, @ZeroPath fp issue 2 posted as a reply under issue 5’s thread will act on issue 2, not issue 5. For the full command reference — every keyword, alias, target form, the because modifier, RBAC requirements, and platform support — see Bot Commands. When you change an issue’s status via a bot command, a vulnerability status changed notification is sent through your configured notification channels. The notification includes the previous status, new status, and who made the change, so your team has full visibility into triage decisions made from PR comments.

Bot commands are supported on GitHub, GitLab, and Azure DevOps. Bitbucket supports PR scanning but not bot commands yet. On Azure DevOps, you can use commands such as @zeropath rescan, @zeropath bypass, and other triage commands directly from PR comments. Use @ZeroPath as a universal alias, or replace it with your environment’s configured bot username.

Comments that appear to contain prompt injection content are automatically blocked. If you receive a rejection message, rephrase your question as a direct inquiry about the reported issue.

Bot commands must come from a human account. Comments from bot accounts (including other GitHub Apps) are automatically ignored to prevent feedback loops and ensure that every command is attributable to a real user.

When the bot answers questions about secrets findings, the raw secret value is automatically masked in its reply. The assistant receives and posts only the redacted form, so cleartext credentials are never echoed back into your pull request comments.

When your organization has access control enabled, bot commands require your VCS account to be linked to a ZeroPath user. On GitHub, you can link your account by setting your GitHub public email (Settings → Public profile) to match your ZeroPath account email, then commenting on a PR. The link is saved permanently, so you can switch the email back to private afterward. On GitLab, contact your org admin to link your account. When access control is disabled, anyone with comment access to the PR can use bot commands and the AI assistant without linking an account.

If the PR references specific vulnerabilities using ZP-ID tags or dashboard issue URLs (see Fix Verification), retriage re-runs fix verification against the latest PR code instead of the standard investigation flow. This checks whether the current PR changes actually resolve the referenced issues. If a fix verification is already in progress for the PR, the bot will let you know rather than creating a duplicate.

Configuration

All PR scanning settings follow an Organization → Tag → Repository inheritance cascade. Repository-level overrides take precedence.

Setting	Default	What It Controls
PR scanning enabled	Off	Master on/off switch for PR scanning on a repository. The current status is visible in the repository detail view and API response.
Inline review comments	On	Post inline comments on affected diff lines
PR summary (issues found)	On	Post a summary comment when the scan finds issues
PR summary (clean scan)	On	Post a summary comment when the scan finds no issues
Detailed vulnerability info	Not set	Include vulnerability descriptions, severity scores, and remediation details in PR summary comments. When not explicitly set, downstream settings apply.
Check status posting	On	Post pass/fail check status to VCS
Result inclusion threshold	0	Minimum score for a finding to appear in PR feedback
Check failure threshold	75	Priority score at which the check is marked as failing. Must be greater than or equal to the result inclusion threshold.
Scan timeout	10 min	Maximum time before the scan is marked as timed out. When the scan runs out of time before the AI agent can complete, ZeroPath preserves any findings already produced by other tools (such as secrets and SCA) rather than discarding the entire scan.
Auto-patching on PR scans	On	Generate fix suggestions for findings in the PR
Scan draft MRs	Off	Whether to scan draft pull requests and merge requests. By default, drafts are skipped and scanned automatically once marked ready for review. Enable to scan them immediately when opened or updated.
Scan bot PRs	Off	Whether to scan PRs opened by automation/bots
Allow PR check bypass	On	When enabled, a Bypass Check button appears on failing PR security checks, allowing authorized developers to override a blocking result. Disable this to remove the button entirely and prevent any bypass. In monorepo or multi-repository setups where a single PR triggers scans for more than one repository, the button is shown only when every repository involved in the PR allows bypass — if any repository has bypass disabled, the button is suppressed across all partitions of that PR check.
Tool toggles	All on	Enable/disable SAST, SCA, Secrets, and IaC individually for PR scans

GitHub Merge Queue Compatibility

If you use GitHub merge queues, ZeroPath handles merge-group events automatically. When a pull request enters the merge queue, GitHub creates a temporary merge commit and requests status checks on it. Because the PR was already scanned when it was opened or updated, ZeroPath does not re-scan the merge commit. Instead, it posts a neutral check on the merge-group head SHA, which the merge queue treats as passing. This ensures your merge queue does not hang waiting for a ZeroPath check that would never arrive. No additional configuration is required — if your GitHub App has the Merge queues read permission and the merge_group event subscription, merge queue compatibility works out of the box. Newly created GitHub Apps via ZeroPath’s setup flow include these permissions automatically.

If you are using an existing GitHub App that was created before merge queue support was added, you may need to accept the updated permissions in your GitHub App settings to enable the merge_group event subscription.

Automatic Repository Sync (GitHub)

ZeroPath automatically keeps your repository metadata in sync when changes happen on GitHub. The following events are detected and handled in real time via webhooks:

Event	What Happens
Repository renamed	The repository name is updated across ZeroPath, including all linked scan configurations
Repository transferred	Ownership and URL are updated to reflect the new organization or user
Repository archived	The repository is marked as archived in ZeroPath — no new scans will be triggered
Repository unarchived	The repository is restored to active status and scans resume normally
Repository deleted	The repository and its associated data are removed from ZeroPath

No manual action is required — these changes propagate automatically as long as the ZeroPath GitHub App is installed.

Azure DevOps

ZeroPath also detects repository rename and delete events on Azure DevOps via service hooks:

Event	What Happens
Repository renamed	The repository name is updated across ZeroPath
Repository deleted	The repository and its associated data are removed from ZeroPath

How PR Scanning Differs From Full Scans

Aspect	PR Scan	Full Scan
Scope	Changed files only (diff-focused)	Entire repository
Trigger	Automatic on PR open/update	Manual, scheduled, or on push
Speed	Fast (minutes)	Thorough (longer)
Differential	Yes — subtracts existing target-branch findings	No
Results	VCS check + inline comments + dashboard	Dashboard only
SCA gate	AI decides if dependency files changed	Always runs
Timeout	10 minutes (configurable)	Longer timeouts

Adoption Guide

Enable PR Scanning

Toggle it on in your repository’s scanner settings.

Install the VCS Integration

Ensure your GitHub App, GitHub Enterprise Server app, GitLab installation, Bitbucket integration, or Azure DevOps connection is configured.

Open a PR

ZeroPath will automatically scan it and post results.

Configure Branch Protection

Add the ZeroPath check as a required status check in your VCS branch protection rules.

Tune Thresholds

Adjust the check failure threshold and result inclusion threshold to match your team’s tolerance.

Review Inline Comments

Address findings directly in your code review workflow.

Getting Started

Scanning

SCA

Platform

Developer Tools

Integrations

Authentication

How It Works

Diff-Focused Analysis

Differential Comparison

Parallel Security Tools

AI Validation

Supported Platforms

What Gets Analyzed

Check Status & Feedback

Blocking Pull Requests

GitHub

GitHub branch protection docs

GitLab

GitLab successful pipeline docs

GitLab external commit status docs

Bitbucket

Bitbucket Cloud merge check docs

Bitbucket Data Center merge check docs

Azure DevOps Services

Bot Commands

Configuration

GitHub Merge Queue Compatibility

Automatic Repository Sync (GitHub)

Azure DevOps

How PR Scanning Differs From Full Scans

Adoption Guide

​How It Works

Diff-Focused Analysis

Differential Comparison

Parallel Security Tools

AI Validation

​Supported Platforms

​What Gets Analyzed

​Check Status & Feedback

​Blocking Pull Requests

​GitHub

GitHub branch protection docs

​GitLab

GitLab successful pipeline docs

GitLab external commit status docs

​Bitbucket

Bitbucket Cloud merge check docs

Bitbucket Data Center merge check docs

​Azure DevOps Services

​Bot Commands

​Configuration

​GitHub Merge Queue Compatibility

​Automatic Repository Sync (GitHub)

​Azure DevOps

​How PR Scanning Differs From Full Scans

​Adoption Guide

How It Works

Supported Platforms

What Gets Analyzed

Check Status & Feedback

Blocking Pull Requests

GitHub

GitLab

Bitbucket

Azure DevOps Services

Bot Commands

Configuration

GitHub Merge Queue Compatibility

Automatic Repository Sync (GitHub)

Azure DevOps

How PR Scanning Differs From Full Scans

Adoption Guide