Developing a Good Security Policy
The final point that must be addressed in handling security is what happens after a bug is fixed. Here, OpenBSD is the shining example of the correct way of doing things. After a bug is found in OpenBSD, it’s categorized. Examples of the categories include overflows caused by casting a signed value to an unsigned, or the lack of bounds-checking on some C string-manipulation functions. Once the bug is categorized, the entire codebase is audited to detect any other occurrences of these bugs—and the developers keep an eye out for new occurrences when approving new code.
A good security policy like this results in a secure system. When these security policies were implemented, around OpenBSD version 2, a huge number of vulnerabilities were found and fixed. Did this mean that OpenBSD was less secure than NetBSD, which shared a lot of the same codebase at the time? The popular press seems to believe so: "They found more vulnerabilities and so must be less secure." But the fact that far fewer vulnerabilities have been found since then—and only one serious vulnerability in eight years—shows that this was not the case.