> For the complete documentation index, see [llms.txt](https://docs.konvu.com/konvu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konvu.com/konvu/triage-and-remediation/exploitability-assessment/reading-an-assessment.md). # Reading an Assessment Every assessment checks whether a vulnerability's exploitability pre-conditions are met in your environment. Every assessment evaluates a set of exploitability pre-conditions, the conditions that must **all** be true for a vulnerability to be exploitable in your environment. If any condition is false, the vulnerability doesn't apply to you. When you open a finding's detail page, the evidence panel shows each pre-condition and whether it was met.

## Exploitability pre-conditions Konvu checks four categories of pre-conditions, evaluated in order: ### 1. Dependency installed Is the vulnerable dependency actually present in your codebase? This checks whether the affected package and version appear in your manifest or lockfile. A vulnerability in a package you don't use is irrelevant.

Determination	What it means
Met	The vulnerable package and version are present in your dependency tree
Not met	The package isn't installed, or you're on a version outside the affected range
Inconclusive	Konvu couldn't determine the installed version

### 2. Environment Does your application run in an environment where the vulnerability applies? Some vulnerabilities only affect specific operating systems, runtime versions, or platforms. This condition checks whether your environment matches.

Determination	What it means
Met	Your OS, runtime, or platform matches the vulnerability's requirements
Not met	The vulnerability requires a different OS, runtime version, or platform than yours
Inconclusive	Konvu couldn't determine your environment configuration

*Example: A vulnerability that only affects frontend enrivonment won't apply if your service runs a backend application.* ### 3. Code reachability Is the vulnerable code reachable from your application? This checks whether the vulnerable function or code path is actually called from your application's entry points. A vulnerable dependency that's installed but never invoked poses no risk.

Determination	What it means
Met	The vulnerable function is imported, referenced, or reachable through your call graph
Not met	The vulnerable function isn't called from any application entry point
Inconclusive	Konvu couldn't fully trace the call graph

When reachability is confirmed, the evidence shows the specific file paths and code snippets where the vulnerable function is referenced.

### 4. Attacker controllability Can an attacker actually reach and exploit the vulnerable code? This is the most nuanced check. Even if vulnerable code is reachable, exploitation requires that untrusted input can reach it through your application's data flow. This checks conditions like: * Does user-controlled input reach the vulnerable function? * Are dangerous configuration options enabled? * Does input validation or sanitization prevent exploitation? * Are safe API variants used instead of vulnerable ones?

Determination	What it means
Met	Untrusted input can reach the vulnerable code path, and exploit conditions are satisfied
Not met	Input is validated, a safe API is used, or the dangerous configuration is disabled
Inconclusive	Konvu couldn't determine the data flow or needs your input

When this condition is inconclusive, Konvu may ask [questions](/konvu/triage-and-remediation/exploitability-assessment/answering-konvus-questions.md) asking you about your application's specifics (e.g., "Is this service internet-facing?"). ## How pre-conditions map to results The relationship between pre-conditions and assessment results is straightforward:

Pre-conditions	Assessment result
All conditions met	Exploitable: the vulnerability can likely be exploited in your environment
Any condition not met	False Positive: at least one requirement for exploitation isn't satisfied
Some conditions inconclusive, with questions to ask	Needs input: Konvu needs your help to evaluate remaining conditions
Some conditions inconclusive, no questions available	Inconclusive: not enough evidence to determine either way

## Reading the evidence panel Each pre-condition in the evidence panel shows: * **The condition being checked**: a plain-English description of what needs to be true * **The determination**: met, not met, or inconclusive * **Supporting evidence**: the specific code snippets, file paths, or reasoning that support the determination You can expand each condition to see the full evidence. When Konvu references your code, it shows the file path and a few lines of surrounding context. {% hint style="info" %} Evidence is cumulative. As you connect more data sources and answer Konvu's questions, Konvu can evaluate more pre-conditions and produce stronger assessment results. {% endhint %} ## Next steps * [Vulnerability enrichment](/konvu/triage-and-remediation/finding-types/dependencies/vulnerability-enrichment.md): how Konvu builds the exploitability checklist for each vulnerability * [Reviewing assessments](/konvu/triage-and-remediation/exploitability-assessment/reviewing-assessments.md): validating assessment results and overriding when needed * [Answering Konvu's questions](/konvu/triage-and-remediation/exploitability-assessment/answering-konvus-questions.md): providing context when Konvu needs your input --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.konvu.com/konvu/triage-and-remediation/exploitability-assessment/reading-an-assessment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.