Pull Request scans

Scan pull requests created in your repository.

Scan pull requests as soon as they are raised in your repository. PR scans detect vulnerabilities in your branch when they are introduced, making it easier to 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 are merged. You can run PR scans in the following ways:

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 the default branch is chosen and used. 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.

You can scan pull requests or merge requests using endorctl for GitHub, GitLab, and Bitbucket. The --pr flag runs the scan for the current commit and records the results as PR runs that do not affect main branch monitoring scans and reports. Endor Labs stores PR and MR scan findings in PR Runs for three weeks, after which they are removed to accommodate new PR scans.

Run the following command after you commit to a pull request or merge request:

endorctl scan --pr

You can perform an incremental PR scan to scan only changed code and dependencies.

An incremental PR scan scans only the parts of the codebase and dependencies that have changed since the last full baseline scan.

  • Endor Labs identifies packages and dependencies in the PR and scans only those that changed relative to the baseline.
  • If no dependencies changed, the scan is skipped, and Endor Labs reports No changes found.
  • Incremental PR scans only report findings that do not exist in the baseline and are associated with changed dependencies in the PR.
  • You can enable incremental PR scans using the --pr-incremental flag or the equivalent CI settings. This flag is also available for SAST incremental scans and Incremental secret scans.

You need to set a baseline for incremental PR scans so only findings new relative to that branch are reported. For GitHub App or GitLab App scans, or when PR comments are enabled, the baseline is detected automatically. Otherwise, pass --pr-baseline when you run the scan. See Set a default branch for how the default branch is chosen and used.

Baseline mismatch in PR scans
If a finding is fixed in the baseline by upgrading or downgrading a dependency and a PR still modifies that package, the finding can be reported as new. To mitigate this, rebase the PR with the latest baseline content and re-run the PR check.

Run the following command to perform an incremental PR scan. Replace main with your baseline branch.

endorctl scan --pr --pr-baseline=main --pr-incremental

When you set --enable-pr-comments, you must also set --scm-pr-id so the scan can determine where to post comments and infer the baseline automatically.

To run an incremental PR scan and publish findings as review comments on a GitHub PR, use the following command. The --scm-pr-id flag associates the scan with the PR, and comments are posted according to your action policies.

endorctl scan \
  -n <your-namespace> \
  --pr \
  --pr-incremental \
  --scm-pr-id <pull-request-id> \
  --github-token <your-github-token> \
  --enable-pr-comments

In this command:

  • --pr-incremental: Limits the scan to changes relative to the baseline branch.
  • --scm-pr-id: Links the run to the specific PR so comments are attached correctly.
  • --enable-pr-comments: Posts scan results as comments on the PR. When you set --enable-pr-comments, you must also set --scm-pr-id so the scan can determine where to post comments and infer the baseline automatically.
  • --github-token: Authenticates with GitHub to post comments.

The Endor Labs SCM integrations let you scan pull requests or merge requests when they are opened or updated. In the integration settings, enable PR or MR scans to run them automatically and, optionally, enable pull request comments to post findings as review comments. Action policies apply to PR scans the same way as to other scan types.

The following describe platform-specific setup and configuration options:

PR scans can be run from a continuous integration pipeline by invoking endorctl scan with pull request flags in jobs triggered by pull request or merge request events. This approach provides control over when scans run, supports posting findings as PR or MR comments, and allows policies to be enforced, such as failing builds or blocking merges. The scan profile assigned to the project determines the toolchains and environment used for the scan.

A scan profile defines the configuration applied to PR scans for a project, including languages, toolchains, path filters, and parameters such as enable_automated_pr_scans and enable_pr_comments. For CI-initiated PR scans, the scan profile determines the toolchains and environment configuration used to execute the scan.

Note

App-triggered PR scans run only when both of the following are true.

  • Pull Request scans or Merge Request scans are enabled during SCM app installation so the app receives PR or MR events.
  • Pull request scans or enable_automated_pr_scans is enabled in the scan profile assigned to the project.

To scope app-triggered PR scans to selected projects, enable Pull request scans only in the scan profiles assigned to those projects. In GitLab, MR scans can alternatively be scoped by configuring merge request webhooks for selected projects. See Configure scan profile through the UI for more information on scan profile settings.

PR comments are automated comments posted on pull or merge requests when Endor Labs detects policy violations during a PR scan. Enable them in your SCM integration or using --enable-pr-comments in CI, then configure an action policy with Branch Type Pull Request. See Pull Request comments and Action policies for setup and configuration.

PR scan findings are stored as PR Runs and kept for three weeks to accommodate new PR activity.

To view PR scan results in the Endor Labs:

  1. Sign in to Endor Labs and 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.

From PR Runs you can see scan metadata, a severity summary, and open any scan for findings, issues, and logs. See PR Runs for more information.

How long are PR scan results retained?
Endor Labs retains PR scan findings as PR Runs for three weeks.
Why does a finding appear as new when it was fixed in the baseline?
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.
Why do two PR scans on the same pull request produce different results?
Results can differ when the PR or baseline branch changes, the scan profile is updated, or the vulnerability database is updated 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.
Do PR scans block merges automatically?
No, PR scans do not block merges by default. Blocking occurs only when policies are configured to fail CI jobs, apply blocking status checks, or prevent merges through PR comments.
Why does an incremental PR scan fall back to a full scan?
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. Ensure the baseline branch has been scanned at least once before relying on incremental scans.