Skip to main content
Scan pull requests as soon as they open in your repository. PR scans detect vulnerabilities in your branch as they enter the code, so you can identify and fix them early. PR scans help you to:
  • Detect new vulnerabilities as developers open or update PRs, instead of after merge.
  • Gate merges based on security and compliance.
  • Enforce policies that can block risky PRs or fail CI builds.
  • Give developers fast feedback on open source, SAST, and secrets findings tied to their changes through PR comments and PR Runs in the Endor Labs UI.
Endor Labs supports scanning pull requests and merge requests to evaluate the impact of proposed changes before they merge. You can run PR scans in the following ways:
  • Run PR scans with endorctl to run pull request scans from the CLI. This approach supports scanning the pull request branch and scanning changes relative to a baseline branch.
  • Configure PR scans to trigger scans automatically from an SCM app or a CI pipeline when someone opens or updates a pull request or merge request.
Once you have findings, see Block pull requests on findings to gate merges on the results.

​
Pull request scan workflow

The following workflow describes a robust approach for scanning pull requests and merge requests against a stable baseline branch.
  1. Establish and maintain a baseline branch Scan your baseline branch, such as main, regularly with monitoring scans or CI scans. See Set a default branch for how Endor Labs chooses and uses the default branch. See Scanning strategies and Branches and workflows for more information on branch strategy, default branch setup, and recommended scan flags.
  2. Trigger PR scans on feature branches Configure PR scans for PRs targeting the baseline branch, for example, main. For large monorepos, enable incremental PR scans to focus only on changed dependencies and code.
  3. Use policies to enforce standards Use finding and action policies to decide when to warn, break builds, or block merges for PR scans.
  4. Integrate first-party scans Optionally, for app-triggered scans, enable SAST and secrets in the SCM integration when you install or manage the app. For CI-triggered scans, include the appropriate endorctl flags and steps in your pipeline so each run covers dependencies, first-party code, and secrets as needed. To analyze first-party code changes with AI SAST on pull requests, see AI SAST PR scans.
The following diagram shows how a pull request scan flows from the baseline to the merge decision.

​
View PR scan findings

Endor Labs stores PR scan findings as PR Runs and keeps them for three weeks to accommodate new PR activity. PR Runs shows only scans for the branch you have selected. Switch branches at the top of the project page to see another branch’s runs. Endor Labs scopes each run by its PR Baseline; runs without one, including CLI scans run without --pr-baseline, fall under the default branch. To view PR scan results in the Endor Labs:
  1. Select Projects from the left sidebar.
  2. Search for and select your project from the list.
  3. Select PR RUNS to review the past scans. PR Runs captures the commit ID, Commit SHA, the referenced branch, its findings, and the tags added to the scan as configured in the policies. Select the specific PR scan to view its findings in detail. You can view the scan metadata, severity summary, and open any scan for findings, issues, and logs.
PR scan results in PR Runs

​
FAQs

Endor Labs retains PR scan findings as PR Runs for three weeks.
PR Runs is scoped to the branch you have selected for the project. Select a different branch to view the PR Runs recorded against it. A PR Run without a recorded PR Baseline, including a CLI scan run without --pr-baseline, appears under the default branch. See View PR scan findings for more information.
Endor Labs reports a finding as new if the baseline includes a fix for the issue and the pull request modifies the affected package. To resolve the finding, rebase the pull request on the latest baseline and re-run the PR scan.
Results can differ when the PR or baseline branch changes, when you update the scan profile, or when Endor Labs updates the vulnerability database between runs. PR Runs store the findings produced at the time of execution. Subsequent PR scans evaluate the pull request using the current scan profile and the latest analysis data.
No, PR scans do not block merges by default. Blocking requires an action policy that breaks the build and a required status check that enforces the result. See Block pull requests on findings for the steps.
Yes. The branch must already be a monitored version of your project, and you must allow it as a PR scan target branch under Monitored versions in the project’s settings. Enabling PR scans on a non-default monitored branch consumes additional scan credits. See Enable PR scans on monitored non-default branches for the steps.
A change to the PR scan target branch setting can take up to 10 minutes to apply. See Enable PR scans on monitored non-default branches for details.
Endor Labs falls back to a full PR scan when no valid baseline exists for the project or when it cannot determine what changed relative to the baseline. Scan the baseline branch at least once before you rely on incremental scans. See Troubleshoot incremental PR scan performance for more checks.