Flows in Sarif are syntactically correct but appear to not follow the standard's intentions.

[nleach999]

Description

CxFlow consolidates the same issue occurring in a single file to one issue in all bug trackers including Sarif. Sarif does support this.

The problem is that we consolidate all flows into one threadFlowObject (Section 3.37) by restarting the index element in the threadFlows[0].locations[0].location:

There are two SQLi vulnerabilities, each flow can be seen in the UI:

Expected Behavior

Section 3.37.1 of the Sarif 2.1.0 standard describes the threadFlow object as:

A thread flow is a sequence of code locations that specify a possible path through a single thread of execution such as an operating system thread or a fiber.

While there is not a validation error for the Sarif, the standard wording appears to indicate there should be one threadFlow object per result flow. Consumers of Sarif are unlikely to incorporate logic to extract flows by reading the index field to recognize that 0 indicates a new flow when the structure of the JSON would usually be used to indicate separate flows.

Actual Behavior

One single threadFlowLocation object is created to contain all flows for a result with the index field as the sole indicator that there are multiple flows.

Reproduction

This script was executed using the attached XML to produce the attached Sarif.

java -Xms512m -Xmx2048m -jar cx-flow-1.6.45-java11.jar --parse \
    --app=Checkmarx \
    --cx-flow.bug-tracker-impl=Sarif \
    --cx-flow.bug-tracker=Sarif \
    --cx-flow.filter-severity=High,Medium,Low,Information \
    --sarif.file-path=./offline-cx.sarif \
    --checkmarx.offline=true \
    --logging.level.com=OFF \
    --logging.level.org=OFF \
    --logging.level.javax=OFF \
    --f=$1

Environment Details

CxFlow 1.6.45
Java 17

offline-cx.sarif.json
SimplyVulnerable-[master].xml.txt

[satyamchaurasiapersistent]

Fixed in Release 1.7.04