Understand results and scores
Scores help you order your work. When deciding what to do, always consider the observed version, signal source, and repository context alongside the score.
Verified on September 13, 2026 against ecbd364. Guide home.
Finding, update, and PR: three different objects
Section titled “Finding, update, and PR: three different objects”A finding links an observed dependency to a vulnerability advisory. Its identifier may be a CVE or an identifier from another source; Aliases help you find other identifiers for the same advisory.
An update proposes moving from one version to another. It may address several findings or represent a version update with no associated finding. The absence of an update does not make a finding disappear.
A PR proposes a change in your repository. Opening it, merging it, and the finding disappearing are three steps to verify separately.
Docker base images
Section titled “Docker base images”Support-date display verified by automated rendered-output tests for issue #591 on October 4, 2026. This does not imply deployment on your instance.
On instances containing the base-image support update, Base images in a repository or application shows Dockerfile references, file/line/stage, and endoflife.date support evidence. An ARG default is a scanned value that CI can override. These checks do not inspect image packages or find image CVEs, and they do not change vulnerability risk scores.
The repository panel appears below the findings summary, before Stack & manifests and Recent scans. Each image shows its reference without the digest, branch, severity when relevant, and security-support dates for its recognized cycles. Open Details to see the complete reference, including its digest, Dockerfile locations, stages, ARG caveats, checks and source links. Unknown and stale support information remains visible while these details are closed.
- High: reference security support has ended. Base image priorities in the update queue groups affected uses by product and release cycle, such as Debian 11. Expand it to see images, repositories, refs and locations: Python and Node images based on Bullseye share the Debian 11 entry.
- Medium: active support ended while reference security support remains,
or security support ends within 180 UTC calendar days, inclusive. A moving
latesttag is also medium. These signals stay on repository/application pages. - Low: a floating version or release alias without a digest.
- Info: no SHA-256 digest or EOL not verified. Missing a digest does not increase priority or alert counts; its explanation remains in the detail.
The same support verification is available on all plans. Application pages retain their existing plan requirements. Unknown private images, cycles or distribution versions remain unverified; a runtime’s support date does not prove that every package in its image is maintained. Debian uses the LTS end; Ubuntu uses reference Maintenance & Security Support. Commercial ELTS and ESM / Ubuntu Pro coverage is not presumed.
Each recognized cycle links to its source and shows the product and version cycle. Security support ends YYYY-MM-DD is the security-support end date for that cycle, not the date the evidence was retrieved. If no such date is available, it shows Security support end date unknown; an active-support end date is not substituted.
If support information cannot be refreshed, earlier evidence keeps its known support end date and is marked stale. Without usable evidence, the page says EOL not verified. Run a scan to refresh this information; opening the page does not refresh it. An unavailable support source does not prevent the vulnerability check from completing.
This section describes the base-image update; it does not assert that your instance has deployed it. Other score descriptions retain their verification reference above.
What the indicators mean
Section titled “What the indicators mean”| Display | Meaning | Key limitation |
|---|---|---|
Severity (critical, high, medium, low, info) |
Category representing severity | It does not determine the final queue order on its own |
| CVSS | Technical severity score out of 10 | The displayed value is not always an official value extracted from the advisory |
| EPSS | Estimated probability of a CVE being exploited in the next 30 days, displayed as a percentage | It is not the probability that your own system will be compromised |
| CISA KEV | Indicates inclusion in the catalog of vulnerabilities known to be exploited | No badge does not guarantee no exploitation |
| Public exploit | Exploitation signal available in the data | This signal comes from KEV, not from an independent inventory of all public exploits |
| Reachability | Signal about whether vulnerable code can be reached | unknown means this has not been established |
| Risk score | Composite score out of 100; a higher number increases the base priority | It is neither a percentage of real-world risk nor a certification |
| Effective priority, AI badge | Priority used after a priority adjustment | A recommendation still requires human review |
General definitions of CVSS and EPSS are published by FIRST. The KEV catalog is maintained by CISA.
Provenance, freshness, and missing data
Section titled “Provenance, freshness, and missing data”Vulnerability advisories include EPSS and KEV when available. Opening a details page does not immediately refresh every signal. Check the scan date and source advisory before acting; the scan date is not the advisory’s publication date.
If a source is unavailable, earlier values may be retained. Without a usable value, EPSS may remain zero and KEV false. That stored false is not a verified absence: triage Ignore still requires a successful KEV catalog lookup. EPSS is also rounded to a whole percentage on the finding details page: a small positive value may appear as 0%. Do not interpret this display as “no possibility of exploitation.” The source or retrieval date may not be shown for every value. Check the source advisory when you need to verify a value.
A displayed CVSS value of 7.0 can be a default rather than the CVE’s official score. Severity is a separate indicator. Verify the source advisory before reporting a displayed CVSS score as official.
Reachability remains unknown by default in the current scan. A direct
dependency does not prove that vulnerable code is called. reachable and
unreachable require an explicit signal; example data in documentation is not an analysis of your
application.
Finally, Fixed version: — means the details page has no usable fixed version to display. It proves neither that no fix exists nor that any newer version fixes the issue. First seen is the first recorded observation, not the CVE’s publication date.
How the base score is calculated
Section titled “How the base score is calculated”The risk score is the sum of the contributions below, rounded to an integer and
clamped between 0 and 100. Each contribution is weight × factor value.
The Risk breakdown section helps explain this calculation.
| Factor | Weight | Factor value out of 100 in the current calculation |
|---|---|---|
| Base severity | 35% | Critical 95; high 75; medium 55; low 30; info 10 |
| EPSS | 20% | Probability between 0 and 1, scaled to 100 and rounded |
| KEV / public exploit | 15% | KEV 100; otherwise public exploit 85; otherwise 10 |
| Reachability | 15% | Reachable 90; unknown 75; unreachable 20 |
| Direct dependency | 5% | Direct 100; transitive 20 |
| Blast radius | 5% | Supplied value, or 60 by default |
| Update lag | 5% | Fix age / 90 days × 100, rounded and capped at 100; default age of 14 days |
A direct dependency is declared by the project; a transitive dependency is brought in by another dependency. Unknown reachability deliberately keeps a high contribution: uncertainty should not make risk appear negligible.
The current finding scoring flow uses these defaults for blast radius and age. The labels Org-wide dependents and Days since fix published therefore do not guarantee an actual calculation of your scope or the fix’s age. Similarly, CVSS-normalized refers here to the severity category table above, not to multiplying CVSS directly by ten.
Worked fictional example
Section titled “Worked fictional example”For a direct dependency with high severity, 20% EPSS, no exploit signal, unknown reachability, and default values:
Severity 0.35 × 75 = 26.25EPSS 0.20 × 20 = 4.00Exploit 0.15 × 10 = 1.50Reachability 0.15 × 75 = 11.25Direct 0.05 ×100 = 5.00Blast radius 0.05 × 60 = 3.00Update lag 0.05 × 16 = 0.80Total = 51.80 → score 52/100A score of 52 does not mean “a 52% chance of being attacked.” With the other factors unchanged, a KEV signal replaces the exploit contribution of 1.50 with 15.00: the score becomes 65. This is a teaching example, not an observation of a real CVE.
Rule-based triage
Section titled “Rule-based triage”Queue and Findings show a deterministic recommendation with the rule’s reason. It is available on Starter, Pro and Team without an AI key. Open the details for the full explanation and unknown signals; list tags also expose the reason.
| Recommendation | Meaning |
|---|---|
| Fix now | Confirmed or assumed production with CISA KEV or EPSS at least 10%. Without a verified corrective version, examine immediate mitigation. |
| Plan | Schedule review/remediation, including KEV or EPSS at least 10% on dev/test-only dependencies. Missing inputs can also require review. |
| Ignore / backlog | Defer by the rule: dev/test with no KEV and known EPSS below 10%; or low production severity with EPSS below 1%; or medium transitive production finding with no known fix and EPSS below 1%. |
Ignore does not hide, suppress, resolve, or accept the risk of a finding. No recommendation automatically opens a PR or performs another action.
Only confirmed dev scope or an exclusively non-production application environment reduces production urgency. Otherwise the reason states Production assumed, context unknown. Optional or unknown scope is not proof of dev-only usage. Application declarations remain a Pro/Team feature; Starter uses dependency scope and the conservative unknown context.
KEV takes precedence over ordinary backlog rules and a disputed CVE. Explicit VEX not_affected or a rejected CVE are policy exceptions, but VEX and CVE status are currently unknown in live results. They are never inferred from reachability or free text. Historical EPSS zero cannot establish a backlog rule because the signal may have been unavailable. Triage uses the severity band when numeric CVSS is unverified and reports that limitation in details.
The default Priority order puts Fix now before Plan before Ignore, then uses the existing numeric rank and base risk within each category. The displayed risk score and breakdown keep their meaning. Alerts and digests retain their existing numeric ordering and selection.
Included triage and optional explanations
Section titled “Included triage and optional explanations”Rules set the category. AI refines the order. Pro and Team include triage for all open findings in active inventories, including scanned application pins. Starter uses rules only. Fix now → Plan → Ignore always takes precedence.
The finding rank starts at the risk score plus declared context, bounded to 0–100, then receives a refinement between −30 and +30, again bounded to 0–100. The stored risk score stays unchanged. An update takes the highest finding rank in its most urgent category; context is not added a second time.
A refinement applies only when the strongest level has at least 70% probability weight. This weight is not an accuracy guarantee. Unknown facts never justify a downward refinement. Verified ended base-image support can add a minimum +5 for active support or +15 for security support on an accepted result. Without a usable result, the rank uses risk and declared context.
Cached decisions are reused while their facts, model and rules are unchanged. Changed data falls back while processing continues. A Partial processing status counts findings awaiting refinement; budgets and temporary errors resume automatically without a rescan.
Settings → AI copilot → LLM explanations and Q&A controls prose only. Turning it off preserves included triage. Choose Explain priority or ask about a finding/update to request prose. Your configured personal key is selected first; otherwise the explicitly configured service key is used. Failure of the selected key returns deterministic facts without switching keys.
Free-text questions go as entered only to the selected explanation provider, never to the scoring engine. Do not include information you do not want sent. Questions and generated answers stay in session memory, with no server history. Provider retention depends on its terms. Replies cite available public sources, recognize missing facts, and never change state or execute actions.
Public watches groups analyze an upstream product; their row count is not the raw finding count. Base-image EOL rows and digest ranking keep their existing contracts.
Three conclusions to avoid
Section titled “Three conclusions to avoid”- “No findings means no risk”: first check inventory, sources, coverage, reference, scan status, and filters.
- “A lower score requires no action”: consider your exposure, policies, and the information in the advisory.
- “The alert disappeared, so it is fixed”: suppression or PR creation may remove an entry from the queue without changing the version in use.
Next: Remediate a vulnerability and verify the fix.
Unavailable data and actions
Section titled “Unavailable data and actions”If OSV is disabled or cannot cover the inventory, the scan reports incomplete advisory matching. Existing findings remain until a complete real scan can reconcile them. Docker images are excluded from OSV package matching; their support lifecycle signals use their own source.
The General settings name and slug are read-only. Subscription changes use the configured billing flow. An AI suggestion to create a ticket reports that ticket creation is unavailable; create it directly in your issue tracker.