This article explains how to block a merge when a security scan has already found high-severity vulnerabilities and the pull request can still be merged. After reading it, you can turn on Block merge when the gate fails, set the Vulnerability gate threshold (a finding at that level or worse blocks the merge), and use branch protection so an administrator cannot bypass it.
Sign in to AngusGit and open the repository where you want the gate. Security scanning is available on Team, Enterprise, and Cloud Service. Community has no Security menu. A gate only judges commits that have already been scanned, so do these two steps first:
- A system admin opens Management → Security settings. The page title is AngusSecurity integration. Config enabled must be On, and Platform reachable must be OK. If it is not provisioned yet, click Provision. When the page asks you to set
angus.git.external-security.enabled=truefirst, set the environment variableANGUS_GIT_EXTERNAL_SECURITY_ENABLEDtotrueand restart AngusGit. - A repository admin opens that repository’s Settings → Security, turns on Auto security scanning for this repo, and turns on at least one of Code security, Dependency and artifact vulnerabilities, and Secret scanning, then saves. A successful save says “Security settings saved”. The page says: “Off by default. Push does not start a scan while this is off.”
A gate is a rule that refuses the merge when its condition is met.
1. Turn the gate on
- Open the repository security settings
Open the repository’s Settings → Security and find the Merge gate section. The page says: “Only repository admins can change these.”
- Turn on Block merge when the gate fails
The note says: “Off by default. When on, the gate uses the check of the PR's latest commit: the merge waits until that check finishes, and is refused when the vulnerability gate or the license gate fails. Direct branch merges are held to the same gate. Code quality does not count.”
- Choose the vulnerability gate threshold
Leave it empty to follow the tenant default. The page shows “Tenant default (…)”, with the tenant’s current level in the parentheses. When the tenant has no setting either, the default is High. How to choose the level is in section 2.
- Confirm auto-scan is on
The gate only recognizes a commit that has already been scanned. When Auto security scanning for this repo is off, the page says: “Automatic checks are off, so new commits are not checked and PRs keep waiting. Turn on automatic checks, or run a check on the branch from the code page.” If you see that note, turn auto-scan on first.
2. Which threshold to pick
The threshold means “block when a finding reaches this level”. Pick one level, and any finding at that level or worse refuses the merge as soon as there is one.
| Threshold | What blocks the merge | When it fits |
|---|---|---|
| Critical | A critical finding | You are just starting, and many old findings are still there. Block only the most dangerous |
| High | A critical or high finding | The usual starting point for most teams |
| Medium | A critical, high, or medium finding | A repository with a strict bar, after the old findings are already cleaned up |
| Low | A finding at any level | Rarely used. It often blocks ordinary merges |
“Finding” here includes what Code security, Dependency and artifact vulnerabilities, and Secret scanning find, counted by severity. License findings are judged by the license gate on their own. Code quality findings do not take part.
After Block merge when the gate fails is on, the vulnerability gate always takes part. The threshold has no Disabled value. The loosest setting is Critical.
Start at High. When the gate is first turned on, existing high-severity dependency vulnerabilities can block many pull requests. Fix that round first, then consider tightening to Medium.
Commits that were already checked are not judged again under a new threshold. The page says: “After changing a threshold, run the check again to apply it.” To apply it now, scan the related branches again.
3. What the gate actually blocks
After Block merge when the gate fails is on, merging a pull request checks the security conclusion of the latest commit on the source branch:
| Check result of the latest commit | Can it merge? | What the page says |
|---|---|---|
| Not checked yet, or still checking | No | Waiting for the security check of commit … |
| The check failed, or the result is incomplete | No | Run the check again |
| The vulnerability count reaches the threshold | No | Vulnerability gate did not pass: critical …, high …, medium …, low … |
| The vulnerability count is under the threshold | Yes | Vulnerability gate passed for commit … |
Three points matter:
- Only the latest commit counts. Push a new commit to the source branch and the conclusion goes back to waiting, then it is judged on the new commit. An old commit’s pass is not reused, and an old commit’s failure does not keep blocking code that has been fixed.
- It does not depend on branch protection. The gate still applies when the target branch has no protection rule. A merge through the API is refused the same way.
- Administrator exception. When the target branch has a protection rule, that rule has not turned on Include administrators, and the person acting is a repository admin, they can bypass this gate. When the target branch has no protection rule, an administrator is blocked too.
To make sure nobody can bypass it, also turn on Include administrators for main under Settings → Branch Protection. Branch protection has another switch, Require security check to pass. Its note says: “Uses the security check of the PR's latest commit and waits until it finishes (off by default)”. It does the same job as Block merge when the gate fails, and it applies only to branches covered by that protection rule. A repository that already has Block merge when the gate fails turned on does not need this switch as well.
4. How to fix it after a merge is blocked
When a developer sees AngusSecurity fail on the pull request, follow these steps:
- See which findings they are
Under Status checks on the pull request, click Open repo security details and open the repository security page. Filter by severity and look at critical and high first.
- Fix by category
For a dependency vulnerability, read Fixed version and upgrade the dependency to that version or higher. For a code security finding, read Remediation and change the code. For a secret, remove the secret from the code, and revoke that secret in the system it belongs to. It is already in the commit history.
- Push the fix
Commit the fix on the source branch and git push. The push starts a new scan. The security check on the pull request goes back to Pending, then updates when the scan finishes.
- Merge after it passes
When the status is Success and the note is “Vulnerability gate passed for commit …”, you can merge.
5. Usual stuck states
| What you see | Cause | What to do |
|---|---|---|
| It stays on “Waiting for the security check of commit …”, and you cannot merge | This commit was not scanned. A common cause is that auto-scan is off, or the commit was made by editing on the web | Turn on auto-scan and push again, or Scan now the source branch on the repository security page |
| “Security check of commit … failed. Run the check again” | The scan itself failed | Scan again. If it still fails, open the scan job on AngusSecurity and read the error |
| “Security check of commit … is incomplete. Run the check again” | The scan finished, and the result is not trustworthy. For example, part of the check did not run successfully | Scan again |
| You changed the threshold, and the pull request conclusion stayed the same | A commit that was already checked is not judged again under the new threshold | Scan the source branch once more |
| So many old vulnerabilities that almost every pull request is blocked | The threshold is strict for the code you have now | Set the threshold to Critical first, clean up the old findings, then tighten it |
| An administrator can merge, and other people cannot | Branch protection has not turned on Include administrators | Decide with the team whether to turn it on |
Common questions
Can I block only main and leave other branches alone?
Block merge when the gate fails applies to every pull request in this repository. To block one branch only, leave that switch off and turn on Require security check to pass in the protection rule for that branch.
We confirmed a finding does not affect us. Can we let this one through?
The gate counts findings. There is no exemption switch for a single finding. On the security page you can change that finding’s Disposition to Acknowledged or False positive and record the decision. To let the merge through, a repository admin merges under the branch protection rules, or you temporarily change the threshold and scan again. Agree in the team who is allowed to make that call.
Does the gate conflict with a pipeline status check?
They both show under Status checks on the pull request. At merge time each one is judged on its own, and both have to be satisfied.
Summary
To let vulnerabilities block a merge, open Settings → Security on the repository, turn on Block merge when the gate fails, and start the Vulnerability gate at High. The gate uses the check result of the latest commit on the source branch: it waits while the check is unfinished, refuses the merge when the count reaches the threshold, and judges again after you push a fix. It does not depend on branch protection, and an API merge is held to it too. To hold administrators to it as well, turn on Include administrators in branch protection. Auto security scanning for this repo has to be on. Otherwise the pull request keeps waiting. Security scanning is available on Team, Enterprise, and Cloud Service. Community has no Security menu. When you need this gate, use Team or Enterprise.
Conclusion: Turn on Block merge when the gate fails under Settings → Security and set the Vulnerability gate threshold (for example High). A pull request is refused when the latest commit on the source branch has a finding at that level.
References
- AngusGit manual: Security
- AngusGit manual: Branches and merge
- After you push: how to run a code security scan automatically
- How to read code security scan results on a pull request
- How to block a non-compliant open-source license before merge
- How to protect the Git main branch: turn on branch protection, then merge through a pull request
Top comments (1)
لحجب الثغرات الأمنية قبل دمج أي كود جديد (Merge)، اتبع الخطوات التالية:
فحص تلقائي (SAST): اربط مستودعك بأدوات فحص تلقائي تفحص الكود الجديد لحظة رفعه وتكشف الأخطاء والثغرات فوراً.
قواعد صارمة للدمج: امنع أي شخص (حتى أنت) من عمل Merge للفرع الأساسي إلا بعد نجاح الفحوصات الأمنية وخلو الكود من المشاكل.
إخفاء البيانات الحساسة: تأكد دائماً أن كلمات المرور ومفاتيح الربط (API Keys) غير مكتوبة صراحة داخل الكود.