Read a vulnerability detail page

Use this article when you have opened a vulnerability and need to understand the sections, evidence, and next actions on the detail page.

Page layout

• Overview: primary vulnerability evidence, sidebar metadata, comments, and workflow actions.

• Analysis: call hierarchy or analysis context when available.

• Locations: active locations with filters for asset and branch or ref. Code findings also provide a container filter.

• Activity: timeline of status changes, comments, and system activity.

• Sidebar: status, snooze, analysis, assignment, ticketing, introduced-by, and impact sections when available.

When you open a vulnerability from a scan

If you open a vulnerability from a list filtered to a specific scan, the detail page stays scoped to the branch or tag from that scan. A banner identifies the active ref filter, and the filter follows the Overview, Analysis, Locations, and Activity tabs.

The filter selects evidence from that ref and narrows locations and call hierarchies. Select Remove filter in the banner to return to evidence from all refs.

Review call hierarchy analysis

• Use path search to find a specific call hierarchy.

• Filter available hierarchies by analysis state, branch, or tag.

• Exploitable identifies a hierarchy confirmed to reach the vulnerable code.

• Not exploitable identifies a hierarchy determined not to reach the vulnerable code.

• Pending means analysis is still in progress.

• Needs review means human review is required.

• Select a hierarchy to review its data flow or function analysis and step-by-step code excerpts when available.

When endpoint discovery is available, code findings can also show linked HTTP endpoints under Endpoint reachability. Follow a linked call chain to inspect the evidence. Investigate external access and exploitability separately.

Why does a confirmed finding still need human review?

A finding can have confirmed exploitable evidence while other evidence remains unresolved. Check the Human review still required callout for the remaining review reasons. When exploitability is unresolved and human review is required, the Analysis section can show Exploitability: Needs Review.

Review summaries group the relevant evidence. Call-chain evidence can replace less complete local analysis for the same location, while independent locations remain visible. An automated exploration limit is a separate review reason and does not add to the unresolved path count. A manual Needs Review status identifies a requested review and does not by itself mean automated analysis was inconclusive.

See Human review evidence for the maintained explanation.

Evidence by vulnerability type

• Code: code snippets, vulnerable context, locations, and analysis when available.

• Dependency: advisory IDs, affected package and versions, patched versions, references, locations, EPSS, and CVSS when available. Existing findings refresh their title, severity, CWE classifications, and impacts when updated advisory data is received.

• Secret: the Assessment Method identifies a Provider check or Context assessment. Provider checks show provider, verification status, timestamps, materials, and history when available. Context assessments show source context and assessment notes. When manual closure is enabled, a context-assessed secret that disappears moves to Needs Review.

Read secret verification history

For a Provider check, Verification History records individual checks. Live means the provider accepted the credential; Not Live means it did not accept the credential for that check. Awaiting Materials means additional verification materials are needed, and Retry Scheduled identifies a temporary provider or network failure.

Results are retained for 30 days. An empty history can mean that no check has been recorded or that earlier results have expired. Review the current secret status and verification timestamps alongside the history. See Verification history for the full label reference.

Why does a fixed finding still have active locations?

In Cysmiq Cloud, a finding can be automatically Resolved / Fixed while active locations remain outside its configured fix branches. Check Locations and the branch or ref before interpreting the overall status. See Automatic resolution.

Common next actions

• Update status or resolution after triage.

• Assign the vulnerability to an owner.

• Create or review a linked Jira or Linear ticket.

• Request or review a snooze when remediation needs more time.

• Add comments or watch the vulnerability for updates.

Canonical docs

For the maintained reference, see Vulnerability detail view.

Contact support if

• The detail page is missing expected evidence or locations.

• Call hierarchy search, filters, or analysis labels do not match the available analysis data.

• The status, assignment, ticketing, or snooze controls are unavailable unexpectedly.

• You need help interpreting code, dependency, or secret-specific evidence.