I had a lengthy talk with a dynamic analysis results producer yesterday who noted that SARIF is very thin as far as expressing stack-based information. He noted that his tool collects a series of execution events, each of which has an associated stack. This chain of events is what's examined to produce a scan result.

One of the events needs an identifier, some user-facing text, a stack and a bundle of state. Hm. Sounds a lot like a code flow, except that we have a stack (collected at runtime) rather than a speculative physical location provided by a static checker.

We have two directions we could go: 1) create dynamicEventFlows or some equivalent, modeled like code flows (they would be an array of arrays of dynamicEventFlows). Each dynamic event contains an identifier, message, stack, state and a thread id (or the thread id is associated with an array, 2) just add stacks and a 'kind' designator to code flows.

Note that doing either option will allow us to drop stacks from the result object. i.e., you could simply use code flows for this (and not populate any other information).

This suggestion also resolves a long-standing thought we've had around how to model exceptions. Now you populate code flow with a single item, add the exception stack, note the kind as 'unhandledException' and that's it.