在“安全→设置”中可找到组织默认值以及每个项目对应的配置。 所有项目均遵循该默认值，除非人为为其单独设置；使用默认值即可恢复默认设置。所有者和管理员可修改设置，普通成员仅能查看只读内容。
Observe与Enforce
每种防护都有两个独立状态：
- Observe：用于检测、记录并显示相关结果。发现结果会呈现在“安全”板块中，
Coroid SecurityPull Request的审核检查会报告这些结果但不会导致检查失败。 - Enforce：会导致检查失败。若变更引入的发现问题严重程度达到设定阈值，检查便会失败，且Coroid自身的任务也无法在此基础上创建Pull Request。
针对不同作用域，强制执行有三种可选配置：
| 选项 | 含义 |
|---|---|
| 继承（默认设置） | 待该防护对应的平台就绪门限通过后即强制执行。 |
| 强制执行 | 为该作用域明确选择的强制执行规则。 |
| 仅Observe | 无论平台状态如何，绝不导致检查失败。 |
所有防护初始均为Observe状态。仅当防护通过就绪门限后，Coroid才会针对该防护开启强制执行：对于依赖项，需通过覆盖率测试且经过无错误拦截的观察期；对于机密信息和代码规则，需满足下述校准要求及同样的观察期。在此之前，设置为继承或强制执行的防护仅会处于Observe状态，设置界面也会如实显示。门限通过后，原先选择继承的选项会自动启用强制执行；而选择仅Observe的选项则仍保持观察状态。
强制执行并不等同于“GitHub阻止合并”。仅当代码仓库要求执行Coroid Security检查。请参阅GitHub权限与Coroid安全检查。
已校准的规则
机密信息泄露检测和代码扫描功能仅在检测器版本通过校准后才可强制执行：校准指标包括在真实代码和合成机密数据集合上的精确度和召回率、通过重放已合并变更测得的误拦截率、所有上报的错误均会被列为需持续通过的案例，以及14天无错误拦截的观察期。
新版本的检测器不会自动接管强制执行功能。上一获批版本会继续强制执行，同时新版本会在旁侧进行观察，仅当新版本通过自身校准后才会接替旧版本。若没有获批版本可运行，已强制执行的防护会标记为不可用，其检查也会失败，而非未经校验便通过。
相关设置
| 防护 | 开关 | 调整 |
|---|---|---|
| 易受攻击的依赖项 | Observe | 强制执行；“严重程度不低于”阈值（默认为高） |
| 修复易受攻击的依赖项 | 开启或关闭 | “严重程度不低于时开启修复任务”（默认为高）；各项目的pull request修复任务上限（默认5个，最多50个）；代理工时预算，遵循组织默认值 |
| 机密信息泄露 | Observe | 强制执行。仅组织默认值下生效：拦截新出现的机密信息，以及最大规模的扫描变更。 |
| 代码扫描 | Observe | 强制执行；用户自定义的扫描命令；规则列表 |
| Pull Request的安全审核 | Observe | 强制执行；“严重程度不低于”阈值（默认为高） |
| GitHub安全警报 | Observe | 无 |
| 安全审计 | 开启或关闭 | 执行频率：每日、每周（默认）或每月 |
部分防护依赖其他功能：
- Pull Request的安全审核需该项目在“Quality Control”中开启Coroid审核功能。若Coroid审核功能关闭，对应行会注明此情况，且该防护不会生效。
- 修复易受攻击的依赖项组织默认值下的该功能也会同步切换内置安全修复指令的开启与关闭状态。详情请参阅 修复Pull Request。
- 安全审计该功能遵循您的计划设置，除非您手动更改：付费套餐默认开启，免费套餐默认关闭。详情请参阅安全审计。
安全功能的运行遵循“Quality Control”的设置。
安全模块的保护机制不依赖于Quality Control模块的控制规则。在Quality Control中关闭反冗余检测功能只会停用其质量规则，并不会影响安全模块的代码规则。在拉取请求中，Coroid Security无论项目是否发布了已发布的Delivery图，都会自行提交检查。
扫描器配置来源于Coroid。
扫描器运行时采用的配置由Coroid根据这些设置和在安全模块中接受的例外规则生成，绝不会取自待测试变更中的文件。若变更涉及添加或编辑扫描器配置（osv-scanner.toml、.gitleaks.toml、.gitleaksignore、.github/secret_scanning.yml、.secrets.baseline及类似内容）会基于基础提交的配置进行检查，并生成相应的security.policy-changed检测结果。仓库文件可以提出例外申请；该申请只有在所有者或管理员在安全模块中批准后才会生效。同一规则也适用于Coroid自身的修复任务：智能体无法通过修改排除项来使其自身的检查通过。
设置会随组织一同迁移。
这些security设置属于组织设置包的一部分，与其他质量策略以及每个项目的最新威胁模型一同存储。例外情况、检测结果和证据属于运行结果而非设置，不会随组织迁移。详见设置可移植性。