Back to integrations
    SAST

    CodeQL integration

    Check whether each CodeQL security alert is exploitable, and dismiss the false positives in GitHub code scanning.

    Integration details

    Primary category

    Static Application Security Testing

    Sync direction

    CodeQL ↔ Konvu

    Konvu reads CodeQL alerts from GitHub code scanning once a day and on demand. Dismissals and reopens made in Konvu are applied to the alert in GitHub.

    Status

    Available

    Which CodeQL alerts are real vulnerabilities?

    CodeQL finds data flows that look dangerous. Whether one can be exploited often depends on checks and context outside the query. Konvu imports CodeQL security alerts from GitHub code scanning, investigates each one in the full repository, and returns a verdict with evidence. When your team dismisses an alert in Konvu, Konvu dismisses it in GitHub too.

    CodeQL findings Konvu analyzes

    SAST

    CodeQL in GitHub code scanning

    Security alerts only: alerts with a security severity, a CWE, or a security tag.

    Not imported today

    • Alerts from other tools that upload SARIF to code scanning
    • CodeQL alerts without a security classification

    Access and setup

    Through the Konvu GitHub App, with SAST import turned on for the installation.

    To read findings

    • Metadata: read
    • Contents: read
    • Code scanning alerts: read

    To write back

    • Code scanning alerts: write, to dismiss and reopen alerts from Konvu

    How Konvu investigates CodeQL findings

    What Konvu receives

    The CodeQL alert: the query, the source and sink it matched, and the path between them.

    What Konvu checks

    • Whether a request, file, or message an attacker controls can supply the source.
    • Validation, allowlists, encoding, or framework behavior along the path that the query does not model.
    • Whether the flagged code runs in production.

    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.

    Illustrative example

    A path injection alert from CodeQL

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

    1. 1

      Scanner finding

      CodeQL reports "Uncontrolled data used in path expression" in an Express route that serves report files: req.params.name flows into fs.readFile.

    2. 2

      Application context

      Before the read, the route checks the name against the list of report names in the reports table. An internal job is the only writer to that table.

    3. 3

      Investigation

      Konvu follows req.params.name from the route to fs.readFile. The handler returns 404 for any name not in the list, so only known file names reach the read. It then confirms that request handlers never write to the reports table.

    4. 4

      Verdict

      False positive. Path traversal needs a name outside the list, and those never reach fs.readFile.

    5. 5

      Evidence

      The route, the allowlist check and where its values come from, and the path from parameter to file read.

    6. 6

      Where it ends up

      An engineer dismisses the finding in Konvu, and Konvu dismisses the alert in GitHub code scanning. The reasoning stays on the finding in Konvu.

    Writeback and controls

    What changes in CodeQL

    • Dismissing a finding in Konvu dismisses the code scanning alert in GitHub.
    • Reopening the finding in Konvu reopens the alert.

    Who triggers it

    A person. Konvu changes an alert only when someone on your team dismisses or reopens the finding in Konvu.

    What stays with your team

    • Changing or disabling the CodeQL query itself.
    • Alert severity in GitHub, which Konvu does not change.

    Evaluation questions