Veracode integration
Send Veracode SCA and Static Analysis results to Konvu for an exploitability verdict with evidence, through the Konvu API or a report upload.
Integration details
Primary category
Software Composition Analysis
Sync direction
Veracode → Konvu API
No native connector. Your pipeline sends Veracode 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 Veracode flaws can an attacker reach?
Veracode reports vulnerable libraries through Veracode SCA and code flaws through Static Analysis. Konvu has no native connector for Veracode, so your pipeline sends the results. Library findings go through the Konvu API and get an exploitability verdict with evidence. Static Analysis results go up as a JSON export, which Konvu splits into one report per flaw, triages, and reproduces against your code.
Veracode findings Konvu analyzes
SCA
Veracode SCA
Vulnerable libraries with a CVE, sent through POST /sca_findings or konvu finding submit with the repository and manifest file.
SAST
Veracode Static Analysis
Flaws from a policy scan, sandbox scan, or Pipeline Scan, exported as JSON and uploaded as a report.
Not imported today
- Veracode SCA findings without a CVE or GHSA ID
Access and setup
Create an organization API key in Konvu and call it from the pipeline step that runs the Veracode scan, or from a script that pulls results from the Veracode APIs. Konvu never connects to Veracode.
To send findings
- A Konvu API key, scoped to your organization
- For SCA findings: the CVE or GHSA ID, the library, the manifest file, and the repository URL
- For Static Analysis: the JSON export and the repository it applies to
To write back
No access to Veracode 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.
- When automated triage is enabled for your organization, Konvu splits an uploaded export into one report per finding and links each back to the file it came from.
How Konvu investigates Veracode findings
What Konvu receives
For SCA: the CVE, library, version, manifest file, and repository. For Static Analysis: each flaw copied verbatim from the export, with its CWE and location.
What Konvu checks
- For libraries, whether the vulnerable code is shipped and called, and whether the conditions the CVE needs are present.
- For Static Analysis flaws, whether the claim is plausible, in scope, and not already reported.
- For Static Analysis flaws, whether the flaw can be triggered in an isolated sandbox running your code.
What decides the verdict
Library findings come back exploitable, false positive, or inconclusive, with the reasoning behind each. Static Analysis reports that pass triage are reproduced, and end as Reproduced, False positive, Hardening, or Inconclusive.
Illustrative example
A commons-text finding from Veracode SCA
A made-up service, written to show how an investigation reads. Not a customer result.
- 1
Scanner finding
Veracode SCA reports CVE-2022-42889, known as Text4Shell, in Apache Commons Text 1.9 for a Java service. Versions 1.5 through 1.9 can run code when StringSubstitutor interpolates untrusted input with its default lookups.
- 2
Application context
The service depends on Commons Text for WordUtils, which it uses to capitalize display names.
- 3
Investigation
Konvu confirms commons-text 1.9 ships with the service, then searches for StringSubstitutor and StringLookupFactory. Neither appears anywhere in the code or its configuration.
- 4
Verdict
False positive. The interpolation feature the exploit needs is never called.
- 5
Evidence
The installed version, the WordUtils calls the service makes, and the search showing no use of StringSubstitutor.
- 6
Where it ends up
The finding is marked false positive in Konvu with its evidence. Konvu does not write to Veracode, so the team records a mitigation there if their policy requires one.
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.
- Reproduced Static Analysis reports come with a fix prompt your coding agent can apply directly.
- If your Veracode SCA findings also reach you through ArmorCode, Konvu can dismiss them there and add its assessment as a comment and tag.
- 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. Triage and reproduction of Static Analysis reports start on their own when automation is enabled for your organization.
What stays with your team
- Mitigation proposals and approvals in Veracode.
- Closing a finding in Konvu once it is fixed, by sending it again with state "fixed".
Evaluation questions
The technical detail
How Veracode compares
More integrations
View all
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
GitHub
Prioritize GitHub CodeQL and Dependabot alerts by adding exploit context to each finding.
- SAST
- SCA
- Ticketing & Messaging
GitLab
Add exploitability analysis to GitLab's built-in SAST and SCA pipeline findings.
- SCA
- SAST
- Ticketing & Messaging
Semgrep
Find out which Semgrep Supply Chain and Semgrep Code findings are exploitable, with the evidence behind each verdict.
- SAST
- SCA