> 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/finding-types/dependencies/vulnerability-enrichment.md). # Vulnerability Enrichment How Konvu enriches vulnerabilities with exploitability checklists that determine whether a finding applies to your environment. Not all vulnerabilities apply to every application. A vulnerable function that your code never calls, or a flaw that only affects Windows when you run Linux, poses no real risk. The challenge is figuring out which conditions matter for each vulnerability. Konvu maintains an enriched vulnerability database that goes beyond severity scores. For each vulnerability, Konvu builds an **exploitability checklist**, a set of conditions that must all be true for the vulnerability to be exploitable. This checklist drives every assessment. ## What enrichment adds Raw vulnerability data from sources like OSV, GitHub Advisory, and NVD tells you *what* is vulnerable. Konvu's enrichment adds *when* it's exploitable:
Raw vulnerability dataKonvu enrichment
Affected package and versionsVulnerable method signatures: the specific functions that are dangerous
CVSS severity scoreExploitability checklist: the conditions required for actual exploitation
Advisory descriptionEnvironment conditions: which OS, runtime, or platform is affected
Patch informationAttacker controllability conditions: what input patterns enable exploitation
## The exploitability checklist Each enriched vulnerability has a checklist of conditions structured as an **AND-logic chain**: every condition must be met for the vulnerability to be exploitable. If any single condition is false, the vulnerability is a false positive for your application. A typical checklist includes conditions like: * **Is the vulnerable package installed?** The affected dependency and version must be in your dependency tree. * **Does your environment match?** The vulnerability may only affect specific operating systems, runtimes, or platform versions. * **Is the vulnerable function reachable?** The specific dangerous function must be called from your application code. * **Can untrusted input reach it?** User-controlled or attacker-controlled data must flow to the vulnerable code path. * **Are dangerous settings enabled?** The vulnerability may require specific configuration options to be active.
### Example For a vulnerability in `sanitize-html` (GHSA-xc6g-ggrc-qq4r), the checklist might be: 1. Untrusted HTML is passed to `sanitizeHtml()`. *Checks whether attacker-controlled input reaches the function* 2. `allowedTags` configuration includes a `nonTextTag`. *Checks whether a dangerous configuration is active* 3. Output is rendered as HTML without additional escaping. *Checks whether the output context enables exploitation* If your application sanitizes HTML but doesn't include `nonTextTag` in `allowedTags`, condition 2 fails and the vulnerability is a false positive, regardless of the other conditions. ## How enrichment is built Konvu enriches vulnerabilities from multiple sources: * **Automated analysis.** Konvu analyzes vulnerability advisories, affected package source code, and patch diffs to identify the specific functions and conditions involved. * **Vulnerability database.** Konvu cross-references data from OSV, GitHub Advisory, and NVD to build a complete picture of each vulnerability. * **Continuous updates.** As new information becomes available (updated advisories, new patches), checklists are re-evaluated and updated. Enrichment covers vulnerabilities across all [supported ecosystems](/konvu/what-is-konvu.md#languages): Java/Maven, JavaScript/npm, Python/PyPI, Ruby/RubyGems, Go, .NET/NuGet, PHP/Composer, and Rust/Cargo. ## How enrichment feeds into assessments When Konvu [assesses a finding](/konvu/triage-and-remediation/exploitability-assessment/how-assessments-work.md), it takes the vulnerability's exploitability checklist and evaluates each condition against your specific codebase and environment: 1. Konvu retrieves the enriched checklist for the vulnerability 2. For each condition, Konvu checks your source code, runtime data, and any answers you've provided 3. Each condition gets a determination: **met**, **not met**, or **inconclusive** 4. The combination of determinations produces the [assessment result](/konvu/triage-and-remediation/exploitability-assessment/reading-an-assessment.md#how-pre-conditions-map-to-results) This is why connecting your [source code](/konvu/get-started/connect-your-environment/source-code.md) matters. More context means Konvu can evaluate more conditions, leading to more conclusive results. ## Next steps * [Reading an assessment](/konvu/triage-and-remediation/exploitability-assessment/reading-an-assessment.md): how to interpret the pre-condition checks on each finding * [How assessments work](/konvu/triage-and-remediation/exploitability-assessment/how-assessments-work.md): the full assessment lifecycle --- # 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/finding-types/dependencies/vulnerability-enrichment.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.