[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [sarif] Asking for output of analysis tools that produce code paths
From: Larry Golding (Comcast) [mailto:larrygolding@comcast.net] Thanks Jim, that's very helpful! I uploaded your samples to the directory Tool Samples/SWAMP Tools in the repo and provided a README.md. Here are my takeaways from studying them: 1. cppcheckThe code paths in the cppcheck sample (lighttpd-1.4.45---ubuntu-16.04-64---cppcheck\results\assessment_report15.xml, line 4) are very simple. Only one of them (the first one, the “redundant assignment” error) has more than one location in the path. 2. clangIn the clang sample, I’ll need your help interpreting the contents of the .plist file. Those nested dict/key/array/dict/key… elements exceed my complexity limit 😊 I do see that the “previous event, next event” links in the HTML file can be synthesized from the information in the .plist file. But there are some strings in the HTML file (for example, “Within the expansion of the macro 'CONST_BUF_LEN'”) that don’t appear in the .plist file at all. Is the idea that you can tell clang to emit one format or the other, but it does not offer a single output format that is both as easy to parse as the .plist and as comprehensive as the HTML? After all that, I don’t see anything in either format that SARIF is missing, except possibly the extended_message in the .plist file. But I might find I’m mistaken when you guide me through the .plist format in more detail. 3. findbugs, spotbugsI’ll also appreciate your help interpreting this XML format. I assume that the BugInstance element is the equivalent of the SARIF result. BugInstance contains a sequence of Class, Method, and SourceLine elements, some of which contain nested elements, for example: BugInstance Class SourceLine Message Method SourceLine Message SourceLine Message I assume each of the top-level elements specifies a location along the code path, but I’m not sure what it means for some SourceLine elements to be nested in Method elements, and others not. Thanks again, Jim. I look forward to exploring this further during our meeting. The agenda has time specifically set aside to discuss codeFlows. Larry -----Original Message----- From: James A. Kupsch [mailto:kupsch@cs.wisc.edu] Sent: Monday, January 29, 2018 2:00 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; mikefan@microsoft.com Cc: Vamshi Basupalli <vamshi@cs.wisc.edu> Subject: Re: [sarif] Asking for output of analysis tools that produce code paths *** UW-Madison Mail System warning: attached executable file was renamed *** * * Attached to this message is an executable file or an archive that * contains an executable file. The attachment has been renamed for * your protection. * * The file was scanned by UW-Madison anti-virus scanners and no threat * was found. However, executable files should be treated with great * caution. It's possible for viruses to slip through undetected in * the minutes before anti-virus definitions are published. * * Please confirm with the sender that the file was sent intentionally, * and that the file is safe to run before renaming the file by * removing the "_renamed" from the end of the filename. * * For more information and support, please visit the following link: * * https://kb.wisc.edu/office365/page.php?id=6056 * *************************** end of warning ********************************* Attached are sample output from tools in the SWAMP that produce code paths. The location in the result files are below and are all relative to tool_results_with_paths after unzipping tool_results_with_paths.zip (the locations are also in the file tool_results_with_paths.txt). SpotBugs is a fork (successor) of FindBugs. The commercial tools all have code paths, but our agreement with the commercial tool vendors prevents me from sharing output. Jim lighttpd-1.4.45---ubuntu-16.04-64---cppcheck/results/assessment_report15.xml line 4 lighttpd-1.4.45---ubuntu-16.04-64---clang-sa/results/clang-sa_results1/2017-12-16-142506-11976-1/report-e82605.html whole file harder to parse, but more complete than .plist lighttpd-1.4.45---ubuntu-16.04-64---clang-sa/results/clang-sa_results1/2017-12-16-142506-11976-1/report-liRwOK.plist whole file easier to parse, but not as complete than .html twitter4j-3.0.3---ubuntu-16.04-64---spotbugs/results/assessment_report6.xml line 169 twitter4j-3.0.3---ubuntu-16.04-64---findbugs/results/assessment_report10.xml line 744 On 01/24/2018 03:59 PM, Larry Golding (Comcast) wrote: > One of our current discussion topics is whether the existing SARIF > codeFlow object can represent the rich information produced by tools > which trace execution paths through the code. It would help to have > sample log files from such tools to review at our upcoming meeting. > > If any of you have log files like that, could you please send them > directly to Mike Fanning (mikefan@microsoft.com > <mailto:mikefan@microsoft.com>) and me, Larry Golding > (larrygolding@comcast.net <mailto:larrygolding@comcast.net>)? > > Michael thought that some of you are likely to be able to supply logs > like that: > > * Yekaterina O’Neil – Fortify > * Paul Anderson – CodeSonar? > * Mel Llaguno – Synopsis > * Luke Cartey – Semmle > * Mike Fanning – Static Driver Verifier (SDV) > * Jim Kupsch – SWAMP-compatible tools? > * Henny Sipma – Kestrel > > … but the request is to any and all of you who can help. > > Thanks, > > Larry > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]