On Wednesday, December 12, 2012 01:00:36 AM Paulo César Pereira de Andrade wrote: > > A while back I ran my static checker on all of the Python extension > > > > modules in Fedora 17: > > http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts > > > > I wrote various scripts to build the packages in a mock environment that > > injects my checker into gcc, then wrote various scripts to triage the > > results. I then filed bugs by hand for the most important results, > > writing some more scripts along the way to make the process easier. > > > > This led to some valuable bug fixes, but the mechanism for running the > > analysis was very ad hoc and doesn't scale. > > I think it could be useful at least as a generic tool where one would > just do something like: > make CC=gcc-with-python-plugin > like some time ago one could run > make CC=cgcc > to see what sparse would tell. Or maybe think of it as a tool like > rpmlint. I wrote a program, fake-make which collects everything so that programs like cppcheck can be run with correct defines, paths, and files. Instructions are here: http://people.redhat.com/sgrubb/swa/cwe/index.html That said, what's really needed is every analyzer to output messages with something in common so that results can be compared. That something in common is CWE (Common Weakness Enumeration). I was working on a mapping for cppcheck to CWE so that it could be correlated with other tools. the advantage of CWE is that its also married to CAPEC (Common Attack Pattern enumeration and classification). This mapping shows some possible ways that the bug being found could be exploited depending on other mitigating factors. So, what would be nice is to figure out how to get all the static analyzers and compilers outputting CWE information. Then define a common format so that correlation tools can be built. If several tools report the same issue at the same line, then its probably not a false positive and someone should look at it. But at the same time, not all bugs are created equal. A buffer overflow is a worse problem than unchecked return code (unless its setuid(2)). There is a scoring framework, CWSS (Common Weakness Scoring System) that can be used to rank bugs so they can be prioritized. It also takes into account the effect of the bug withon the program its found in. For example, buffer overflow in network app or daemon is more critical that same issue in a program run by authenticated users such as "ps". Don't get me wrong, there are corners cases...but some heuristic has to be used and decisions have to be made. So.. this would be my advice...try to follow these standards. Its all part of a larger project to track weaknesses, combine with configuration information, and network IDS systems for real time situational awareness. -Steve -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
