Understanding findings and severity
What a finding record contains, what each severity means, and how the triage lifecycle works.
Last updated · September 2026
On this page
Each finding is a structured record describing a single security concern, with a lifecycle: open, in progress, ignored, resolved, or accepted risk. Findings carry CVE identifiers and CVSS scores where advisories publish them.
Severity levels
| Level | Meaning | Examples |
|---|---|---|
| Critical | Directly exploitable with high impact. | RCE via unsafe deserialization, critical CVE with a public exploit, exposed cloud root credentials. |
| High | Exploitable under realistic conditions with significant impact. | SQL injection, high-severity dependency CVE with a fix available. |
| Medium | Requires specific conditions or has limited impact. | Verbose errors leaking internals, S3 bucket without encryption, missing rate limits. |
| Low | Best practice violations or defense-in-depth concerns. | Missing security headers, mutable image tags, informational disclosures. |
Anatomy of a finding
| Field | Type | Description |
|---|---|---|
| severity | critical | high | medium | low | Risk classification from CVSS and exploitability context. |
| cve | string | null | CVE identifier from the advisory, when published. |
| cvss | number | null | CVSS base score from the advisory, when published. |
| package | string | null | Affected package and installed version for dependency findings. |
| fixVersion | string | null | First patched version, when the advisory names one. |
| file | string | null | Relative path for code, secret, and IaC findings. |
| line | number | null | Line number where the issue begins, if identifiable. |
| status | open | in_progress | ignored | resolved | accepted_risk | Triage lifecycle state. People change it, never silently. |
Was this page helpful?