Security keeps an inventory of every package each project installs and matches it against published advisories, so a vulnerable version is found when it arrives in a pull request, and again when a new advisory names a version you already run.
The inventory
At each new head of the default branch, and at least once a day, Coroid reads
the project's lockfiles with OSV-Scanner,
pinned to one version and checked against its published checksum. The scanner
gets only the dependency files, a configuration Coroid generates, and no
network access or credentials. A repository's own osv-scanner.toml has no
effect.
Security → Dependencies shows each project's inventory: the packages and their installed versions, which manifest declares each one, which are vulnerable, the coverage of each file, and when the advisory data was last read. Export CycloneDX downloads the inventory as a CycloneDX 1.5 file. It lists vulnerabilities only for findings that are already public. See Disclosure.
What Coroid reads completely
Coverage is per lockfile, not per repository. In a monorepo, each lockfile is its own group with its own coverage, so a complete lockfile's results stand even when another manifest is partial.
| File | Ecosystem | Exact versions | Complete transitive dependencies | Coverage |
|---|---|---|---|---|
package-lock.json | npm | Yes | Yes | Complete |
npm-shrinkwrap.json | npm | Yes | Yes | Complete |
pnpm-lock.yaml | npm | Yes | Yes | Complete |
yarn.lock | npm | Yes | Yes | Complete |
requirements.txt | PyPI | Yes | No | Partial |
go.mod | Go | Yes | No | Partial |
This table is generated from the fixtures Coroid's own tests run through the scanner, so it changes only when the tests do.
- npm workspaces, pnpm and Yarn: a workspace's
package.jsonwithout its own lockfile is covered by the root lockfile. Apackage.jsonthat no longer matches its lockfile is partial until the lockfile is regenerated. - npm lockfiles must be version 2 or 3. pnpm and Yarn entries that come from git, a local file or a patch are partial.
requirements.txtcovers only versions pinned with==.- Other dependency files (
package.jsonwithout a lockfile,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet and others) are found and shown as partial, naming the file, so a project never reads as covered when it is not.
Advisories
Coroid reads advisories from OSV, which also carries GitHub's advisories, for each ecosystem your projects use. Every hour it reads what is new or changed since the last read, and once a day it reads everything. Matching uses the stored inventories, so it needs no access to your repository.
Coroid's target is to match 95% of new advisories against every inventory within 60 minutes of their appearing in the advisory data it reads, and it measures how long each match took. It cannot promise a time from a vulnerability's original disclosure: that depends on when an advisory is published.
If the advisory data is more than 90 minutes behind, or its last read failed, Overview and Dependencies show "Advisory feed delayed since …", and no project's coverage reads as complete while it lasts.
When an advisory is withdrawn, Coroid recomputes what still applies from the remaining advisories for the same vulnerability. A finding closes as "No longer applies" only when none does, never as fixed.
On pull requests
The Coroid Security check scans the lockfiles a pull request changes, at its
base and at its head, and counts only the vulnerable versions the change
introduces:
- Observe: the check passes, or reports neutral naming what it found.
- Enforce: a change that introduces a known-vulnerable version at or above the chosen severity (high by default) fails the check. Partial coverage of a lockfile the change touches fails it too, saying why and how to re-run.
The same check runs on Coroid's own fix and feature pull requests before they are opened. For how the check behaves, how to require it and how to re-run it, see GitHub permissions and the Coroid Security check.
Notifications
A repository's first complete inventory is a silent baseline: its findings appear in Security and nobody is notified. After that, a new critical dependency finding notifies the organization's owners and admins once, in the bell, by email when email is on, and in Slack when Slack is connected. For a public advisory the bell names the package and the advisory; for anything not yet public it says only that a critical finding needs attention. See Disclosure.