Two protections look at code itself: Code scanning runs fixed rules on every change and on the default branch, and Security review on pull requests checks the security issues Coroid Review raises before any of them can fail a pull request.
Code scanning
Coroid's rules
Security owns these rules. They were part of anti-slop in Quality Control and now live here, so each has one home:
| Rule | Looks for |
|---|---|
security.hardcoded-secret | Credentials written into code. See Leaked secrets. |
security.tls-disabled | TLS certificate verification turned off. |
security.auth-removed | Authentication or permission guards, decorators or middleware removed or commented out. |
security.cors-wildcard-credentials | Any origin allowed together with credentials. |
security.sql-concat | SQL built from interpolated strings and passed to a query function. |
security.eval | Code run from input: eval, new Function, unsanitized dangerouslySetInnerHTML. |
security.remote-script-exec | Downloaded scripts piped straight into a shell or interpreter. |
security.policy-changed | Changes to scanner configuration. See Protections and enforcement. |
deps.nonexistent | New dependencies that do not exist in their registry. |
deps.known-malicious | New dependencies with a malicious-package advisory. |
deps.suspicious-new | New dependencies first published less than 30 days ago, with very few downloads, named one or two letters away from a popular package, or with a recent change of maintainer. |
deps.install-script | New npm dependencies that run a script when installed. |
The dependency hygiene rules, unpinned versions and manifest and lockfile drift, stay in Quality Control with anti-slop. See Anti-slop.
The rules run on changes, in the same scan as Quality Control's anti-slop check, and on the default branch at each push and once a day, whether or not anti-slop is on. Security, not anti-slop's settings, decides what each rule does. Security → Settings → Code scanning lists them. Until code scanning enforces, each rule keeps the action it had in Quality Control, so a rule you had set to block keeps blocking.
Your own scan command
If your project already has a security scanner, enter its command under
Your own scan command in Code scanning. It runs as the project's
security_scan check on each change. Leave it empty to turn it off.
Results from external tools such as SonarQube, Snyk or Semgrep can also reach Coroid as review evidence. See Review evidence providers.
Security review on pull requests
Coroid Review reviews pull requests in Quality Control. When it sees a security issue, it does not write it into its review as prose. It reports the issue as a structured claim: the kind of vulnerability, the file and lines, and the severity. Security records each claim as Not confirmed yet.
The independent check
For critical and high claims, Coroid runs an independent check: a separate, bounded model run that sees the file the claim names, at the pull request's head commit, and has to re-derive the issue itself. If it does, the claim becomes a validated static finding. If the code that decides the issue is in another file, the check cannot confirm it, and the claim stays not confirmed.
The check spends your organization's credits like other model work, within fixed limits per pull request. When credits or hours are spent, it does not run, and the review says "A possible security issue could not be verified: the organization's credits or hours are spent."
What fails the review
| Observe | Enforce | |
|---|---|---|
| A confirmed claim at or above the threshold (high by default) | Neutral, "FINDING CONFIRMED" | The Coroid Review check fails, "FINDING CONFIRMED" |
| A claim that is not confirmed | Never fails | Never fails |
An enforced, confirmed critical or high claim fails Coroid Review even when the review is set to advisory in Quality Control. This is the one exception to advisory reviews never failing. A review that asks for changes only because of security claims that are not confirmed counts as advisory.
Security review needs Coroid Review on for the project. With Coroid Review off, its row in Security → Settings says so.
What reaches GitHub
Before any review text, comment or check reaches GitHub, it passes the publication gate. On a public repository, or one whose visibility Coroid cannot confirm, a security issue that is not public is replaced by "Coroid found a possible security issue; details are in Coroid", with a link. See Disclosure.