Back to integrations
    SASTSCA

    Checkmarx integration

    Send Checkmarx One SCA and SAST 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

    Checkmarx → Konvu API

    No native connector. Your pipeline sends Checkmarx 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 Checkmarx results are worth a developer's time?

    Checkmarx One reports vulnerable dependencies and risky code paths across your applications. Konvu has no native connector for Checkmarx, so your pipeline sends the results after each scan. Dependency findings go through the Konvu API and get an exploitability verdict with evidence. SAST results go up as a SARIF or JSON export, which Konvu splits into one report per finding, triages, and reproduces against your code.

    Checkmarx findings Konvu analyzes

    SCA

    Checkmarx SCA

    Vulnerable dependencies, sent through POST /sca_findings or konvu finding submit with the repository and manifest file for each one.

    SAST

    Checkmarx SAST

    Code findings exported as SARIF or JSON and uploaded as a report. Each finding becomes its own report.

    Not imported today

    • KICS infrastructure-as-code results
    • Checkmarx container scan results

    Access and setup

    Create an organization API key in Konvu and call it from the pipeline step that runs the Checkmarx scan. Konvu never connects to Checkmarx, so no Checkmarx credentials are shared with Konvu.

    To send findings

    • A Konvu API key, scoped to your organization
    • For SCA findings: the CVE or GHSA ID, the package, the manifest file, and the repository URL
    • For SAST results: the export file and the repository it applies to

    To write back

    No access to Checkmarx 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 Checkmarx findings

    What Konvu receives

    For SCA: the vulnerability, package, version, manifest file, and repository. For SAST: each finding copied verbatim out of the export.

    What Konvu checks

    • For SCA, whether the vulnerable package is installed, whether the vulnerable function is reachable, and whether your configuration matches what the vulnerability needs.
    • For SAST, whether the finding is plausible and in scope, and whether another report already covers it.
    • For SAST, whether the flaw can be triggered, by reproducing it in an isolated sandbox against your code.

    What decides the verdict

    Dependency findings come back exploitable, false positive, or inconclusive, with the reasoning behind each. SAST reports that pass triage are reproduced, and end as Reproduced, with the proof, or as False positive, Hardening, or Inconclusive, with the evidence.

    Illustrative example

    A reflected XSS result from Checkmarx SAST

    A made-up service, written to show how an investigation reads. Not a customer result.

    1. 1

      Scanner finding

      A Checkmarx SAST export includes a Reflected XSS result in a Java controller: the q request parameter flows into the search results view.

    2. 2

      Application context

      The view is a Thymeleaf template that renders q with th:text, which HTML-escapes its output. No template in the path uses unescaped output.

    3. 3

      Investigation

      Konvu splits the export, so this result becomes its own report. It passes triage. Konvu then runs the application in a sandbox and sends search requests with script payloads in q. Every payload comes back escaped in the page.

    4. 4

      Verdict

      False positive. The template engine escapes the value, so the payload never runs.

    5. 5

      Evidence

      The requests Konvu sent, the escaped responses, and the template line that renders q.

    6. 6

      Where it ends up

      The report is marked false positive in Konvu with the proof attached. Konvu does not write to Checkmarx, so the team marks the result there. Had it reproduced, Konvu would give a fix prompt for your coding agent rather than a pull request.

    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 SAST reports come with a fix prompt your coding agent can apply directly.
    • If your Checkmarx 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 then start on their own when automation is enabled for your organization.

    What stays with your team

    • Triage in Checkmarx One.
    • Closing a finding in Konvu once it is fixed, by sending it again with state "fixed".

    Evaluation questions