Actually, we can't prove programs are bug free if by "bug" we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything "right" in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%.
Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com ________________________________________ From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews [andr...@rbacomm.com] Sent: Friday, August 21, 2009 11:41 AM To: sc-l@securecoding.org Subject: Re: [SC-L] What is the size of this list? I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can "prove" programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a "flawless" piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI [snippety snip] _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
