just to try to set expectations with some of these tools... yes, the
level of effort is comparable with pouring through gcc's output with -
Wall and -Wextra and attempting to fix every warning. actually... the
trick is... how do you get the tool to emit only "interesting"
warnings rather than a whole bunch of warnings you can conceivably
ignore? With fortify's tools, there's a lot of configurability
allowing the analyst to ignore or add different tests depending on the
analyst's wetware settings. BTW, this is one of the ways static
analysis tools can be used to funnel people into professional services
engagements. People build expertise in not only using the tool, but in
configuring and defining rules for the tool to ignore warnings and
detect errors. So in the same way i had a little bit of head
scratching when i moved from cc to xlC and from xlC to gcc, learning
how to use static analysis tools can be a task in and of itself.
so... there might be some benefits to selecting an individual and
getting them to be the "static analysis person." (i.e. - the person
who knows how to apply the tool to the codebase.) and as Rob
mentioned... at least at the Lab, it probably makes sense to include
this in our overall "source code security" process. outside the lab...
it might make sense for someone outside the lab to develop experience
with tools like fortify, prevent and whatever the latest offering from
Ounce Labs is (can't remember off the top of my head.) again... it
would be nice for there to be coordination between the in-lab and out-
of-lab resources, so yay! one more ball for Robla to juggle.
but... at the end of the day... anyone can download the source for the
viewer, related libraries and open-source static analysis tools.
-cheers,
-meadhbh/infinity
On Jan 11, 2009, at 11:42 PM, Gareth Nelson wrote:
e. it is characteristic of these tools that there is some give and
take
between the tool and the tool using mammal behind the keyboard.
many static
analysis tools are quite configurable and allow the user to perform
invasive
scans that produce an ox-stunning amount of output or to perform a
light
scan, which gives little of value. there's a lot of finesse
required to use
these tools effectively. this has led some to consider these tools
thinly
veiled professional services sales vehicles.
As someone who's not used these tools personally, how comparable are
they to paranoid compiler options that produce 10 billion warnings?
Running through build.log and using compiler warnings as a checklist
in my own projects is almost a hobby for me.....
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
