Security → Findings is the one list of everything Security found, whatever found it. Every source writes to the same store, and the same problem reported by two sources is one finding.
Findings, occurrences and sources
- A finding is one distinct problem in one repository: a vulnerable package, a leaked credential, or a vulnerable pattern in code.
- Its occurrences say where it is: a manifest and dependency path, a file and line, or the commit and path where a secret appears. Two installed versions of the same package are two occurrences.
- Its sources say who saw it, when, and how completely: OSV-Scanner, GitHub Dependabot, GitHub code scanning, GitHub secret scanning, Coroid's secret scan, Coroid's code rules, your own scan command, Coroid Review, and the security audit.
The list is grouped by project. Filter it by project, kind, severity, state, source, disclosure and evidence. A dependency finding is grouped by package, with the upgrade that fixes it when one is known.
Severity and due dates
Each finding is due a set time after it opens:
| Severity | Due within |
|---|---|
| Critical | 2 days |
| High | 7 days |
| Medium | 30 days |
| Low | 90 days |
Overview counts findings that are overdue and those due within three days.
States
| State | Means |
|---|---|
| Open | Present on the default branch. |
| Fixed in code | Every occurrence on the default branch is gone, according to a complete scan. |
| Rotation attested | A leaked credential that someone attested was rotated or revoked. See Leaked secrets. |
| No longer applies | Every advisory behind the finding was withdrawn. This is not "fixed". |
| On a pull request | Seen only on a pull request. It belongs to the pull request, and the next default-branch scan observes it if the change merges. |
No silent green
An occurrence becomes absent only when a complete scan of the current head says so. A partial scan, a failed scan, a scan without permission, or a scan of a commit the branch has since moved past changes nothing. Coverage shows each case:
- Partial: some files could not be read completely, named in the coverage.
- Stale: the inventory is not of the current default-branch head, or is more than a day old.
- Unknown since …: a source lost its permission or could not be read. Findings that only it reported show "status unknown since" that time.
- Advisory feed delayed: no project shows clean coverage while it lasts.
Results apply in the order Coroid observed the branch heads, not in the order of commit dates. If someone force-pushes a branch back to an older commit, a scan of that commit is the newest result, and a late result for a head the branch has left changes nothing.
Fixed in code and fixed where it runs
Merging a fix does not mean the fix is running. Security tracks the two separately:
- Fixed in code: the default branch no longer has the problem.
- Per environment: for each environment that reports what it runs, Coroid scans exactly that revision. The finding is fixed there only when that scan is complete and does not find it. A revert or a rollback that brings the problem back reopens the finding for that environment.
A finding's Environments show, for each environment, "Running in production", "In code only" or "Deployment unknown". Deployment unknown means Coroid has no observed revision for the environment, or no complete scan of it yet. A project without deployment tracking says "Repository posture only — no deployment revision is tracked." To track deployments, see Deployment events.
Overview → Fix progress counts what is still running in production, what is fixed in code but not deployed yet, what cannot be told yet, fix pull requests waiting for review, and the median time from detection to fix merged and to fix deployed.
Exceptions
An exception hides a finding from the open list without deleting it. Owners and admins add one on a finding:
| Kind | Needs |
|---|---|
| Accept risk | A reason, the highest severity it accepts, and an expiry date in the future. |
| Not a problem (false positive) | A reason and the highest severity it accepts. An expiry is optional. |
The finding comes back when the exception expires, when someone revokes it, or when the finding's severity rises above what the exception accepts. A severity rise voids the exception for good. Observations the exception hid are kept, and name it. Every exception is recorded in the organization's audit log.
A leaked credential is different: it closes only when someone attests that it was rotated or revoked. See Leaked secrets.
Acting on a finding
From a finding, owners and admins can:
- Fix: open the fix work for it. For a public dependency finding, a fix pull request, or a mitigation task when no fixed version exists. For a code finding, a fix task. For a leaked secret, the rotation checklist. See Fix pull requests.
- Accept risk or mark it Not a problem.
- Follow its open fix task and pull request.
Retention
Findings, their occurrences and their evidence are kept while the repository is connected. When a repository is disconnected, they are deleted after 30 days, and restored if it reconnects within them. Shared advisory data is not yours and is kept. Audit entries for exceptions, attestations and disclosures follow the audit log's retention.