Sadly, the SANS Top 25 shows us that application developers are still struggling to learn from past mistakes. The errors in the Top 25 are split into three programming error categories: insecure interaction between components (8 errors), risky resource management (10 errors) and porous defenses (7 errors).
Risky resource management errors highlight poor programming and a lack of security awareness among developers. I know most developers tend not to have security high on their priority list, concentrating instead on "features and functions," but to still be introducing buffer-overflow and path-traversal vulnerabilities into applications in 2010 shows that people new to the industry are not being taught how to code correctly, let alone with security in mind. While well-known vulnerabilities are still being coded into applications, systems and users will continue to suffer from attacks.
Porous application security defenses is a reflection of poor project management or underfunded projects. I can't think of any other reason why "missing encryption of sensitive data" would appear on the list. "Missing authentication of critical function" again shows that many developers do not have a grasp of how applications that run in the hostile environment of the Internet need to be built. Developers need to appreciate that they can't rely on a firewall and IDS for an application's security; they are also responsible.
Developers often don't realize the security implications of particular features and functions that they wish to incorporate into their applications. Threat modeling is a good way to resolve this problem of security versus usability. It not only raises security awareness among developers, but it also makes application security an integral part of the application design and development processes. It is a great way to help bridge the knowledge gap between security and development professionals.
Finally, I think the errors in the first category, insecure interactions between components, are often a direct result of many development teams being so big, and the different components that make up an application being written by different developers, often with little dialogue between them until the application is built and deployed. To reduce the occurrence of this type of error, it's vital that all code is well documented. This should include a description of what the code does, why and how, and what assumptions are made when the code is called.
Many flaws can be eliminated from an application by validating these assumptions and testing that they can't be violated. It's also important to list all other code that references a particular component. This cross-referencing helps ensure changes to the component won't break assumptions and logic elsewhere and makes it easier for a reviewer to see or understand where flow or business controls could be circumvented. To ensure this documentation and validation is carried out, I would mandate it as part of the design and build requirements. If every project manager ensures that their application has been checked for these 25 errors, we will be a lot further down the road toward enforcing good coding practices and reducing the number of easy attack vectors for hackers.
This was first published in March 2010