> 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/get-started/bring-in-findings/external-reports.md).

# External Reports

Import pentest reports, audits, scanner exports, and findings from AI code security tools into Konvu with the dashboard, the CLI, or the API.

Import vulnerability reports into Konvu for automated triage and reproduction. Target the repository the report applies to; Konvu resolves the matching vulnerability-report configuration.

## What you can submit

Any document that describes one or more vulnerabilities in your code:

* **Pentest and audit reports**, often delivered as PDF.
* **Researcher write-ups** received outside a connected bug bounty program.
* **Scanner exports** from scanners Konvu has no integration for, as SARIF or JSON.
* **Findings from AI code security tools**, such as security reviews run by AI coding agents. Save the tool's output as Markdown, JSON, or SARIF and submit it like any other report.

Konvu handles every report the same way, whether a person or an AI tool wrote it: it is triaged, deduplicated, and [reproduced](/konvu/triage-and-remediation/exploit-reproduction.md) against your code.

## Supported formats

| Format     | Extensions | Dashboard | CLI | API                 |
| ---------- | ---------- | --------- | --- | ------------------- |
| Markdown   | `.md`      | Yes       | Yes | Yes                 |
| Plain text | `.txt`     | Yes       | Yes | Yes                 |
| JSON       | `.json`    | Yes       | Yes | Yes                 |
| SARIF      | `.sarif`   | Yes       | Yes | Yes                 |
| PDF        | `.pdf`     | Yes       | Yes | Yes, base64-encoded |

Konvu stores the file as you submitted it. A JSON or SARIF export keeps its structure and renders as a code block on the report page rather than as collapsed prose. A PDF is converted to text when it arrives, and the text is what gets triaged — the original file is not kept.

{% hint style="info" %}
A PDF has to come from a file, not a pipe. `--file -` reads text only, because a PDF's title is its filename and a pipe has none. The CLI refuses any other file that is not text rather than uploading a corrupted body.
{% endhint %}

## Reports with many findings

A scanner export usually describes many findings in one file. Triaged as a single report, those findings cannot be told apart: deduplication has nothing to compare, and reproduction runs against a document rather than a vulnerability.

Konvu splits it first. Before triage, an agent reads the upload and decides whether it holds one finding or several. If it holds several, Konvu carves out **one report per independently fixable finding** — the same unit deduplication uses, so two reports are duplicates when one patch would resolve both.

Each report then follows the normal lifecycle on its own:

* Triaged against your program rules, with its own triage result.
* Deduplicated against your other reports, so the same bug reported twice is linked rather than reproduced twice.
* Reproduced individually, so evidence points at one vulnerability.

The findings are copied verbatim out of your export. Konvu does not summarize or reword them, and it keeps a link from each report back to the file it came from.

What you see after uploading an 86-finding export is 86 reports, not one. That is the intended result.

Splitting applies to files you upload, through any of the three routes below. Reports that arrive from a connected HackerOne program or GitHub Security Advisory already describe one finding each and are never split. It runs when automated triage is enabled for your organization; with automation off, your upload is stored and waits for you as a single report.

## Import from the dashboard

Open **Triage > Vulnerability reports** and select **Upload report**. Drop a file on the upload area or click to browse. Pick the repository the report applies to, then select **Upload**.

The title comes from the file: its first Markdown heading, or the file name when it has none.

## Import with the CLI

The same import can also be done with the Konvu CLI (see `konvu --help`).

## Import with the API

Authenticate with an organization-scoped **Read and write** API key. A read-only key can retrieve reports but cannot submit one. See [API Documentation](/konvu/reference/api-documentation.md#generate-an-api-key) to create one.

```bash
curl -X POST https://api.konvu.com/services/vulnerability-reports/v1/reports \
  -H "Authorization: Bearer $KONVU_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "repository": { "vcs_repo_url": "github:acme/web" },
    "content": "# Stored XSS in profile rendering\nThe profile renderer accepts unsanitized HTML...",
    "source": "burp"
  }'
```

| Field                     | Required | Notes                                                                                                                                                                                                    |
| ------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `repository.vcs_repo_url` | Yes      | Repository URL, such as `github:acme/web`.                                                                                                                                                               |
| `title`                   | No       | Report title, up to 500 characters. Derived from the report when omitted.                                                                                                                                |
| `content`                 | Yes      | The report body. Base64-encoded when `file_type` is `pdf`, otherwise the file's text.                                                                                                                    |
| `file_type`               | No       | One of `md`, `txt`, `json`, `sarif`, `pdf`. Only `pdf` changes how `content` is read.                                                                                                                    |
| `source`                  | No       | The tool that reported it, such as `burp`. Up to 64 characters. Surrounding whitespace is trimmed; nothing else about the value is changed. Omit it and Konvu infers the source from the report instead. |

`source` is set when the report is created and never changes. Submitting the same report again creates a second report; it does not relabel the first.

Send a SARIF export as its own text, with no encoding:

```bash
curl -X POST https://api.konvu.com/services/vulnerability-reports/v1/reports \
  -H "Authorization: Bearer $KONVU_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile report konvu-web.sarif \
    '{repository: {vcs_repo_url: "github:acme/web"}, source: "xbow", content: $report, file_type: "sarif"}')"
```

A new report returns `201 Created`. The response contains the created report and the pipeline outcome:

```json
{
  "report": {
    "id": "019d0000-0000-7000-8000-000000000001",
    "title": "Stored XSS in profile rendering",
    "status": "pending",
    "created_at": "2026-09-11T18:00:00Z",
    "updated_at": "2026-09-11T18:00:00Z"
  },
  "pipeline": "dispatched"
}
```

`pipeline` is `dispatched`, `skipped`, or `held_not_chargeable`. A report is stored in all three cases; the value describes whether automated triage was started.

The response describes the file you submitted. When that file holds several findings, the reports Konvu carves out of it appear in Triage shortly afterwards, each with its own id — the upload response does not list them.


---

# 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/get-started/bring-in-findings/external-reports.md?ask=<question>&goal=<user_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.
