Page History

...

Yet the reality of today's software is that much of its legacy code was not originally produced within a secure development process. Andy Ozment and Stuart Schechter studied the impact of legacy code on the security of modern software and how large code changes might introduce vulnerabilities ([1)]. The positive news is that foundational vulnerabilities—ones that existed in the very first release and carried through the most recent version of the software—decay over time. We can find them, fix them, and make the code base stronger overall. However, the bad news is that as the low-hanging fruit of foundational vulnerabilities are fixed, the remaining foundational vulnerabilities tend to be more subtle or complex, making them increasingly difficult to discover.

Furthermore, ongoing development and code changes can introduce new vulnerabilities, making it unlikely for the security process to ever be "finished." Even with modern architecture development and secure coding practices, software bugs (and in particular security vulnerabilities) remain a likely result as new features are added or code is refactored. This can happen for many reasons, not all of them technical. A recent article highlighted the difficulty of getting teams of people to work together, resulting in poor software architecture ([2)]. While the authors were primarily concerned with maintainability and performance, bugs (and particularly security vulnerability bugs) are an important side effect of inadequate architecture and teamwork process.

Another possibility is that, even with good internal processes and teamwork, no software model or specification can comprehensively account for the variety of environments the software may operate in ([3)]. If we cannot predict the environment, we cannot predict all the ways that things may go wrong. In fact, research has shown that it appears impossible to model or predict the number of vulnerabilities that may be found through tools like fuzzing—and, by extension, the number of vulnerabilities that exist in a product ([4,5)]. The best advice seems to be to assume that vulnerabilities will be found indefinitely into the future and work to ensure that any remaining vulnerabilities cause minimal harm to users and systems.

...