在漏洞修复完成前就披露其详情，对攻击者而言益处大于对防御者的益处。安全功能会将所有非公开的漏洞发现详情留存于Coroid内，仅由具备权限的人员决定何时将其公开。
公开与非公开
每种漏洞发现分为两类：
- 公开：此类漏洞已被公开披露，例如已发布相关公告的依赖项。修复拉取请求中可能会注明该公告信息。
- 非公开：其余情况均属此类，比如审计、Coroid审核或代码规则在用户代码中发现的隐患，或是泄露的凭证。
只有当漏洞发现关联到未撤销的已发布公告，或由所有者或管理员发布了其私有修复版本时，该发现才属于公开类别（详见下文）。
发布管控机制
Coroid在Coroid外发布的所有内容均需先通过发布管控机制：审核机构、行内审核评论及摘要、检查结果及其注释、pull request标题和描述、提交信息、议题评论、Slack消息和电子邮件，以及导出文件。该机制会检查文本中的任何安全问题，无论是否已确认。
对于公开仓库，或Coroid无法确认其可见性的仓库，非公开的隐患会被替换为带有链接的中性语句：
Coroid发现了潜在的安全隐患；详情请查看Coroid。
对于私有仓库，相关内容会被直接发布。尚未确认的隐患会标记为“未经验证的安全声明：Coroid尚未验证该隐患”。
无论何处，凭证都会始终被脱敏处理。详见泄露的机密信息。
仓库可见性
Coroid仅在近期从GitHub的事件中获取到明确的私有仓库判定结果，或直接向GitHub查询得到结果且时间不超过一小时时，才会将该仓库视为私有仓库。内部仓库被视为公开仓库。若Coroid无法判定，则将该仓库视为公开仓库。
通知与导出
- 铃铛图标：对于非公开的漏洞发现，铃铛图标仅标注危害等级和项目名称，例如“某关键隐患需及时处理”，并附带指向安全模块中该隐患页面的链接。
- Slack与电子邮件仅会显示“某隐患需及时处理”这一行提示及对应链接，不会包含漏洞详情或代码内容。
- 导出文件：CycloneDX导出文件仅列出公开类的漏洞发现。组织设置包中则不包含任何漏洞发现信息。
在公开仓库中修复隐患
在私有仓库中，针对非公开隐患的修复属于常规的pull request操作。其提交信息和描述会说明修复内容，而非隐患本身。
在公开仓库，或Coroid无法确认其可见性的仓库中，公开的pull request、分支或提交操作会在修复完成前暴露隐患。因此Coroid根本不会在此类仓库中提交此类修复。修复任务会因未提及隐患细节的原因而终止，已准备好的变更会被保存为私有修复版本。
私有修复版本
带有私有修复版本的隐患会显示在私有修复版本栏目下。仅所有者和管理员可查看。
- 下载修复版本会将已准备好的变更保存为
.patch文件，供用户自行审核或应用。 - 发布会记录该隐患现已披露的信息，并创建任务以直接应用已准备好的变更，同时开启对应的pull request。当您准备好发布修复版本及隐患信息时即可点击发布，例如在协调好的发布日期到来时。若修复内容过大无法通过Coroid发布，仍可手动下载并应用。
- 丢弃会删除已准备好的变更。
发布和丢弃操作均会记录在组织的审计日志中，且两者都会从Coroid中删除已准备好的变更。
无人发布或丢弃的私有修复版本会被保留有限的时间。180天后会提醒所有者和管理员，365天后该修复版本会被删除并通知相关人员。
已规划
- 各项目的安全联系人可与所有者和管理员共同审核并发布私有修复版本。
- GitHub私有分支：在GitHub仓库安全公告的私有分支中准备修复版本及回归测试，而非将其留存于Coroid中。
- 给维护者的报告：当依赖项代码中存在漏洞时，会为其维护者起草一份私密报告，该报告仅由人工发送。