Change draft for #161 (dynamic execution events)

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

I pushed a change draft for Issue #161, “Expand code flows to represent dynamic execution events”:

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-149-nested-graphs.docx

 

I will move its adoption at TC #17 on May 16^th.

 

This is a feature request from the creators of a dynamic analysis tool that runs on a web server and observes whether the server code is performing an insecure operation (such as acting on tainted data that has not been sanitized). This tool emits a sequence of “events”, each associated with a code location, for example “tainted data enters the system”, “tainted data is used”. This sequence of events is reminiscent of a code flow, but this tool needs to record the stack trace for each location. To accommodate them, we introduce codeFlowLocation.stack.

 

Note: a static analysis tool could equally well make use of this feature, if it keeps track of the call trace as it simulates the execution of the code.

 

This tool also wants to associate a “kind” with each location (as in my examples above, “tainted data enters the system”). You may recall that we recently removed the properties codeFlowLocation.kind and codeFlowLocation.taintKind, because we despaired of being able to exhaustively enumerate the kinds of semantics a location might have. The new, improved “kind” is subtly different. It has no pre-defined enumerated values. Its meaning is entirely up to the tool that produced it. A SARIF consumer that hopes to use it needs to examine the run.tool property to see if it understands how this tool uses kind.

 

Here is the entire change:

 

3.34.4 [codeFlowLocation.]stack property

A codeFlowLocation object MAY contain a property named stack whose value is a stack object (§3.32) that represents the call stack leading to this location.

3.34.5 [codeFlowLocation.]kind property

A codeFlowLocation object MAY contain a property named kind whose value is a string that describes the meaning of this location. The interpretation of kind depends on the tool that produced the log file. A SARIF consumer that wishes to take action based on kind SHALL examine run.tool (§3.11.7, §3.12) to determine if it (the consumer) knows how to interpret the kind values produced by that tool.

A SARIF producer MAY provide additional kind-dependent information by populating the codeFlowLocation.properties with properties whose names and values depend on kind. A SARIF consumer that knows how to interpret kind for this tool MAY use this additional information.

EXAMPLE:

"kind": "taintedDataSource"

 

Thanks,

Larry