> 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.md). # Bring In Findings Import vulnerability findings and reports from your existing tools into Konvu. Import findings from your security scanners, reports from bug bounty programs, and external reports such as pentests, audits, or the output of AI code security tools. Connected sources sync automatically on a regular schedule. For a scanner Konvu doesn't integrate with, send its SCA findings with the [API](#import-scanner-findings-with-the-api) or upload them as a [CSV file](/konvu/get-started/bring-in-findings/csv-import.md). ## Scanner findings When you connect a scanner, Konvu ingests: * **Vulnerability identifiers** -- CVE IDs, GHSA IDs, and scanner-specific identifiers * **Severity data** -- critical, high, medium, low as reported by the scanner * **Affected packages** -- dependency name, version, and ecosystem (npm, Maven, pip, etc.) * **Manifest locations** -- which lockfile or manifest file contains the vulnerable dependency * **Dependency context** -- direct vs. transitive, reachability data (when the scanner provides it) * **Finding state** -- open, dismissed, or fixed status from the source tool Konvu ingests open-source dependency vulnerabilities (SCA) and, for supported scanners, code analysis findings (SAST) and container vulnerabilities. It does not import infrastructure-as-code findings. [Secrets triage](/konvu/triage-and-remediation/finding-types/secrets.md) includes Konvu repository detections and a separate view of imported GitHub Secret Scanning alerts; other integrations do not automatically provide secret findings. ## Supported sources ### SCA and SAST | Scanner | SCA | SAST | What it brings in | Setup | | -------------------------------------------------------------------------------------------- | --------- | ----------- | ----------------------------------------------------------------------------------- | ---------------------- | | [Snyk](/konvu/get-started/bring-in-findings/code-scanners/snyk.md) | Supported | Coming soon | Snyk Open Source SCA findings. Organization-level, supports multiple orgs. | Auth Token + OAuth | | [Semgrep](/konvu/get-started/bring-in-findings/code-scanners/semgrep.md) | Supported | Supported | Semgrep Supply Chain and Code findings. Organization-level, supports multiple orgs. | API Token | | [GitHub Dependabot](/konvu/get-started/bring-in-findings/code-scanners/github-dependabot.md) | Supported | Coming soon | Dependabot alerts from your GitHub repositories. Connects through your GitHub App. | GitHub App permissions | | [Endor Labs](/konvu/get-started/bring-in-findings/code-scanners/endor-labs.md) | Supported | Coming soon | Endor Labs SCA findings with function-level reachability data. Namespace-level. | API Key + Secret | | [Arnica](/konvu/get-started/bring-in-findings/code-scanners/arnica.md) | Supported | Supported | Arnica SCA and SAST findings with reachability and package type context. | API Key | ### ASPM | Platform | What it brings in | What Konvu sends back | Setup | | -------------------------------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | [ArmorCode](/konvu/get-started/bring-in-findings/armorcode.md) | SCA vulnerability findings from ArmorCode. | Send individual SCA assessments or automatically forward SCA and SAST assessments as comments and tags. Automatic forwarding is off by default. | API key | ### Container | Scanner | What it brings in | Setup | | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------- | | [AWS Inspector](/konvu/get-started/bring-in-findings/container-and-cloud-scanners/aws-inspector.md) | Container findings from AWS Inspector (and Amazon ECR basic scanning). | AWS cloud connection | | [Wiz](/konvu/get-started/bring-in-findings/container-and-cloud-scanners/wiz.md) | Container findings from your Wiz tenant. | Service account (client ID/secret) | AWS Inspector findings arrive through your AWS account connection, set up under [Connect Your Environment > Cloud](/konvu/get-started/connect-your-environment/cloud.md). To connect a **container registry**, connect AWS there too — Amazon ECR is part of that flow. Non-AWS registries (GCR, Docker Hub, Harbor) are not supported yet. ### Vulnerability reports | Source | What it brings in | Setup | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- | | [HackerOne](/konvu/get-started/bring-in-findings/bug-bounty-programs/hackerone.md) | Vulnerability reports from your HackerOne program. | API token | | [External reports](/konvu/get-started/bring-in-findings/external-reports.md) | Pentest and audit reports, researcher write-ups, scanner exports, and findings from AI code security tools. Markdown, plain text, JSON, SARIF, or PDF. | Dashboard upload, CLI, or API | ### Any other scanner | Method | What it brings in | Setup | | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------- | | [API](#import-scanner-findings-with-the-api) | SCA findings your pipeline sends after each scan. Re-sending a finding updates it. | Read and write API key | | [CSV import](/konvu/get-started/bring-in-findings/csv-import.md) | SCA findings from any scanner, one file at a time. Each upload is a snapshot. | Dashboard upload | ## Import scanner findings with the API Using a scanner Konvu doesn't integrate with yet? Import your SCA findings directly with `POST /sca_findings`. Instead of Konvu pulling on a schedule, your pipeline sends findings after each scan. This accepts SCA (open-source dependency) findings only — not SAST or container findings. Prefer the command line? The Konvu CLI wraps this endpoint as [`konvu finding submit`](/konvu/reference/cli.md#konvu-finding-submit). For a one-off import, [upload a CSV file](/konvu/get-started/bring-in-findings/csv-import.md) instead. Authenticate with a **Read and write** API key (`Authorization: Bearer api_...`); a read-only key cannot submit findings. See [API Documentation](/konvu/reference/api-documentation.md#generate-an-api-key) to create one. Keys are scoped to your organization. Each finding is a **vulnerability in a dependency**, located at a **repository, ref (branch or tag), and manifest path** — Konvu resolves these server-side, so you don't need its internal IDs. Those five parts are the finding's identity and its dedup key (see below). ```bash curl -X POST https://api.konvu.com/sca_findings \ -H "Authorization: Bearer $KONVU_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "repository": { "vcs_repo_url": "https://github.com/your-org/your-repo", "vcs_ref": "main" }, "findings": [ { "vulnerability_id": "CVE-2021-23337", "manifest_location": "package.json", "dependency_name": "lodash", "dependency_version": "4.17.15", "dependency_ecosystem": "npm", "transitivity": "transitive", "state": "open", "source": "snyk" } ] }' ``` ### Repository fields | Field | Required | Notes | | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `vcs_repo_url` | Yes | GitHub or GitLab repository URL — `https://github.com/your-org/your-repo` or the short `github:your-org/your-repo`. Must point at the repository itself, not a branch or file path. The response echoes it canonicalized (`github:org/repo`). | | `vcs_ref` | No | Git ref the findings pertain to: a branch name (`main`) or a tag ref (`refs/tags/1.2.0`). A bare name is always treated as a branch — tags require the `refs/tags/` prefix. Defaults to the repository's default branch in Konvu, and is required if the repository isn't connected yet (there's no default to fall back to). Echoed back. | ### Finding fields | Field | Required | Notes | | ---------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `vulnerability_id` | Yes | CVE or GHSA identifier. | | `manifest_location` | Yes | Path to the dependency manifest, e.g. `package.json` or `services/api/pom.xml`. | | `dependency_name` | Yes | Affected package, e.g. `lodash` or `com.fasterxml.jackson.core:jackson-databind`. | | `dependency_ecosystem` | No | `npm`, `maven`, `pypi`, etc. Inferred from the manifest path when omitted. | | `dependency_version` | No | Installed version of the affected package. | | `state` | No | `open` (default), `dismissed`, or `fixed`. | | `transitivity` | No | `direct` or `transitive`. | | `source` | No | The scanner that reported the finding (e.g. `snyk`). Max 64 characters. Stored on the finding and returned as `source.scanner` when you read it back; filterable in the triage list with the `source:` filter and with `konvu finding list --source snyk`. | ### Response You get `201 Created` with a per-item breakdown, even when some items are rejected: ```json { "repository": { "repository_id": "...", "vcs_repo_url": "github:your-org/your-repo", "vcs_ref": "main" }, "created_count": 1, "updated_count": 0, "accepted_unmapped_count": 0, "rejected_count": 0, "results": [ { "index": 0, "vulnerability_id": "CVE-2021-23337", "manifest_location": "package.json", "status": "created", "finding_id": "...", "reason": null } ] } ``` Each item's `status` is one of: * `created` / `updated` — finding stored. Re-sending the same finding updates it instead of creating a duplicate (deduplicated on repository, ref, manifest, vulnerability, and dependency — the same finding on a branch and on a tag counts as two findings), so it's safe to POST your full set on every scan. An update replaces every optional field from the new payload, `source` included: resubmitting with a different `source` renames the finding's scanner, and resubmitting **without** `source` clears the label back to `api`. Send it on every submission. Two scanners reporting the same dependency and vulnerability in the same manifest are the same finding, and it carries whichever `source` arrived last — submit them under one label if you want them grouped. Findings you stop sending are **not** auto-closed — send `state: "fixed"` or `"dismissed"` to close one. * `accepted_unmapped` — stored, but the CVE/GHSA isn't in Konvu's vulnerability database yet. It enters triage automatically after the next database refresh. * `rejected` — not stored; `reason` explains why (for example, an ecosystem that couldn't be resolved or an unsupported `state`). Batches are capped at 1000 findings per request — larger requests are rejected with `422` before anything is stored. The complete schema is in the [API reference](https://api.konvu.com/redoc). {% hint style="info" %} Submitted findings appear in the triage list right away, but only receive an AI exploitability assessment once the repository is [connected](/konvu/get-started/connect-your-environment.md) and Konvu has scanned it — assessment reads your source code, not just the finding metadata. {% endhint %} ### Verify the source label The response above doesn't echo `source`, so read the finding back to confirm the label stuck: `GET /sca_findings` returns it as `source.scanner`, and the same value filters the list. ```bash curl -H "Authorization: Bearer $KONVU_API_KEY" \ "https://api.konvu.com/sca_findings?source=snyk" ``` The CLI equivalent is [`konvu finding list --source snyk`](/konvu/reference/cli.md#konvu-finding-list). The filter also accepts the ingestion channel, so `?source=api` still returns everything you pushed through this API — but it is broader than a label, matching every API-submitted finding whatever its `source`. A label you never submitted returns no results rather than an error, unless it happens to be one of Konvu's own channel names (`snyk`, `dependabot`, `semgrep`, `csv`, `endor_labs`, `arnica`, `api`, `gitlab_dependency_scanning`). In the triage list, the `source:` dropdown offers your label itself — labelled findings are listed under it, not under "API". The scanner icon on the finding still shows the ingestion channel rather than your label; `source.source_name` and `source.provenance` stay `api`. ## What happens next After connecting a scanner, Konvu runs an initial sync to import all open findings. From there: 1. [**Connect your environment**](/konvu/get-started/connect-your-environment.md) -- Link your source code (GitHub or GitLab) so Konvu can analyze your codebase for exploitability context. 2. [**Triage findings**](/konvu/triage-and-remediation/exploitability-assessment.md) -- Review Konvu's AI-driven assessments to separate exploitable vulnerabilities from false positives. --- # 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.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.