Skip to main content
A PR scan reports findings, but it does not block a merge on its own. To gate a pull request, ensure that you have the following configurations:
  • An action policy that breaks the build when the findings you care about appear.
  • A required status check in your source control manager that enforces the result before a merge.
The action policy decides which findings block a pull request, and the required status check is what stops the merge.

Create an action policy that breaks the build

In Endor Labs, create an action policy and choose the Break the Build enforcement action. Select the policy template for the finding types you want to gate, such as SCA, secrets, or SAST. The policy applies to PR scans the same way it applies to other scans. See Create an action policy from template for the full procedure.

Configure the required status check in GitHub to block merges

GitHub blocks a merge only when the Endor Labs check is a required status check on the target branch. The check you require depends on how Endor Labs scans your pull requests. The check appears as a selectable option only after it has reported on a pull request within the last seven days. Open or update a pull request so the Endor Labs check runs once, then add it to your branch protection rule. To add the check to a branch protection rule:
  1. In your GitHub repository, select Settings > Branches.
  2. Next to the rule for your default branch, click Edit.
  3. Select Require status checks to pass before merging.
  4. Enter the check name (Endor Labs Automated Scan for the GitHub App, or your workflow job name for GitHub Actions), and select it from the results.
  5. Click Save changes.
To create a rule instead, click Add branch protection rule, enter a Branch name pattern, and follow the same steps. GitHub also supports requiring status checks through repository and organization rulesets, which GitHub now recommends. Use an organization ruleset to enforce the check across many repositories at once. For more information, refer to About rulesets. After you require the check, GitHub keeps the merge blocked until the check passes. A check that concludes as neutral or skipped does not block the merge, even when it is required. Endor Labs reports a neutral result when there is nothing to scan, such as a pull request with no relevant changes. For more information, see Managing a branch protection rule and About rulesets, and Troubleshooting required status checks in the GitHub documentation.

Configure the required status check in Azure DevOps to block merges

To block pull requests from merging, configure a branch policy that requires the Endor Labs pull request status. The merge is blocked until the status succeeds. The Azure DevOps App posts this status as endorlabs/Endor Labs Automated Scan, which is what you select when you create the branch policy. You can select the status only after Endor Labs posts it to a pull request at least once. Open or update a pull request to let the scan run, and then add the branch policy. You can also enter Genre and Name manually before the first scan. To require the status on your default branch:
  1. In Azure DevOps, select Project settings > Repositories.
  2. Search for and select your repository.
  3. Select Policies.
  4. Under Branch Policies, select your default branch, such as main.
  5. Next to Status checks, click +.
  6. Select endorlabs/Endor Labs Automated Scan as the status to check.
  7. Set Policy requirement to Required.
  8. Optionally, set Authorized identity to the account that the Azure DevOps App authenticates with. Only statuses posted by that account satisfy the policy.
  9. Under Reset conditions, clear Reset status whenever there are new changes. Endor Labs binds each status to the pull request iteration it scanned, so the reset keeps the merge blocked until the latest scan succeeds.
  10. Click Save.
The status fails when a finding matches an action policy set to Break the Build, and also when the scan itself fails to complete. Findings that match a Warn action policy still generate pull request comments, but the merge is not blocked. A Not Applicable status does not block a merge, even if the Policy requirement is set to Required. Endor Labs reports this status when the base branch of the pull request has not yet been scanned, or when the scan could not be performed. For more information, refer to Configure a branch policy for an external service and Iteration status.

Block merges for PR scans run from Azure Pipelines

When you run endorctl in an Azure Pipelines job instead of using the Azure DevOps App, Endor Labs does not post a pull request status. If a finding matches an action policy set to Break the Build, endorctl exits with code 128, causing the pipeline job to fail. See Scanning in Azure Pipelines to learn how to configure the pipeline. To block merges based on findings, configure a build validation policy for the pipeline that runs the Endor Labs scan. The merge remains blocked until the pipeline job succeeds. To require the pipeline on your default branch:
  1. In Azure DevOps, select Project settings > Repositories.
  2. Search for and select your repository.
  3. Select Policies.
  4. Under Branch Policies, select your default branch, such as main.
  5. Next to Build validation, click +.
  6. Select the Build pipeline that runs the Endor Labs scan.
  7. Under Trigger, choose Automatic (whenever the source branch is updated).
  8. Set Policy requirement to Required.
  9. Click Save.
For more information, refer to Set build validation.