GitHub权限与Coroid安全检查

Security通过Coroid的GitHub应用运行。本页列出了该应用为Security所需的权限，以及Coroid Security检查的报告内容，讲解如何让GitHub强制启用该检查，以及GitHub自身的安全告警如何在Security中显示。

权限#

Security使用该应用针对你的代码库已有的权限：读取代码和拉取请求、写入检查结果。这些权限均为可选，每项权限对应一项功能：

当该应用申请新权限时，GitHub会请求你所在组织的所有者为该安装实例批准权限。在此之前，Security→概览会列出缺少该权限的代码库，并附上在GitHub上的安装页面链接。

Coroid还会通过GitHub的事件及向GitHub查询，获取每个代码库是公开还是私有的信息，以此判断可在其中发布的内容。详见披露。

Coroid安全检查#

Coroid Security该检查为一个独立检查项，名称统一；无论其单独运行还是作为项目交付流程图中的一部分在Quality Control中执行，一个代码库仅需启用一次即可。它会报告针对每次变更的防护情况：易受攻击的依赖项和泄露的机密信息。两者中以严重程度更高者为准。代码扫描结果通过Quality Control的检查呈现，安全审核则通过Coroid的审核检查反馈。

它会在通过该应用连接的GitHub代码库上运行：

• 当pull request被创建、重新打开、更新或标记为待审核时；
• 每次合并队列提交时，需具备合并队列权限；
• 有人在GitHub上重新运行该检查时。

事件触发后，该检查会立即显示为进行中状态。点击其详情链接可在Security中打开对应项目。

它报告的内容#

它永远不会显示为“跳过”：GitHub将跳过的必检项视为通过，因此未运行的强制执行防护会被判定为通过。必检项总会返回上述某种结果，所以合并队列不会无限等待。

该检查仅统计变更引入的内容，不包含基准分支上已有的风险项。其描述不会提及非公开的风险项；只会说明发现的风险项数量、阈值，并注明详情可在Coroid中查看。

启用Coroid安全检查#

强制执行防护会导致该检查结果为失败。只有当代码库要求通过该检查时，GitHub才会阻止合并操作：

1. 分支保护：在代码库的设置→分支中，编辑默认分支的规则，开启要求状态检查通过才能合并，然后添加Coroid Security。
2. 规则集：在设置→规则→规则集中，添加要求状态检查通过到默认分支的规则集中，添加Coroid Security，然后选择Coroid的GitHub应用作为来源。
3. 合并队列：在同一规则中要求通过该检查。该应用需具备合并队列权限，才能在合并队列提交时运行该检查。

在您想要强制执行的防护策略生效之后，即可启用此项要求。只要满足观测条件的检查项就会判定为通过。

GitHub安全告警#

借助GitHub安全告警在「安全」→「设置」中开启此项功能并配置上述权限后，安全模块会将Dependabot、代码扫描及机密信息扫描生成的告警，作为与Coroid自身扫描结果一致的观测数据导入。新告警会在GitHub发送时同步抵达，且Coroid每天会重新读取每个仓库的告警信息一次。

• 已导入，尚未确认。若Coroid自身的扫描尚未确认某条告警，该告警会显示为“从GitHub导入，尚未确认”。此类告警会被列入列表并计入统计，在Coroid的扫描确认前不会触发通知或阻断流程。
• 数据源结论不一致。当GitHub与Coroid对某条漏洞的检测结果不一致时，该漏洞条目会标注此情况，并显示各数据源对应的状态：存在、已消失、已忽略或无法读取。
• 各数据源的关闭机制各不相同。当默认分支不再包含易受攻击的版本时，Dependabot告警会在GitHub端被标记为已修复；代码扫描告警会在默认分支的分析结果不再报出该漏洞时被标记为已修复；而机密信息扫描告警需由用户在GitHub端手动解决才会关闭，因此合并修复代码并不会直接关闭此类告警。
• 权限丢失。若该应用失去相应权限，或GitHub关闭了相关功能，仅由该数据源上报的漏洞会显示为该时间点的“状态未知”，且此类漏洞不会被标记为已关闭。

在概览页面中，可按仓库和数据源查看对应告警是否已读取、是否缺少权限、GitHub是否关闭了相关功能，以及该仓库是否无法访问。