发现结果及其生命周期

“安全”→“发现结果”是“安全”模块识别到的所有问题的统一列表，无论由何种工具发现。所有数据源都会写入同一存储，两个数据源上报的同一问题会被归为一条发现结果。

发现结果、出现位置与数据源#

• 一个发现结果指的是某个代码库中的一类特定问题：存在漏洞的软件包、泄露的凭证，或是代码中的脆弱模式。
• 其出现位置指明了该发现结果的具体位置：依赖清单与依赖路径、文件及行号，或是机密信息出现的提交及路径。同一软件包的两种安装版本会被视为两个出现位置。
• 其数据源说明了识别到该发现结果的工具、时间及完整度：OSV-Scanner、GitHub Dependabot、GitHub 代码扫描、GitHub 机密扫描、Coroid 的机密扫描、Coroid 的代码规则检查、自定义扫描命令、Coroid 审核，以及安全审计。

该列表按项目分组。可按项目、类型、严重程度、状态、数据源、披露情况及证据进行筛选。依赖类发现结果会按软件包分组，若已知修复该问题的升级版本则会一并展示。

严重程度与截止日期#

每条发现结果在开启后会在指定时间内被处理：

“概览”页面会统计已超期的发现结果，以及未来三天内需处理的发现结果。

状态#

无静默修复#

只有当完整的当前分支头部的扫描结果如此判定时，该出现位置才会被标记为不存在。部分扫描、扫描失败、无权限扫描，或是扫描对象为分支已跳过的历史提交，均不会改变这一判定。覆盖情况会分别展示每种情形：

• 部分：部分文件无法被完整读取，相关信息会记录在覆盖情况中。
• 过时：清单数据并非来自当前默认分支头部，或数据生成时间超过一天。
• 自…起状态未知：数据源失去权限或无法读取。仅由该数据源上报的发现结果会显示“自此时起状态未知”。
• Advisory 源数据延迟：在此期间没有项目能展示完整的覆盖情况。

结果会按照 Coroid 识别分支头部的顺序展示，而非提交日期顺序。若有人对分支执行强制推送，使其回退到旧提交，那么该提交的扫描结果会成为最新结果；若分支已跳过该提交，后续产生的旧结果不会改变现有状态。

代码中修复与运行环境中修复#

合并修复代码并不意味着该修复已在运行环境中生效。“安全”模块会分别跟踪这两种情况：

• 代码中已修复：默认分支中已不存在该问题。
• 按环境区分：对于每个报告其运行内容的环境，Coroid 都会扫描该环境对应的确切修订版本。只有扫描完成且未发现该问题时，才会判定该环境中的发现结果已修复。若还原或回滚导致问题再次出现，该环境中的发现结果会重新开启。

某条发现结果的环境Coroid 会针对每个环境显示“正在生产环境运行”、“仅存在于代码中”或“部署情况未知”。“部署情况未知”表示尚未观测到该环境对应的修订版本，或尚未完成对该环境的扫描。未启用部署追踪的项目会显示“仅仓库状态 — 未追踪部署修订版本”。如需了解部署追踪功能，详见部署事件。

概览 → 修复进度统计了仍在生产环境中运行的问题、代码中已修复但尚未部署的问题、暂时无法确定的问题、等待审核的修复拉取请求，以及从问题被发现到修复合并、再到修复部署的中间时间中位数。

例外情况#

例外情况会将某个发现结果从公开列表中隐藏，但不会将其删除。所有者和管理员可为某个发现结果添加例外：

一旦例外情况过期、被他人撤销，或者发现结果的严重程度超出该例外情况所允许的范围，该发现结果就会重新出现。严重程度的提升会永久使该例外情况失效。例外情况隐藏的观察结果会被保留，并为其命名。每条例外情况都会记录在组织的审计日志中。

泄露的凭证情况有所不同：只有当有人证实该凭证已被轮换或撤销时，才会关闭相关记录。详见泄露的机密信息。

针对发现结果的操作#

针对某个发现结果，所有者和管理员可以执行以下操作：

• 修复：打开对应的修复任务。若是公共依赖项相关发现结果，则生成修复拉取请求；若不存在固定版本，则创建缓解任务。若是代码类发现结果，则创建修复任务。若是泄露的机密信息，则启动轮换检查流程。详见 修复拉取请求。
• 接受风险或将其标记为并非问题。
• 跟进其未完成的修复任务以及pull request。

留存规则#

只要代码仓库保持连接状态，发现结果、其相关实例及证据就会被留存。若代码仓库断开连接，相关数据会在30天后被删除；若在此期间重新连接，则会恢复。共享的 advisory 数据不属于用户所有，会被继续留存。例外情况、 attestation 记录和披露记录的审计条目会遵循审计日志的留存规则。