OASIS Static Analysis Results Interchange Format (SARIF) TC

Michael provided feedback on the change draft that restores threadFlowLocation.kind (Issues #194 and #202 , pushed from TC #24 to TC #25 for lack of time):   Documents/ChangeDrafts/Active/sarif-v2.0-issues-194-202-threadFlowLocation-changes.docx   He requested some additional values:   "applicationEntryPoint" : This location is an entry point to the application. "applicationExit" : This location is a point of exit from the application. "branchFalse" : At this location, a branch in the execution path occurred because the branch condition evaluated to false . "branchTrue" : At this location, a branch in the execution path occurred because the branch condition evaluated to true . NOTE: Plain “branch” still exists. "exceptionFilter" : At this location, an exception filter was executed.   Remember, the list is not meant to be exhaustive. The spec explicitly permits you to use any value you want if the defined values don’t meet your needs.   Thanks, Larry

I’d suggest making the first two concepts more generic. Entry points may occur at the driver or dynamic linked library level, for example, for some checkers. The following names might help make these a bit more general purpose   entryPoint unloadOrExit   ‘terminate’ might be another option.       From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Monday, October 1, 2018 2:54 PM To: 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org> Subject: [sarif] More threadFlowLocation.kind values   Michael provided feedback on the change draft that restores threadFlowLocation.kind (Issues #194 and #202 , pushed from TC #24 to TC #25 for lack of time):   Documents/ChangeDrafts/Active/sarif-v2.0-issues-194-202-threadFlowLocation-changes.docx   He requested some additional values:   "applicationEntryPoint" : This location is an entry point to the application. "applicationExit" : This location is a point of exit from the application. "branchFalse" : At this location, a branch in the execution path occurred because the branch condition evaluated to false . "branchTrue" : At this location, a branch in the execution path occurred because the branch condition evaluated to true . NOTE: Plain “branch” still exists. "exceptionFilter" : At this location, an exception filter was executed.   Remember, the list is not meant to be exhaustive. The spec explicitly permits you to use any value you want if the defined values don’t meet your needs.   Thanks, Larry

I was wondering in general why we changed our mind regarding the kind property (looks like I missed the discussion) – if I recall correctly, at the face-to-face meeting we agreed not to use this property.   Bu since we are working on the list, I am curious about why we have ‘sanitizer’ kind on the list, considering it will probably not be part of any result (result won’t be generated in this case). Or is the idea that it might be part of some informational result? On the other hand, why not add a ‘passthrough’ kind to indicate that the taint was propagated at this location. Also, what about something like ‘endScope’ to indicate the end of the variable scope? Finally, do we need a separate kind for lambda?   k   From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org] On Behalf Of Michael Fanning Sent: Monday, October 01, 2018 3:35 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org> Subject: RE: [sarif] More threadFlowLocation.kind values   I’d suggest making the first two concepts more generic. Entry points may occur at the driver or dynamic linked library level, for example, for some checkers. The following names might help make these a bit more general purpose   entryPoint unloadOrExit   ‘terminate’ might be another option.       From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Monday, October 1, 2018 2:54 PM To: 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org > Subject: [sarif] More threadFlowLocation.kind values   Michael provided feedback on the change draft that restores threadFlowLocation.kind (Issues #194 and #202 , pushed from TC #24 to TC #25 for lack of time):   Documents/ChangeDrafts/Active/sarif-v2.0-issues-194-202-threadFlowLocation-changes.docx   He requested some additional values:   "applicationEntryPoint" : This location is an entry point to the application. "applicationExit" : This location is a point of exit from the application. "branchFalse" : At this location, a branch in the execution path occurred because the branch condition evaluated to false . "branchTrue" : At this location, a branch in the execution path occurred because the branch condition evaluated to true . NOTE: Plain “branch” still exists. "exceptionFilter" : At this location, an exception filter was executed.   Remember, the list is not meant to be exhaustive. The spec explicitly permits you to use any value you want if the defined values don’t meet your needs.   Thanks, Larry

We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their tool s UI to put icons in the margin indicating (for example), that a true branch was taken.   You make an interesting point about sanitizer : presumably, if a datum passes through a sanitizer, it will not trigger a result for use of tainted data . But I can imagine a scenario where two pieces of tainted data enter the system and only one is sanitized

Also, yes, as you noted, some results are purely informational (result.level == note ) or explicitly denote a success (result.level == pass ), so again sanitizer is useful.
 
As for passthrough : we do have usage value, meaning at this location, data is used . But we can certainly consider adding taintedDataUsage if you would find it useful.
 
We can also add endScope if you would find it useful.
 


From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast)
Sent: Tuesday, October 2, 2018 9:04 AM
To: 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; Michael Fanning <Michael.Fanning@microsoft.com>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] More threadFlowLocation.kind values


 
We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their tool s UI to put icons in the margin indicating (for example), that a true branch was taken.
 
You make an interesting point about sanitizer : presumably, if a datum passes through a sanitizer, it will not trigger a result for use of tainted data . But I can imagine a scenario where two pieces of tainted data enter the system and
only one is sanitized

Yes, passthrough and endScope would be useful to us. The former because we differentiate between just usage (e.g. variable was assigned null and then used, that is, dereferenced) and propagation of taint.
The latter is useful for explaining why we report memory and resource leaks.
 
As for lambda , it might be useful to separate it from just a call , but I guess not absolutely necessary.
 
k
 


From: Larry Golding (Myriad Consulting Inc) [mailto:v-lgold@microsoft.com]

Sent: Tuesday, October 02, 2018 12:42 PM
To: 'O'Neil, Yekaterina Tsipenyuk' <katrina@microfocus.com>; Michael Fanning <Michael.Fanning@microsoft.com>; 'OASIS SARIF TC Discussion List' <sarif@lists.oasis-open.org>
Subject: RE: [sarif] More threadFlowLocation.kind values


 
Also, yes, as you noted, some results are purely informational (result.level == note ) or explicitly denote a success (result.level == pass ), so again sanitizer is useful.
 
As for passthrough : we do have usage value, meaning at this location, data is used . But we can certainly consider adding taintedDataUsage if you would find it useful.
 
We can also add endScope if you would find it useful.
 


From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org >
On Behalf Of Larry Golding (Comcast)
Sent: Tuesday, October 2, 2018 9:04 AM
To: 'O'Neil, Yekaterina Tsipenyuk' < katrina@microfocus.com >; Michael Fanning < Michael.Fanning@microsoft.com >; 'OASIS SARIF TC Discussion List' < sarif@lists.oasis-open.org >
Subject: RE: [sarif] More threadFlowLocation.kind values


 
We changed our mind because (Paul or Michael, correct me if I am wrong) Grammatech needed a property that could guide their tool s UI to put icons in the margin indicating (for example), that a true branch was taken.
 
You make an interesting point about sanitizer : presumably, if a datum passes through a sanitizer, it will not trigger a result for use of tainted data . But I can imagine a scenario where two pieces of tainted data enter the system and
only one is sanitized