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.

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.
• 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.

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.