这篇讲安全扫描已经发现高危漏洞、拉取请求却仍能合并时，怎么在合并前拦住。看完你可以打开 未通过时拒绝合并，设好 漏洞门禁阈值（达到这一级以及更严重的问题就拦），再用分支保护让管理员也绕不过去。
先登录 AngusGit，打开要设门禁的仓库。安全扫描在团队版、企业版和云服务中提供；社区版没有 安全 菜单。门禁只认已经扫描过的提交，所以先做下面两步：
- 系统管理员打开 管理 → 安全设置。页面标题是 AngusSecurity 集成。配置启用 要是 已启用，平台可达 要是 正常。还没开通时点 开通集成。页面要求先设置
angus.git.external-security.enabled=true时，把环境变量ANGUS_GIT_EXTERNAL_SECURITY_ENABLED设为true，改完重启 AngusGit。 - 仓库管理员进入该仓库 设置 → 安全，打开 本仓自动安全扫描，并至少打开 代码安全、依赖/制品漏洞、密钥检查 中的一种，然后保存。保存成功的提示是「安全设置已保存」。页面说明是「默认关闭。关闭后推送不再自动检查」。
1. 打开门禁
- 打开仓库的安全设置 进入仓库 设置 → 安全，找到 合并门禁 一节。页面提示「只有仓库管理员能修改。」
- 打开「未通过时拒绝合并」 说明是「默认关闭。打开后按 PR 最新提交的检查结论判定：还没检查完时等待，漏洞门禁或许可证门禁未通过时拒绝合并。直接合并分支同样受限。代码质量不参与。」
- 选漏洞门禁阈值 留空表示沿用租户默认，显示为「沿用租户（…）」；租户也没有设置时，默认是 高危。阈值怎么选见第 2 节。
- 确认自动扫描是打开的 门禁只认已经扫描过的提交。本仓自动安全扫描 关闭时，页面会提示「自动检查已关闭：新提交不会自动检查，PR 会一直等待。打开自动检查，或在代码页对分支手动检查。」看到这条提示，先把自动扫描打开。
2. 阈值选哪一级
阈值的意思是「达到这个级别就拦」。选某一级，就是这一级以及比它更严重的问题，只要有一个就拒绝合并。
| 阈值 | 什么情况会拦住合并 | 适合的情况 |
|---|---|---|
| 严重 | 有严重问题 | 刚开始推行，存量问题很多，先拦最危险的 |
| 高危 | 有严重或高危问题 | 大多数团队的默认选择 |
| 中危 | 有严重、高危或中危问题 | 安全要求高、存量问题已经清理干净的仓库 |
| 低危 | 有任何级别的问题 | 很少使用，容易频繁拦住正常合并 |
这里的「问题」包括代码安全、依赖/制品漏洞和密钥检查发现的问题，按严重级别计数。许可证问题单独由许可证门禁判断，代码质量问题不参与。
打开 未通过时拒绝合并 后，漏洞门禁总会参与判断，阈值没有「不启用」这一项，最宽松的设置是 严重。
建议从 高危 开始。门禁刚打开时，存量的高危依赖漏洞可能会挡住很多拉取请求，先集中修一轮，再考虑收紧到 中危。
修改阈值之后，已经检查过的提交不会按新阈值重新判定。页面提示「改了阈值后，需要重新检查才按新阈值判定。」要马上生效，对相关分支重新扫描一次。
3. 门禁到底拦住了什么
打开 未通过时拒绝合并 之后，拉取请求合并时会检查 源分支最新那一个提交 的安全检查结论：
| 最新提交的检查结论 | 能不能合并 | 页面提示 |
|---|---|---|
| 还没检查，或正在检查 | 不能 | 等待对提交 … 的安全检查 |
| 检查失败，或结果不完整 | 不能 | 请重新检查 |
| 漏洞数量达到或超过阈值 | 不能 | 漏洞门禁未通过：严重 …、高危 …、中危 …、低危 … |
| 漏洞数量未达到阈值 | 能 | 提交 … 的漏洞门禁已通过 |
有三点要特别说明：
- 只看最新提交。 往源分支推了新提交，结论会回到等待，按新提交重新判定。不会沿用旧提交的通过结论，也不会因为旧提交失败而一直挡住修好的代码。
- 不依赖分支保护。 即使目标分支没有任何保护规则，这道门禁也生效，通过接口合并同样会被拒绝。
- 管理员例外。 目标分支有保护规则、规则没有打开 对管理员同样生效、并且操作人是仓库管理员时，可以绕过这道门禁。目标分支没有保护规则时，管理员也会被拦住。
所以，要做到谁都绕不过去，还要在 设置 → 分支保护 里给 main 打开 对管理员同样生效。分支保护里还有一个 要求安全检查通过 开关，说明是「按 PR 最新提交的安全检查结论判定，没检查完时等待（默认关闭）」，作用和 未通过时拒绝合并 相同，只在这条保护规则覆盖的分支上生效。已经打开 未通过时拒绝合并 的仓库，不需要再打开它。
4. 被拦住之后怎么修
开发者看到拉取请求上的 AngusSecurity 失败，按下面的步骤处理：
- 看是哪些问题 在拉取请求的 状态检查 里点 打开仓安全详情，进入仓库安全详情页。按严重级别筛选，先看严重和高危。
- 按类别修 依赖漏洞看 修复版本，把依赖升级到这个版本或更高；代码安全问题看 修复建议 改代码；密钥问题把密钥从代码里移除，并且一定要去对应的系统里作废这把密钥，因为它已经进入了提交历史。
-
推送修复
在源分支上提交修复并
git push。推送会触发新的扫描，拉取请求上的安全检查先回到 进行中，扫完更新。 - 确认通过后合并 状态变成 成功，说明文字是「提交 … 的漏洞门禁已通过」，就可以合并了。
5. 常见的卡住情况
| 你看到的 | 原因 | 怎么处理 |
|---|---|---|
| 一直停在「等待对提交 … 的安全检查」，合并不了 | 这个提交没有被扫描。常见原因是自动扫描关了，或者提交是在网页上编辑的 | 打开自动扫描后重新推送；或者在仓库安全详情页 立即扫描 源分支 |
| 「提交 … 的安全检查失败，请重新检查」 | 扫描本身出错 | 重新扫描；仍然失败时到 AngusSecurity 查看扫描任务的错误 |
| 「提交 … 的检查结果不完整，请重新检查」 | 扫描完成但结果不可信，例如部分检查没有跑成功 | 重新扫描 |
| 改了阈值，拉取请求的结论没变 | 已检查的提交不会按新阈值重新判定 | 对源分支重新扫描一次 |
| 存量漏洞太多，几乎所有拉取请求都被拦 | 阈值相对当前代码太严 | 先把阈值放到 严重，集中清理存量问题后再收紧 |
| 管理员能合并，其他人不能 | 分支保护没有打开 对管理员同样生效 | 按团队规定决定是否打开 |
常见问题
只拦 main，其他分支不拦，可以吗？
未通过时拒绝合并 对这个仓库的所有拉取请求生效。只想拦特定分支时，不打开它，改为在那个分支的保护规则里打开 要求安全检查通过。
发现的漏洞确认不影响我们，能放行这一次吗？
门禁按数量判断，没有针对单个问题的豁免开关。可以在安全详情里把这个问题的 处置状态 改为 已知悉 或 误报，记录判断结论；需要放行时，由仓库管理员按分支保护的规则合并，或者临时调整阈值后重新扫描。这类操作建议在团队里约定好由谁决定。
门禁和流水线的状态检查有冲突吗？
没有。两者都显示在拉取请求的 状态检查 里，合并时分别判断，都满足才能合并。
小结
让漏洞挡住合并，在仓库 设置 → 安全 打开 未通过时拒绝合并，漏洞门禁阈值 从 高危 开始。门禁按源分支最新提交的检查结论判断：没检查完就等待，达到阈值就拒绝，修好推送后重新判定。它不依赖分支保护，接口合并也受限；要让管理员也受限，在分支保护里打开 对管理员同样生效。前提是 本仓自动安全扫描 已打开，否则拉取请求会一直等待。安全扫描在团队版、企业版和云服务中提供；社区版没有 安全 菜单，需要时请使用团队版或企业版。
结论： 在仓库 设置 → 安全 打开 未通过时拒绝合并 并设好 漏洞门禁阈值（如 高危），拉取请求源分支最新提交只要检出达到该级别的问题就会被拒绝合并。
Top comments (0)