Trivy integration
Send Trivy repository scan results to Konvu through the API or CLI and get an exploitability verdict for each vulnerable dependency.
Integration details
Primary category
Software Composition Analysis
Sync direction
Trivy → Konvu API
No native connector. Your pipeline sends Trivy repository scan results to the Konvu API after each scan. Verdicts go out as fix pull requests, Slack alerts, and through the Konvu API.
Status
Available
Which Trivy results are exploitable in your code?
Trivy scans repositories, filesystems, and images, and lists every known vulnerability in what it finds. Konvu has no native connector for Trivy. Your pipeline sends the dependency results from a repository or filesystem scan to the Konvu API, and Konvu checks each one against your code and returns a verdict with evidence.
Trivy findings Konvu analyzes
SCA
Trivy filesystem and repository scans
Vulnerable dependencies from the lockfiles and manifests Trivy found, sent through POST /sca_findings or konvu finding submit. The target file on each result maps to the manifest field.
Not imported today
- Image scan results. The findings API does not accept container findings; for images in Amazon ECR, connect AWS Inspector instead.
- Misconfiguration, secret, and license results
Access and setup
Run Trivy with JSON output in CI, turn each vulnerability into a finding, and send it with an organization API key. Konvu never connects to Trivy.
To send findings
- A Konvu API key, scoped to your organization
VulnerabilityIDas the CVE or GHSA IDPkgNameas the packageInstalledVersionas the installed versionTargetas the manifest file
To write back
No access to Trivy is needed.
- Sending the same findings again updates them instead of creating duplicates, so the full result set can go up after every scan. Findings you stop sending stay open until you send them again with state "fixed" or "dismissed".
- Konvu assesses a dependency finding once its repository is connected through GitHub or GitLab. Until then it appears in triage without a verdict.
How Konvu investigates Trivy findings
What Konvu receives
The vulnerability, package, installed version, and manifest file from Trivy's output, plus the repository and branch.
What Konvu checks
- Whether the vulnerable package is installed and shipped, or only used in development and tests.
- Whether the vulnerable function is called, and whether input an attacker controls reaches it.
- Whether your runtime and configuration match what the vulnerability needs.
What decides the verdict
Konvu returns exploitable, false positive, or inconclusive, with the reasoning behind it: the code it read, the conditions it tested, and what settled the call. When the answer depends on something only your team knows, Konvu asks a question instead of guessing.
Illustrative example
A requests finding from a Trivy repository scan
A made-up service, written to show how an investigation reads. Not a customer result.
- 1
Scanner finding
Trivy reports CVE-2023-32681 in requests 2.28.1 from a Python service's requirements.txt. Before 2.31.0, requests can leak Proxy-Authorization headers to the destination server when it follows a redirect to HTTPS.
- 2
Application context
The leak only matters when requests is configured to use a proxy with credentials.
- 3
Investigation
Konvu checks every place the service creates a requests session or makes a call. None passes proxies, and the deployment configuration sets no HTTP_PROXY or HTTPS_PROXY variables.
- 4
Verdict
False positive. There are no proxy credentials to leak.
- 5
Evidence
The installed version, the requests calls Konvu reviewed, and the proxy settings it checked in code and configuration.
- 6
Where it ends up
The finding is marked false positive in Konvu with its evidence. Upgrading requests can wait for the normal update cycle.
Writeback and controls
Where results go
- Exploitable dependency findings can become a fix pull request in GitHub or GitLab, opened automatically if you turn that on for the repository.
- Exploitable findings can be posted to Slack, so the team hears about them without opening Konvu.
- Every verdict and its evidence can be pulled into your own tools through the Konvu API or CLI.
Who triggers it
Your pipeline decides when results reach Konvu.
What stays with your team
- Closing a finding in Konvu once it is fixed, by sending it again with state "fixed".
- Image scanning. Container results stay in Trivy unless the image is in Amazon ECR and AWS Inspector is connected.
Evaluation questions
The technical detail
More integrations
View all
Grype
Send Grype directory and SBOM scan results to Konvu through the API or CLI for an exploitability verdict on each vulnerable package.
- SCA
- Container Security
Snyk
Find out which Snyk Open Source and Snyk Code findings are exploitable in your code, with the evidence behind each verdict.
- SCA
- SAST
- Container Security
Arnica
Add exploitability verdicts with evidence to Arnica SCA and SAST findings, and send approved SCA dismissals back to Arnica.
- SCA
- SAST
- ASPM
Black Duck
Get an exploitability verdict with evidence for Black Duck Polaris SCA findings and Coverity SAST findings.
- SCA
- SAST
Checkmarx
Send Checkmarx One SCA and SAST results to Konvu for an exploitability verdict with evidence, through the Konvu API or a report upload.
- SAST
- SCA
Dependabot
Get an exploitability verdict for each Dependabot alert, and dismiss the false positives in GitHub with the evidence linked.
- SCA