Dealing with static code analysis in Fedora

[Steve Grubb]

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