Security → Settings has the Organization default and each project on a rail. Every project follows the default until someone gives it its own setup; Use the default brings it back. Owners and admins change settings; members see them read-only.
Observe and enforce
Each protection has two separate states:
- Observe: detect, record and show. Findings appear in Security, and the
Coroid Securitycheck on pull requests reports them without failing. - Enforce: fail a check. A change that introduces a finding at or above the chosen severity fails the check, and Coroid's own tasks do not open a pull request past it.
Enforcement has three choices per scope:
| Choice | Means |
|---|---|
| Inherit (the default) | Enforce once the protection's platform readiness gate has passed. |
| Enforce | The same, chosen explicitly for this scope. |
| Observe only | Never fail a check, whatever the platform does. |
Every protection starts in observe. Coroid switches on enforcement per protection only after that protection has passed its readiness gate: for dependencies, the coverage tests and an observation period with no wrong blocks; for secret and code rules, the calibration described below and the same observation period. Until then, a protection set to Inherit or Enforce observes, and the setting says so. Once the gate passes, everyone who left Inherit gets enforcement; anyone who chose Observe only keeps observing.
Enforce is not the same as "GitHub prevents merging". GitHub blocks a merge
only where the repository requires the Coroid Security check. See
GitHub permissions and the Coroid Security check.
Calibrated rules
Leaked secrets and code scanning enforce only with detector versions that passed calibration: measured precision and recall on a labelled set of real code and synthetic secrets, a false-block rate measured by replaying real merged changes, every reported mistake kept as a case that must keep passing, and 14 days of observation without a wrong block.
A new detector version never takes over enforcement on its own. The last approved version keeps enforcing while the new one observes beside it, and the new one takes over only once its own calibration passes. If no approved version can run, an enforced protection reports itself unavailable and its check fails, rather than passing unchecked.
The settings
| Protection | Switch | Adjust |
|---|---|---|
| Vulnerable dependencies | Observe | Enforcement; "Enforce at or above" (default high) |
| Fix vulnerable dependencies | On or off | "Open fix work at or above" (default high); open fix pull request limit per project (default 5, up to 50); the agent-hour budget, on the organization default |
| Leaked secrets | Observe | Enforcement. On the organization default only: block new secrets, and the largest change scanned |
| Code scanning | Observe | Enforcement; your own scan command; the list of rules |
| Security review on pull requests | Observe | Enforcement; "Enforce at or above" (default high) |
| GitHub security alerts | Observe | None |
| Security audit | On or off | How often: daily, weekly (default) or monthly |
Some protections depend on something else:
- Security review on pull requests needs Coroid Review on for the project in Quality Control. With Coroid Review off, the row says so and the protection does nothing.
- Fix vulnerable dependencies on the organization default also switches the built-in Security fixes mandate on and off. See Fix pull requests.
- Security audit follows your plan unless you switch it: on for paid plans, off on Free. See Security audit.
Security runs whatever Quality Control says
Security's protections do not depend on Quality Control's controls. Switching
anti-slop off in Quality Control turns off its quality rules, not Security's
code rules. On pull requests, Coroid Security posts its own check, whether or
not the project has a published Delivery graph.
Scanner configuration comes from Coroid
Scanners run with configuration Coroid builds from these settings and the
exceptions accepted in Security, never from files in the change under test. A
change that adds or edits scanner configuration (osv-scanner.toml,
.gitleaks.toml, .gitleaksignore, .github/secret_scanning.yml,
.secrets.baseline and similar) is checked under the base commit's
configuration and gets a security.policy-changed finding. A repository file
can propose an exception; it applies only once an owner or admin accepts it in
Security. The same rule binds Coroid's own fix tasks: an agent cannot make its
own check pass by changing what is excluded.
Settings travel with the organization
The security settings are part of the organization settings bundle, with the
other quality policies, and so is each project's latest threat model.
Exceptions, findings and evidence are results, not settings, and do not travel.
See Settings portability.