[cfe-dev] [analyzer] Project to output SARIF

[Paul Anderson via cfe-dev]

All:

This is my first post to this list, so first, let me give a quick 
introduction. I'm VP of Engineering at GrammaTech, where I am in charge 
of an advanced static analysis tool named CodeSonar. It primarily works 
for C and C++, but also for x86, x64 and ARM binaries. There is a little 
overlap with what CSA does, but CodeSonar's strength is in whole-program 
path-sensitive analysis for serious defects and security vulnerabilities.

I'm writing to let the community know of some work we will be doing that 
should benefit everyone. I think I know the best way forward, but I'd 
appreciate any words of wisdom and feedback on our approach.

This work is funded by a government research project aimed at 
modernizing open source static analysis tools. The project is named 
STAMP (the official funding agency page, which is admittedly very short 
on details, is here: https://www.dhs.gov/science-and-technology/csd-stamp.)

There are several thrusts, but the piece I have been working on is aimed 
at changing tools so that they can communicate more effectively with 
each other. Ultimately there will be a protocol to allow tools to 
exchange information actively, but the first part is simpler and fairly 
straightforward. We will be modifying tools so that they can output 
results in SARIF, a standard output format for static analysis tools: 
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif. The 
standard was first conceived at Microsoft. I'm on the TC, along with 
representatives from other tool vendors and interested users.

We've already written an adapter for CSA that can take plist-format 
output and convert it to SARIF, and we plan to make that available 
shortly. However due to constraints on what is expressible with that 
format, we feel we can do a much better job if we change the analyzer to 
output SARIF natively, controlled by (say) -analyzer-output=sarif.

We've done some prototyping of this on a fork and have it rolling over 
nicely. There's more to be done though before we are ready to submit 
anything for review. We've read all the material on contributing and 
will follow those guidelines as best we can. However, if anyone can 
think of a reason why we should do anything differently, or if there are 
particular pitfalls we should be aware of, I would greatly appreciate 
that input.

Thanks in advance,

-Paul


-- 
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850
Tel: +1 607 273-7340 x118; http://www.grammatech.com