OWASP Periodic Table of Vulnerabilities
Vulnerabilities and weaknesses from industry-recognized indexes including OWASP Top 10, WASC TCv2, and CWE-25 are analyzed to determine which of the protection options are ideal for solving the software security problem. Where changes to internet standards and protocols are required, alternatives in perimeter, framework, or custom code solutions are also provided until the internet-scale solutions are in place. If a solution can be completely implemented in perimeter or infrastructure technologies, only that solution is provided. Similarly, if any part of the solution can be provided in standard or custom frameworks, that solution is not recommended to be implemented in custom code. The guiding principle is essentially: "implement security controls as far from custom code as possible." Only if there is no other way to solve a particular security problem is a custom code solution recommended.
After 20 years of software engineering since the first Internet worm was written to exploit a buffer overflow vulnerability, developers are still building insecure software. It is time for a new approach. The vast majority of software bug classes can be eliminated by building protections into perimeter technologies, platform infrastructures, and application frameworks before a developer even writes a single line of custom code. By allowing developers to focus on just a small subset of bug classes, training and standards programs can be more targeted and effective so developers can write secure code much more efficiently.
The most scalable and effective approach to addressing vulnerability classes is to fix the browsers, standards, and protocols that enable web applications. This approach can sometimes increase security for every application on the internet without changing a single custom application. Less scalable, but almost as effective is to address vulnerabilities in perimeter technologies such as application firewalls, load balancers, geocaching services and proxies.
These technologies can shield vulnerable applications without requiring changes to the applications themselves. The next most scalable approach requires upgrading popular application frameworks so they are robust against common attack classes. Finally, organizations can customize application frameworks to support their own application-specific APIs and security controls that developers can leverage during development instead of having to build the controls in during their daily coding efforts. If none of these options are possible for a given vulnerabillity class, developers will be required to protect against that class in every line of code that they write, which does not scale effectively at all.
| PROJECT INFO
What does this OWASP project offer you?
| RELEASE(S) INFO|
What releases are available for this project?