一旦凭据被提交到推送的提交中，即便后续提交将其删除，该凭据也已然泄露。安全功能会在你的变更和历史记录中识别凭据，不会留存任何凭据内容，且每条泄露的凭据都会被视为未处理状态，直至有人确认其已被轮换或吊销。
扫描范围
- 所有变更：即每个pull request的变更，作为
Coroid Security检查的一部分，以及Coroid自身代理在提交前的变更。 - 默认分支：每次推送时都会扫描，也会扫描其完整历史记录。历史记录扫描在代码库关联或开启泄露的机密信息功能时启动。
- 拉取请求分支：若凭据被推送到pull request分支，也会触发一条发现记录，因为该凭据已然存在于代码库中。
未关联pull request的分支不会被扫描。
历史记录扫描会按从新到旧的顺序读取所有可访问的提交，且每个文件版本仅读取一次。扫描以切片方式运行，可从上次中断处继续。每个代码库对可读取的历史记录量（提交数、字节数、时间、文件大小）均有限制；超出限制的代码库只会显示部分扫描结果。
可识别的内容
符合已知格式的供应商凭据（AWS访问密钥、GitHub和GitLab令牌、OpenAI密钥等）、授权令牌、分配给特定名称的凭据，例如password或api_key、私钥、URL内的凭据以及高熵值的长字符串。代码中分配的凭据仅在值为字面量时才会被匹配，变量或函数调用的情况除外。
Coroid绝不会留存凭据值。
检测到的凭据值会直接从检测器传输至Coroid的凭据代理，代理会返回带键的指纹并丢弃该值。仅存储指纹信息。指纹按组织维度加密，因此无法跨组织比对或在离线状态下猜测。
在原本会显示机密信息的所有位置（发现记录、检查项、审核评论、日志）中，Coroid仅会显示规则、长度和位置，例如[redacted secret: named_credential, 40 characters]。不会显示该值的任何部分，甚至包括首字符。
Coroid绝不会尝试使用检测到的凭据验证其有效性。
一个凭据，一条发现记录
多个提交中出现的同一凭据只会生成一条包含多条记录的发现记录。两个代码库中的同一凭据会生成两条发现记录，每个代码库各一条。当你确认其中一条后，安全功能会列出具有相同凭据的其他记录，方便你一并确认。系统不会主动执行此操作。
只有经确认后，泄露的机密信息才会被关闭
从代码中删除凭据后，相关记录会消失，但发现记录仍会保持开放状态：此前读取过该代码库的人员可能已获取到该凭据。只有所有者或管理员确认已采取相应措施后，记录才会关闭：
- 已轮换或已吊销；
- 操作日期；
- 可选的备注。
安全功能会记录确认人和确认时间，并在发现记录中展示：“10月28日轮换，10月29日由Alex确认”。随后发现记录会移至轮换已确认。
修复泄露的机密信息
创建检查清单任务会在项目中创建包含以下步骤的任务：
- 在其供应商端轮换或吊销该凭据。
- 将其移动至项目存放机密信息的位置。
- 从代码中删除该凭据。
- 在安全功能中确认已完成轮换。
该任务不会重复执行或尝试使用该凭据。它不会重写Git历史记录：是否从历史记录中删除凭据由你的团队决定，且此举并不会让泄露的凭据重新变得安全。
真实凭据或无需处理
针对泄露的机密信息发现记录，所有者和管理员需回答这是真实的凭据吗？
- 真实凭据会保持发现记录开放，直至确认处理完毕。
- 无需处理会记录误报例外情况，从而隐藏该发现记录，例如测试用伪数据的情况。真实凭据会移除该例外情况。
这些回答也有助于校准检测器。
拦截机制
泄露的机密信息功能默认处于观察模式。只有当检测器完成校准且启用强制拦截功能后，才会实施拦截。详见防护与强制拦截。
在组织机构策略中提前开启机密扫描功能的组织机构，会持续被该扫描功能及其检测器版本拦截，直到新检测器完成校准。由于早期的扫描不会生成发现结果，因此即便设置例外规则或出具 attestation 也无法绕过其拦截机制。
在组织机构默认设置中，拦截新机密信息以及扫描出的最大变更内容会被归类到“泄露的机密信息”项下。
通知
机密类发现结果暂不会触发通知，它们会显示在“安全”→“发现结果”页面和“概览”页面中。
GitHub 机密扫描
如果某个代码仓库开启了 GitHub 自带的机密扫描功能，安全模块便可导入其相关告警。GitHub 机密扫描生成的告警会一直保持开放状态，直至有人在 GitHub 端解决该问题，因此合并修复补丁并不会关闭该告警。详见GitHub 安全告警。