This article explains how to read the security check on a pull request, and what each note means. After reading it, you can read the AngusSecurity row under Status checks as Success or Failed, then click Open repo security details to see which file or dependency is involved.
The example is pull request #1 in the repository xlliu/e2e-license-gate. AngusSecurity on #1 is Success. The note is “Vulnerability gate and license gate both passed for commit 1f78310a”. A gate is a rule that refuses the merge when its condition is met. The vulnerability gate looks at vulnerability counts. The license gate looks at the open-source licenses used by dependencies. The pull request shows only that one conclusion. The details are on the repository security page.
The security check is available on Team, Enterprise, and Cloud Service, and AngusSecurity has to be connected first. The steps below only read an existing scan result. You do not need to click Start scan, and you do not need to change a finding’s disposition.
1. Where the conclusion is
Open the pull request and stay on the Conversation tab. In the middle of the page is a Status checks card. Status checks gather the automatic checks on the pull request. Each check is one row, and it shows Pending, Success, or Failed. The security check is named AngusSecurity.
Compared with the other checks, the AngusSecurity row has two extra pieces:
- A note under the name. It is the reason for this decision.
- Open repo security details on the right. It opens the security page for this repository.
Pull request #1 is titled e2e GIT-08 pending gate. It has already been merged from e2e-git08 into main. The page is https://git.anguskit.com/pulls/xlliu/e2e-license-gate/1.
Merged pull request #4 in the same repository shows a different success note: “Vulnerability gate passed for commit d3ebc5ab”. It leaves out the license gate because the check on #4 uses a later scan that skipped the license check. The table in the next section explains both success notes.
2. What each status means
The badges Pending, Success, and Failed are only the check status. One badge can cover several reasons, so read the note to tell them apart. A check that is not finished yet shows the Pending badge. The table lists the product’s own sentences. {8 chars} is the first 8 characters of the commit id, and {n} is a count:
| Badge | Note | Meaning |
|---|---|---|
| Pending | Waiting for the security check of commit {8 chars} | This commit has no check job yet |
| Pending | Security check of commit {8 chars} is in progress | The job is queued or scanning |
| Pending | Security check of commit {8 chars} is incomplete. Run the check again | The scan result is incomplete and needs another scan |
| Pending | No commit is available to check | The pull request has no commit id yet |
| Failed | Security check of commit {8 chars} failed. Run the check again | The scan job itself failed |
| Failed | Vulnerability gate did not pass: critical {n}, high {n}, medium {n}, low {n} | The vulnerability counts reached the repository’s threshold |
| Failed | License gate did not pass | The license gate is on, and this license check did not pass |
| Failed | License gate is enabled, but this check did not include license compliance | The license gate is on, and this scan did not check licenses |
| Success | Vulnerability gate passed for commit {8 chars} | Vulnerabilities are under the threshold. The license gate did not take part |
| Success | Vulnerability gate and license gate both passed for commit {8 chars} | Both gates passed. #1 uses this sentence |
A few points about this repository:
- The conclusion uses only the latest finished scan of this commit. If you push a new commit to the source branch, a pull request that is still open goes back to “Waiting for the security check of commit …”. It does not keep the previous commit’s conclusion.
- The vulnerability threshold is chosen in this order: the repository’s own setting, then the tenant default, then High when the tenant has no setting either. On this repository the tenant default is Low, and
e2e-license-gateitself is set to High, so the decision uses high. At high, only critical and high are counted. Medium and low can be above zero and this row can still show Success. - Code quality results do not take part in this row.
- #1 and #4 in the example both show Success, while the repository overview still says “License gate did not pass. Merge rejected”. An open
GPL-3.0-onlyfinding is still on the repository. Section 3 shows its category. A check row on a pull request that is already merged is not rewritten when a finding appears later.
3. Open the row and see the actual problem
Open repo security details goes to the repository security page at https://git.anguskit.com/security/repos/xlliu/e2e-license-gate. It opens on Overview. This repository has a score of 95. Critical, high, medium, low, secrets, and quality are all 0. License risk is 1.
The tabs are Overview, Vulnerabilities, Dependencies, Secrets, Licenses, Quality, Scan history, and Settings. The open findings on this repository are on the Licenses tab. There are two. The high one is GPL-3.0-only, category Strong copyleft. The low one is MIT, category Permissive. A license category describes how loose the terms are. A strong-copyleft license, such as GPL, requires the related code to be published under the same license when you distribute the software. A permissive license, such as MIT, mainly requires you to keep the copyright notice, and a closed-source product can use it.
Open the high finding and a detail drawer slides in from the side of the page. It includes:
-
Location:
package.json. The component ise2e-with-gpl@1.0.0. -
License:
GPL-3.0-only. The category is Strong copyleft. -
Description:
Declared by project manifest. The license is declared by the project manifest file. -
Ref / commit:
e2e-git07 @591d671. - Disposition: Open. Disposition records what the team decided about this finding. The other values are Acknowledged, Resolved, Suppressed, and False positive. Every change leaves a disposition record, so leave it Open when you are only reading the result.
- Two links: View in code and Open in Security.
Fixed version appears only when the finding itself has a version you can upgrade to. That is usually a dependency vulnerability. This finding is a license finding, so the drawer has no fixed version. If you open a secret finding, the page says: “Secret findings do not show plaintext snippets here. Open the Security console for details.”
Security in the sidebar is the security console across repositories. You can read every repository’s results there. Its tabs are Repo risk, Vulnerabilities, Secrets, Licenses, Quality, and Scan history.
4. What to check when the row is missing
| What you see | Cause | What to do |
|---|---|---|
| “AngusSecurity is not connected” | The integration is not provisioned | A system admin provisions it under Management → Security settings |
| “No security scan yet” | The integration is provisioned, and this repository has never been scanned | Turn on auto-scan, or have a repository admin scan once by hand |
Status checks has no AngusSecurity row |
The commit has no finished scan, and the repository has not turned on Block merge when the gate fails | Turn on auto-scan, then push once more |
| The note stays on “Waiting for the security check of commit …” | This commit has no scan job | Turn on Auto security scanning for this repo and push a new commit, or scan the source branch by hand |
| The sidebar has no Security | This is Community | The security check is available on Team, Enterprise, and Cloud Service |
The example instance is already provisioned. Two rows in the table need a longer note. The first is a missing AngusSecurity row under Status checks. That happens only when all three are true: this commit has no finished scan, the repository has not turned on Block merge when the gate fails, and the pull request does not already have this check. The other way around: if the scan finished before the pull request was created, the pull request attaches the existing result even when block-merge is off. The second is a note that stays on waiting. While auto-scan is off, a new commit does not create a scan job, so the note stays on “Waiting for the security check of commit …”.
Besides a command-line push, editing a file on the web and committing, or clicking merge on the pull request page, also puts a new commit on the target branch and sends a scan job to AngusSecurity. While auto-scan is off, those actions do not start a scan either.
Common questions
AngusSecurity failed. Can I still merge?
The example repository has Block merge when the gate fails turned on. With that switch on, the merge API refuses a pull request whose check did not pass. The message is “Security check did not pass, cannot merge:”, followed by the note on this row. Merging a branch straight into the target branch is held to the same rule.
Whether the merge button on the page can be clicked also depends on branch protection (the merge rules set on a branch). Before the branch protection rules have loaded, any check that is not Success disables the button, with the note “All required status checks must pass”. After the rules have loaded, if no check is marked required, the button does not go gray because this row failed. After you click merge, the server still refuses it according to Block merge when the gate fails.
Does a reviewer have to wait until the security check finishes?
No. Review and the security check do not depend on each other. #1 has no reviewers assigned, and the check result is already Success.
Can I see the vulnerability list on the pull request?
The pull request shows this one conclusion and Open repo security details. The files, dependencies, and license findings are on the repository security page.
Summary
The AngusSecurity row under Status checks on a pull request is the gate conclusion of the latest scan of that commit. The badge only says Pending, Success, or Failed. The reason is in the note: the scan itself failed, the vulnerability count reached the threshold, or the license did not pass. To see the actual problem, click Open repo security details. On xlliu/e2e-license-gate, #1 says “Vulnerability gate and license gate both passed for commit 1f78310a”, and the open finding on the repository is GPL-3.0-only in package.json, category Strong copyleft.
The security check is available on Team, Enterprise, and Cloud Service. Community has no Security menu.
Conclusion: The AngusSecurity row under Status checks on a pull request is the gate conclusion of the latest scan of that commit. To see which file or dependency is involved, click Open repo security details and read the repository security page.
References
- AngusGit manual: Security
- AngusGit manual: Pull requests
- AngusSecurity and AngusGit together: scans on push and pull request
- After you push: how to run a code security scan automatically
- How to block vulnerabilities before merge
- How a pull request triggers a pipeline, and whether a red pipeline can still merge
Top comments (1)
The key habit is to turn a scan finding into a triage decision with evidence: exploitable path, affected boundary, compensating control, owner, and expiry for any accepted risk. Otherwise teams alternate between closing real issues as noise and carrying noisy alerts forever. A PR is a great place to capture that decision while context is still fresh.