发现漏洞只是第一步。安全团队的工作是让修复方案被合并并部署，因此对于存在漏洞的依赖项，Coroid会自行发起升级版pull request，再由你的团队审核并合并。
当Coroid发起一个升级版时
借助修复存在漏洞的依赖项功能开启后，严重程度达到修复标准（默认是高级别）的依赖项发现结果会在对应项目中生成一个修复任务：
- 每个软件包对应一个任务和一个pull request涵盖所有影响该软件包的安全通告。
- 优先处理严重级别的问题其次是高级别问题。
- 每个项目最多同时有5个开放的修复拉取请求默认上限为5个（最高可设为50个）。下一个修复任务需等待空余名额。
所有者和管理员也可以选择修复针对任何公开的依赖项发现结果启用该功能。若尚未发布修复版本，“修复”功能会提供缓解任务：删除或替换该软件包、锁定已打补丁的分支，或对存在漏洞的调用进行防护。
目前自动升级功能仅支持npm项目。对于其他生态系统，系统会提示“该生态系统暂不支持自动修复”，“修复”功能则会提供相应的缓解任务。
费用来源
修复任务会使用AI模型，因此会像其他工作一样消耗智能体工时。它们会在内置的安全修复指令下运行，这是每个组织都需遵守的规定：
- 范围：仅涉及依赖项升级和安全缓解措施，不涉及其他内容。
- 预算：仅消耗智能体工时，默认为你每月套餐所含智能体工时的四分之一。所有者可在“安全”→“设置”→“修复存在漏洞的依赖项”中调整工时配额，以及按周还是按月计算。
- 无审核过期限制。这是固定默认的设定，无需额外续期。
- 优先级：安全修复任务的优先级高于其他自主发起的任务。
在组织层面关闭“修复存在漏洞的依赖项”功能会暂停该指令。该指令会与其他指令一同列在Quality Control → 指令。
已关联代码库的组织开通Security服务后，所有者会收到通知：“安全修复功能将在七天后启动”。修复工作会在通知发送七天后开始，因此所有者可在首个pull request生成前关闭该功能。新组织会立即启用该功能。
为何修复任务会延迟
发现结果的修复板块会说明延迟原因。常见原因如下：
- 该项目已达pull request的开放请求上限；
- 该指令的预算或套餐所含智能体工时已耗尽（检测工作仍会继续）；
- Mission Control中的智能体工作暂停，或无可用智能体名额；
- 七天通知期尚未结束；
- 暂无兼容的修复版本，或该生态系统不支持自动修复；
- “修复存在漏洞的依赖项”功能已被关闭。
升级版本的选择逻辑
对于每个安装存在漏洞软件包的位置，Coroid会挑选高于当前安装版本、且能修复所有相关安全通告的最小版本，同时会符合声明的版本范围和主版本要求。它绝不会降级。需要不同主版本的工作区会各自获得独立的打补丁版本，这些版本都属于同一个pull request。传递性软件包会通过其父包的升级或包管理器的覆盖规则来处理。任何主版本变更或版本合并操作的原因都会标注在pull request中。若没有单一升级版本能修复所有问题，拉取请求会先修复可处理的部分，并将其余未修复问题列出。
pull request包含的内容
- 所修复的安全通告及其严重程度。
- 软件包清单变更前后的对比，可看到存在漏洞的版本已被移除。
- 项目的检查项：若项目的Delivery图表中配置了可运行的检查项，推送变更后这些检查项必须给出“继续”指令，Coroid才会发起pull request；否则任务会以相应原因终止。若项目未配置检查项，pull request仍会生成，并注明Coroid未执行项目检查，你的代码库的CI会在pull request上运行，同时会说明如何在Quality Control中配置检查项。
- 任何主版本或版本范围变更的原因。
- 无法修复的任何安全通告，会列为未修复项。
其结尾内容为：“由人员负责审核并合并代码。部署状态仅通过扫描已部署的修订版本来确定。”该发现结果会从下一次完整清单生成时开始被固化到代码中，且会根据对应环境运行的修订版本扫描结果按环境进行固化。请参阅发现结果及其生命周期。
代码类发现结果
针对代码类发现结果，修复会在对应项目中创建任务以修复该问题。所有者和管理员可针对任何未关闭的代码类发现结果使用该功能。该任务要求开发者在提交信息和pull request中说明修复方案而非攻击细节，同时需添加回归测试用例。该任务与其他任务遵循相同的规则，会占用智能体工时。
对于公开仓库，或Coroid无法确认其可见性的仓库，尚未公开的发现结果的修复内容不会直接提交至该仓库。Coroid会将准备好的变更内容私密保存，供所有者或管理员发布。请参阅披露。
泄露的机密信息
泄露的凭证需通过轮换操作来修复，此操作Coroid无法代您完成。针对机密类发现结果，修复操作会创建一个检查清单类任务。请参阅泄露的机密信息。