易受攻击的依赖项

Security会盘点每个项目安装的所有软件包，并将其与已发布的安全公告匹配；因此当易受攻击的版本出现在pull request中时就能被识别，当新安全公告提及你已在运行的版本时也能被识别。

盘点结果#

在默认分支的每个新头部提交时，以及每天至少一次，Coroid会使用以下工具读取项目的锁文件：OSV-Scanner，该工具会被固定到特定版本，并会校验其发布的校验和。扫描器仅获取依赖项文件、Coroid生成的配置文件，无需网络访问权限或凭证。代码库的自身设置对该扫描器毫无影响。osv-scanner.toml没有 任何影响。

在“安全→依赖项”页面可查看每个项目的盘点结果：包括软件包及其安装版本、声明各软件包的清单文件、哪些存在漏洞、每个文件的覆盖情况，以及上次读取安全公告数据的时间。导出CycloneDX可将盘点结果下载为CycloneDX 1.5格式的文件。该文件仅列出已公开的检测结果。详见披露。

Coroid完整读取的内容#

覆盖范围是按锁文件划分的，而非按代码库划分。在单体代码库中，每个锁文件属于独立的组，拥有独立的覆盖范围；因此即使某个清单文件不完整，完整锁文件的结果依然有效。

该表格是根据Coroid自身测试中通过扫描器运行的结果生成的，因此仅当测试内容变更时才会更新。

• npm工作区、pnpm和Yarn：工作区的package.json若无自身的锁文件，则由根锁文件覆盖。若某文件与锁文件不再匹配，则在该锁文件重新生成前属于部分覆盖。package.jsonnpm锁文件
• 必须是2或3版本。源自Git、本地文件或补丁的pnpm和Yarn条目属于部分覆盖。仅覆盖用以下方式固定的版本：
• requirements.txt仅涵盖使用==。
• 其他依赖项文件 (package.json若无锁文件， pyproject.toml、poetry.lock、Pipfile、Cargo.lock、Gemfile.lock、 pom.xml、Gradle、Composer、NuGet等其他格式的文件会被识别并显示为部分覆盖，同时会注明对应文件名，因此若项目未完全覆盖则不会显示为已覆盖。

安全公告#

Coroid会从以下来源读取安全公告：OSV，该平台也收录了GitHub的安全公告，涵盖项目使用的所有生态系统。它每小时会读取自上次读取后新增或变更的内容，每天则会读取全部内容。匹配过程会使用已存储的盘点结果，因此无需访问你的代码库。

Coroid的目标是：在安全公告数据发布后60分钟内，将95%的新安全公告与所有盘点结果匹配，同时会记录每次匹配耗时。它无法保证从漏洞首次披露到匹配完成的时间：这取决于安全公告的发布时间。

若安全公告数据延迟超过90分钟，或上次读取失败，“概览”和“依赖项”页面会显示“安全公告源延迟至……”，在此期间任何项目的覆盖情况都不会显示为完整。

若某安全公告被撤回，Coroid会重新计算剩余安全公告中对同一漏洞仍适用的内容。只有当没有适用内容时，检测结果才会标记为“不再适用”，绝不会标记为已修复。

在拉取请求中#

该Coroid Security检查会扫描pull request更改的锁文件，包括其基准版本和头部版本，仅统计此次更改引入的易受攻击版本：

• 观察：检查会通过，或报告中性结果并说明发现的内容。
• 强制执行：若变更引入了所选严重程度（默认是高级别）及以上的已知漏洞版本，则该检查会判定为不通过。如果变更所涉及的锁文件覆盖不完整，同样会判定为不通过，系统会说明原因及重新运行的方法。

该检查也会在Coroid自身的修复和特性拉取请求提交前执行。关于该检查的运行规则、如何启用相关要求以及重新运行的方法，请参阅GitHub权限与Coroid安全检查。

通知#

代码仓库的首份完整依赖清单会作为静默基线：相关检测结果会显示在“安全”模块中，不会发送通知。此后，一旦检测到新的关键依赖漏洞，系统会向组织所有者和管理员发送一次通知，开启邮件提醒时会通过邮件发送，Slack已接入的话会通过Slack发送。如果是公开的安全公告，通知中会注明对应的软件包和公告内容；尚未公开的内容则只会提示有关键漏洞需要处理。详见披露。