Thou shalt have no other gods before the ANSI C standard 1604

Trevor L. Jackson, III

One potential challenge with run-time analysis is ensuring sufficient coverage. It might be very easy to miss bugs that are triggered only on certain code paths. I don't rule out the possibility that one could build a tool that is useful nonetheless, but it might take some work.

A simplistic version of this is simply to run the program with bounds checking enabled during testing, and if any bound is ever violated (during the testing phase), then you've got a pretty good idea that the program is likely to be buggy. Unfortunately, that is unlikely to be enough, because for many buffer overruns, it is not at all easy to come up with the test case that triggers the buffer overrun.

But, if you can build a tool that detects the presence of code which could write to red memory on some input (potentially other than the input currently being processed), that might address the coverage problem.

My favorite research work in this direction is the following paper: Eric Larson and Todd Austin, "High Coverage Detection of Input-related Security Faults", Usenix Security 2003. Personally, I thought this was one of the most exciting ideas in security during the year of 2003. I suspect continued work on some direction like this might well be worth the effort.