> 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/exploit-reproduction/how-reproduction-works.md). # How Reproduction Works How Konvu turns a finding into a running exploit: the pipeline stages, the isolated sandbox, what it needs from you, and its limits. A reproduction checks whether the exploit fires against your application in an environment Konvu controls. It runs in five stages. Each stage hands a structured result to the next, and any stage can stop the run with a stated reason. ## The pipeline | Stage | What happens | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Map** | Konvu reads your code and program rules and builds a threat model of the application: its assets, roles, and attack surface. The map is cached per project and reused across reports. | | **2. Deduplicate** | Reports that describe the same vulnerability are linked, so one bug reported twice is reproduced once. Two reports are duplicates when one patch would fix both. | | **3. Plan** | Konvu writes the environment spec: the version to deploy, its configuration, and the seed data. It also lists the exploit's prerequisites up front, such as a user role or a feature flag. | | **4. Deploy** | Konvu builds your application at the affected version, starts it, seeds it, and runs a smoke test. The exploit is not attempted until the application is confirmed healthy. | | **5. Attack** | An attacker agent, running on a separate machine from the application, attempts the exploit. It records a baseline of the application's state before the attack and checks for observable side effects after. | Most runs take several minutes. The report or finding shows its live stage while the run is in progress. ### How the reproduction result is computed Before attacking, Konvu breaks the report into specific claims. *Example: "an unauthenticated user can read another tenant's invoices through `/api/invoices/{id}`" becomes separate claims for authentication, tenant isolation, and data exposure.* Each claim ends up **proven**, **disproven**, or **inconclusive**, and the reproduction result is computed from them: * Any claim still unresolved makes the run **Inconclusive**. * Proven impact, with the remaining claims resolved, makes it **Exploitable**. * Every claim disproven makes it **Not exploitable**. The rollup follows fixed rules that no model can override. The claims appear on the result as **What was proven**. See [Reading a Reproduction](/konvu/triage-and-remediation/exploit-reproduction/reading-a-reproduction.md). ## The sandbox {% hint style="info" %} Nothing runs against your infrastructure. Konvu builds and deploys its own copy of your application from your repository. {% endhint %} * Sandboxes run in a **dedicated AWS account** used only for reproduction. * The application and the attacker run on **separate instances**. * **Everything is torn down** once the reproduction result is reached. Leftover sandboxes are terminated automatically. The result lists **Where the lab differs from production**, so you can judge whether a difference matters for your deployment. ## Which version is tested By default, Konvu deploys the **version named in the report**, so you see whether the reported bug was real. You can also run against the **latest version** to check whether it has since been fixed. See [Re-running Reproductions](/konvu/triage-and-remediation/exploit-reproduction/re-running-reproductions.md#check-the-latest-version). Scanner findings are always reproduced against the latest commit of the branch where they were found. ## What Konvu needs from you * **A connected repository.** Each report targets a repository. Konvu builds the application from it. See [Connect Your Environment](/konvu/get-started/connect-your-environment.md). * **A buildable application.** Konvu works out how to build and run your application from the repository. It does not need build instructions from you. * **Program rules, for bug bounty reports.** Konvu triages reports against your program's scope and rules before it reproduces them. ## Reports are untrusted input A bug bounty report is text written by someone outside your organization, and Konvu treats it that way. Every stage checks the report for prompt injection. If injection is detected, the pipeline stops, the offending text is redacted, and the report is locked for review. A locked report cannot be reproduced until the lock is cleared. ## Why a run stops early A run that cannot reach a proven or disproven result stops with a reason instead of guessing: | Reason | Meaning | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Environment limitation** | The sandbox cannot run what the exploit needs: a paid feature, a managed cloud service, real credentials, a physical device, or an operating system the sandbox does not support. | | **Report inaccurate** | The report's claims do not match the code, for example an endpoint that does not exist. | | **Hardening** | The issue is real in the code, but a mitigation in place stops it from being exploited at runtime. | | **Not exploitable** | Konvu gathered evidence that the vulnerability is not present. | The first reason produces an **Inconclusive** reproduction result. The others produce the reproduction results described in [Reading a Reproduction](/konvu/triage-and-remediation/exploit-reproduction/reading-a-reproduction.md#reproduction-results). ## What reproduction does NOT do * It does not test your live environment, your cloud accounts, or production data. * It does not reproduce container or secret findings. * It does not downgrade a finding on a Hardening or Inconclusive reproduction result. An exploit that did not fire in the sandbox is not proof that the vulnerability is absent, so the assessment result stands. Only a Not exploitable result changes the finding to False Positive. * It does not reproduce a report that triage rejected, unless the report is re-triaged first. Reproductions can be subject to per-organization limits. If you reach one, the run is refused with the limit that applied. Contact your Konvu team to change it. --- # 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/exploit-reproduction/how-reproduction-works.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.