> 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/csv-import.md). # CSV Import Import SCA findings from any scanner into Konvu by uploading a CSV file on the Integrations page. Upload a CSV file to import open-source dependency findings (SCA) from a scanner Konvu doesn't integrate with, or from a one-off export. Each row is one vulnerability in one dependency, located at a repository, branch, and manifest path. Konvu assesses imported findings the same way it assesses findings from a connected scanner. CSV import brings in SCA findings only. It does not import SAST, container, or secret findings. It does not read severity or state from the file either: severity comes from Konvu's vulnerability database, and every row is imported as open. For pentest reports, SARIF exports, or findings from AI code security tools, use [External Reports](/konvu/get-started/bring-in-findings/external-reports.md). To send findings from a pipeline after every scan, use the [API](/konvu/get-started/bring-in-findings.md#import-scanner-findings-with-the-api) or `konvu finding submit` instead. {% hint style="warning" %} Connect the repositories first. An imported finding appears in Triage and gets an exploitability assessment only when its repository is [connected to Konvu](/konvu/get-started/connect-your-environment/source-code.md) and Konvu has scanned it. Findings for any other repository are stored but stay hidden. {% endhint %} ## Prerequisites * [Source code connected](/konvu/get-started/connect-your-environment/source-code.md) for every repository in the file, with Konvu's first scan complete. * A comma-separated, UTF-8 file under 10 MB. ## Prepare the CSV file Start from the template. Open **Integrations**, select **CSV Upload**, and click **Download template**. You get `csv_import_template.csv` with every column and two example rows. ```csv external_identifier,repository_url,branch,manifest_location,cve_id,dependency_name,dependency_version,dependency_ecosystem,transitivity FIND-0001,https://github.com/acme/web-app,main,package-lock.json,CVE-2021-23337,lodash,4.17.20,npm,transitive FIND-0002,https://github.com/acme/web-app,main,services/api/pom.xml,CVE-2021-44228,org.apache.logging.log4j:log4j-core,2.14.1,maven,direct FIND-0003,https://github.com/acme/billing,main,backend/requirements.txt,CVE-2023-32681,requests,2.25.1,pypi, ``` | Column | Required | Notes | | ---------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `external_identifier` | Yes | Your ID for the finding, such as the scanner's issue ID. Shown on the finding as its CSV source reference. Keep it unique per repository within a file. | | `repository_url` | Yes | GitHub or GitLab repository URL, such as `https://github.com/acme/web-app` or `github:acme/web-app`. Point at the repository itself, with no trailing slash. | | `branch` | Yes | Branch the finding applies to. `main`, `origin/main`, and `refs/heads/main` are equivalent. For a tag, use `refs/tags/1.2.0`. | | `manifest_location` | Yes | Path to the manifest or lockfile from the repository root, such as `package.json` or `services/api/pom.xml`. Lockfiles map to their manifest: `package-lock.json` to `package.json`, `poetry.lock` to `pyproject.toml`, `go.sum` to `go.mod`. | | `cve_id` | Yes | CVE or GHSA identifier, one per row. Matching is case-sensitive: `CVE-2021-23337`, not `cve-2021-23337`. | | `dependency_name` | Yes | Affected package, using the ecosystem's canonical name. For Maven, use `groupId:artifactId`. | | `dependency_version` | Yes | Installed version of the package. | | `dependency_ecosystem` | Yes | Lowercase package type: `npm`, `maven`, `pypi`, `golang`, `gem`, `nuget`, `composer`, or `cargo`. | | `transitivity` | No | `direct` or `transitive`. Leave it empty when you don't know. | Fill every required column on every row. Konvu checks that the headers are present, not that each value is set. File format rules: * Header names are exact and case-sensitive. Column order doesn't matter, and Konvu ignores extra columns. * Separate values with commas. A semicolon-delimited file fails the column check. Quote any value that contains a comma. * Save as UTF-8 without a byte-order mark (BOM). Excel's **CSV UTF-8** format adds one, which makes Konvu misread the first header. Remove it before uploading, or export from a tool that doesn't add it. * Keep the file under 10 MB. There is no row limit. ## Upload the file 1. Open **Integrations** and select **CSV Upload**. If you have uploaded a CSV before, this opens the **CSV** page. Click **Add connection** there. 2. Under **Select CSV file**, choose your `.csv` file. 3. Under **Name integration**, keep the name taken from the file name or enter your own. Names are 3 to 100 characters of letters, numbers, underscores, hyphens, dots, and single spaces. A name copied from a file like `export (1).csv` is rejected until you remove the parentheses. 4. Click **Import findings**. Konvu checks the file, then imports it in the background. The connection's status on the **CSV** page shows **In Progress**, then **Success** or **Failed**. ## After the import * Each upload becomes its own connection on the **CSV** page, listing the repositories in the file. * Imported findings on scanned repositories enter the normal [assessment flow](/konvu/triage-and-remediation/exploitability-assessment/how-assessments-work.md). * In Triage, set the `source:` filter to **CSV** to see them. Each finding shows your `external_identifier` as its source reference. * Triage groups findings by manifest and vulnerability. When the repository, branch, and manifest path match what a connected scanner reports, Triage shows one finding with both sources. * Konvu writes nothing back for CSV findings. There is no source tool to update. ### Update or remove an import A CSV upload is a snapshot. A new upload adds a new connection. It does not update or close findings from earlier uploads, and uploading the same rows again adds a second CSV source to the same finding. To replace an import, upload the new file, then delete the old connection: on the **CSV** page, open the connection's menu, select **Delete Integration**, and type the connection name to confirm. Deletion cannot be undone. For findings that change with every scan, use the [API](/konvu/get-started/bring-in-findings.md#import-scanner-findings-with-the-api). It updates existing findings instead of duplicating them and accepts `fixed` and `dismissed` states. ## Troubleshooting Upload errors appear in a notification titled **Could not upload CSV integration**. | Message contains | Cause and fix | | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `CSV file size must be less than 10MB` | Split the file into several uploads. | | `CSV file must be UTF-8 encoded` | Re-save the file as UTF-8. | | `CSV must contain columns` | A required header is missing or misspelled, the file uses semicolons, or it starts with a BOM. Compare your header row with the template. | | `CSV file is empty` | The file has a header row but no findings. | Konvu does not report rows it skips. If the import shows **Success** but findings are missing from Triage, check: * **The repository is connected and scanned.** Findings on other repositories are stored but hidden. * **The vulnerability ID exists in Konvu's database.** Rows with an unknown `cve_id` are skipped. Check the case of the prefix. * **The branch and manifest path match your repository.** A path that doesn't exist on that branch won't line up with what Konvu scanned. --- # 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/csv-import.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.