Grype integration
Send Grype directory and SBOM scan results to Konvu through the API or CLI for an exploitability verdict on each vulnerable package.
Integration details
Primary category
Software Composition Analysis
Sync direction
Grype → Konvu API
No native connector. Your pipeline sends Grype matches to the Konvu API after each scan. Verdicts go out as fix pull requests, Slack alerts, and through the Konvu API.
Status
Available
Which Grype matches can be exploited?
Grype matches the packages in a directory, SBOM, or image against vulnerability data. Konvu has no native connector for Grype. Your pipeline sends the matches from a directory or SBOM scan of a repository to the Konvu API, and Konvu decides whether each one can be exploited in your code.
Grype findings Konvu analyzes
SCA
Grype directory and SBOM scans
Vulnerable packages matched in a repository checkout or its SBOM, sent through POST /sca_findings or konvu finding submit. Each match needs the manifest file its package comes from.
Not imported today
- Image scan results. The findings API does not accept container findings; for images in Amazon ECR, connect AWS Inspector instead.
Access and setup
Run Grype with JSON output in CI, turn each match into a finding, and send it with an organization API key. Konvu never connects to Grype.
To send findings
- A Konvu API key, scoped to your organization
- For each match: the CVE or GHSA ID, the package name and version, and the manifest file
artifact.locationsgives the path of the file each package came from
To write back
No access to Grype 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 Grype findings
What Konvu receives
The match: vulnerability, package, version, and manifest file, plus the repository and branch it was scanned from.
What Konvu checks
- Whether the matched package is really the one installed, at the version Grype reported.
- Whether the vulnerable function is called with input an attacker controls.
- 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 semver match from Grype
A made-up service, written to show how an investigation reads. Not a customer result.
- 1
Scanner finding
Grype matches CVE-2022-25883 against semver 7.3.8 in a Node.js service's package-lock.json. semver before 7.5.2 is open to a regular expression denial of service when new Range() parses untrusted input.
- 2
Application context
The service uses semver at startup to compare its own version with a minimum version read from its config file.
- 3
Investigation
Konvu finds every semver call in the service. Both inputs come from package.json and a config file shipped with the service. No request, message, or user field reaches semver.
- 4
Verdict
False positive. An attacker cannot supply the string that triggers the slow parse.
- 5
Evidence
The installed version, the two semver calls and where their inputs come from, and the search for other callers.
- 6
Where it ends up
The finding is marked false positive in Konvu with its evidence. The semver upgrade can ship with routine dependency updates.
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 matches reach Konvu.
What stays with your team
- Closing a finding in Konvu once it is fixed, by sending it again with state "fixed".
Evaluation questions
The technical detail
More integrations
View all
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
Trivy
Send Trivy repository scan results to Konvu through the API or CLI and get an exploitability verdict for each vulnerable dependency.
- SCA
- 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