Reference B: Investigation details

Urgency Details

The Urgency Details section in the issue side panel supplies the reachability evidence: whether the CVE is listed in CISA KEV, its EPSS probability, its exploit maturity and exploit availability, and whether the affected package is used in an image, deployed, internet-exposed, or loaded into the memory of a deployed asset.

Evidence	Consequence
Listed in CISA KEV, or exploit maturity is active	Exploitation is not theoretical. Treat as an incident and escalate
High EPSS, no confirmed exploitation yet	Exploitation is probable and near-term. Remediate ahead of the SLA deadline
Deployed, internet-exposed, and loaded into memory	The path from the internet to the vulnerable code is complete
Not deployed, or not loaded into memory	The path is incomplete. Confirm the gap is real and not a traceability gap before deprioritizing

For metric definitions and calculation context, see Urgency and Understand Urgency metrics.

Important

Urgency signals related to deployment context are populated only when the SCA asset is traced to deployed cloud resources through the Code-to-Cloud mapping. If no Code-to-Cloud trace exists, deployment-related urgency signals display as Not Applicable. SCA-specific signals (EPSS Score, KEV Status, Reachability, Has Fix) are always available regardless of Code-to-Cloud traceability.

What is exposed if the CVE is exploited?

Blast radius determines the escalation level and how much capacity the issue justifies.

The Urgency Details section reports the count of affected assets, the criticality and environment of the owning application, whether the affected asset has access to sensitive data or holds privileged capabilities, and the effectiveness of any compensating control already in place. The Code-to-Cloud graph shows the same exposure as a path — the repository, the pipeline that builds it, and every asset the pipeline deploys to.

One vulnerable package in a shared library multiplies across every application that consumes the library. The graph makes that multiplication visible, and it is the reason two issues with the same CVE and the same Severity can justify entirely different responses.

An existing compensating control reduces the exposure but does not remove the CVE. Record the control, and keep the issue open against the fix release.

Who owns the fix, and what does the fix cost?

The code evidence names the repository, the branch, the file path, and the commit that introduced the finding, along with the commit author. That identifies the team to route the work to and the manifest to change.

The placement of the package determines the cost. A direct dependency is a version bump in the manifest. A transitive dependency requires upgrading the root package or applying an override, which pulls in unrelated changes and requires the owning team's regression testing. Establish the placement during the investigation, because the placement — not the CVE — drives the remediation timeline.

Two conditions that understate impact

• A stale classification. When the Urgency classification has not been recalculated since the issue last changed, the issue side panel marks the classification as stale. The evidence you are reading may predate a change in exploit intelligence or deployment state. Verify before committing capacity against the classification.
• A missing deployment trace. When the issue is not deployed, the issue side panel states that no deployment was found. Treat a missing deployment trace as unmeasured risk rather than low risk — deployment-dependent metrics cannot be computed without Code-to-Cloud traceability, which pushes the issue toward the Not Urgent and Not Applicable levels.

Important: The Urgency Details section is populated for issues from periodic scans. PR scan issues and CI scan issues have no deployment context, because unmerged code is not deployed. For PR scan and CI scan issues, prioritize by Severity.