We should all be looking to the security auditing work done by the OpenBSD team for an example of how systems can be cleaned up, fixed, and locked down if there is a will to do so.
Beer, unsupported assertions, and lack of rigorous audit methodology can be blended together to make one's code more secure?
Perhaps you aren't aware of what the OpenBSD team accomplished? Their techniques may not be rigorously documented but they have been used in other projects: http://www1.cs.columbia.edu/~angelos/Papers/posse-chapter.pdf ABSTRACT This chapter reports on our experiences with POSSE, a project studying ?Portable Open Source Security Elements? as part of the larger DARPA effort on Composable High Assurance Trusted Systems. We describe the organization created to manage POSSE and the significant acceleration in producing widely used secure software that has resulted. ... The OpenBSD team provide a brief overview of their process here: http://www.openbsd.org/security.html And a security consulting company describes the lessons of OpenBSD here: http://www.openlysecure.org/openbsd/security/sec_lessons Their process has some parallels in the activities of groups like the Columbia Accident Inquiry Board and the 911 Commission. Openness, rigourous examination, attention to detail... --Michael Dillon