> ## Documentation Index > Fetch the complete documentation index at: https://docs.backline.ai/llms.txt > Use this file to discover all available pages before exploring further. # Exploitability > Understand how Backline evaluates whether a vulnerability can realistically be exploited in your environment ## Overview Exploitability helps you understand whether a vulnerability can realistically be used against your environment. A vulnerability may be severe in theory, but not exploitable in practice. Backline evaluates exploitability using environment-specific evidence such as runtime presence, network exposure, configuration, and access controls to answer a more practical question: **"Can this vulnerability be exploited in this environment?"** This context helps security and engineering teams distinguish between theoretical risk and actionable risk. ## Where to Find It Open a vulnerability and navigate to: **Vulnerability Side Panel → Risk Analysis** The Risk Analysis tab includes exploitability context, supporting evidence, and access to the full report. ## What Exploitability Shows The Exploitability section provides a concise, evidence-based assessment of the vulnerability in your environment. It includes: * **Exploitability status**: Yes, No, or Uncertain * **Confidence**: High, Medium, or Low * **Summary**: Plain-language explanation of the assessment * **Explanation**: Why the vulnerability received this result * **Last scanned**: Timestamp of the latest analysis * **Exploitability factors checked**: Key signals used in the assessment * **Affected resources**: Resources included in the evaluation * **Full report**: Detailed markdown report available in a modal ## Exploitability Status Backline assigns one of four exploitability outcomes: The analysis is currently in progress. This status appears when the vulnerability was newly ingested. All required exploit conditions appear to be satisfied based on the available evidence. Use this result when the environment signals support a realistic exploitation path. At least one required exploit condition is blocked. Use this result when Backline has evidence that exploitation is currently prevented by the environment, deployment model, or control plane. The available evidence is incomplete, partial, or inconclusive. Use this result when Backline cannot confidently prove that exploitation is possible or blocked. ## Confidence The confidence score indicates how strong and complete the supporting evidence is. ### High Used when the assessment is supported by direct, relevant, and sufficient signals from the environment. ### Medium Used when the assessment is supported by meaningful evidence, but some signals are inferred, incomplete, or indirect. ### Low Used when important evidence is missing, weak, or unavailable, and the result relies on partial context. Confidence reflects the quality of the evidence, not the severity of the vulnerability. ## How It Works Backline evaluates exploitability by checking whether the conditions required for exploitation are present in the customer environment. The result is based on a set of evidence-backed checks shown in the Risk Analysis tab. ### Exploitability Factors Checked Determines whether the vulnerable software, package, image, or component is actually present in a deployed runtime context. Typical evidence sources include cloud telemetry and scan data. Determines whether the affected workload is exposed in a way that could allow exploitation. Typical evidence sources include security groups, ingress, load balancers, and routing configuration. Determines whether authentication, authorization, or identity-based controls may block exploitation. Typical evidence sources include IAM, configuration, and inferred access controls. Determines whether the vulnerable feature, service, or execution path is enabled in the environment. Typical evidence sources include runtime or configuration signals. Each factor is displayed with: * **Result**: Pass, Fail, or Unknown * **Evidence source**: Where the signal came from ## Understanding the Result Exploitability is environment-aware. The same CVE may receive different exploitability assessments across different customers, workloads, or deployments. For example: * A vulnerability may be rated critical by CVSS, but still be **Not Exploitable** if the vulnerable component is not exposed or not active. * A vulnerability may be **Uncertain** if Backline can confirm runtime presence, but cannot verify whether the vulnerable path is externally reachable. * A vulnerability may be **Exploitable** when the affected component is present, exposed, and not meaningfully restricted. ## Affected Resources The Affected Resources table shows which resources are part of the exploitability assessment. This section includes: * **Resource type** * **Resource identifier** * **Details** Where supported, the resource identifier is shown as a link. This helps answer questions such as: * Which workloads are running the affected image? * Which resources are included in this assessment? * Where should I investigate first? ## Full Report Select **See Full Report** to open the complete exploitability report. The report is displayed in a modal in markdown format and includes the full reasoning, evidence summary, and supporting context behind the final assessment. This is useful when you need a deeper explanation or want to review the evidence before sharing or downloading the report. ## Why This Matters Exploitability helps teams focus on what is most relevant in their environment. Severity alone does not answer whether a vulnerability is actionable. Exploitability adds the missing operational context by showing whether the required conditions for exploitation are actually present. This helps teams: * prioritize vulnerabilities with real-world relevance * reduce time spent on non-actionable vulnerabilities * explain remediation decisions with evidence * align security urgency with runtime reality ## Best Practices Use exploitability together with severity and broader risk context. A common workflow is: 1. Review the exploitability status 2. Read the summary and explanation 3. Check confidence 4. Review the factor table 5. Open the full report when deeper detail is needed Exploitability should inform prioritization, but it should not be interpreted in isolation. A result of **Uncertain** may still require review, especially for high-severity vulnerabilities. ## FAQ ### Is exploitability the same as severity? No. Severity describes the potential technical impact of a vulnerability. Exploitability evaluates whether the vulnerability can realistically be used in your environment. ### Can a critical vulnerability be marked as not exploitable? Yes. A vulnerability can be severe in theory but blocked in practice by environmental conditions such as lack of exposure, missing runtime presence, disabled features, or access controls. ### What does Uncertain mean? Uncertain means Backline does not have enough evidence to confidently conclude that the vulnerability is exploitable or blocked. ### What does confidence mean? Confidence reflects the completeness and strength of the evidence supporting the assessment. It does not indicate how dangerous the vulnerability is. ### Why do I see affected resources? Affected resources help you understand which workloads or assets were included in the exploitability evaluation. ### When should I open the full report? Open the full report when you need deeper reasoning, want to validate the evidence, or need a shareable explanation of the assessment. ## Related Documentation Understand how Backline combines multiple signals into a single environment-aware score Learn how Backline evaluates whether vulnerable code is actually used by your application See how threat intelligence data informs exploitability scoring Understand how remediations work in Backline