There are few application security projects more popular than the OWASP Top 10. The Top 10 project, which began over a decade ago, has been a vital tool in standardizing and popularizing security terms and issues for innumerable developers and security teams.
At that time, the problem seemed overwhelming. There wasn't even a common language to describe the security issues that researchers were discovering and exploiting. However, limiting the issues to a manageable list simplified security and gave development teams a benchmark for their own security issues.
Since then, security issues in the development landscape have changed considerably. The steady evolution of Web technologies has advanced to the point where security controls are the norm, and are built directly into most Web frameworks.
In 2011, the industry saw Web security gaining momentum
causing a stampede of Web technologists to discover more and more about Web security, and their first port of entry is normally the "Top 10." In fact, most other security consultants and scanning tools tout comprehensiveness in terms of that list.
However, for the average developer the OWASP Top 10 and other similar lists attack the problem from the wrong direction -- many are simply the manifestations of the same core mistakes that happen frequently during development. What's the point of training developers when they may not even be relevant in their environment and organization? It is much more effective to train developers to consistently use the specific controls provided by their particular platform.
Instead of focusing on the vulnerabilities, let's reset the focus. All enterprise software is developed through some sort of process; there are activities and procedures to some or all of these steps to ensure more exploit-resistant software. However, the focus of organizations now, and for the security community as a whole, should be measuring and determining the efficacy and results for particular security practices.
Along the same line of thought, security conferences should be less about the latest bug in 'website X' and more about presenting rates of security defects and tracing back to activities. The emphasis should be on applying security controls during the development process, and actually making those security controls difficult, if not impossible, to leave out.
More important is a contextual list of necessary security controls that must be used throughout an application. And by contextual I mean the list is specific not only to the company or organization, but also contextual to the language, framework and platform being used.
Insomuch, a "Top 10 security controls" would also be antiquated. For example, if framework being built on prohibits direct access to a database, then instead everything must go through an object model. In this scenario, SQL Injection is no longer a priority, because it is highly unlikely to occur (unless the vulnerability is in the underlying framework, which would need to be addressed by the framework developers or an internal security team tasked with mitigating vulnerabilities introduced by third party software).
Understanding the specific manifestations of Web vulnerabilities is a critical piece of the puzzle that must accounted for in every organization, and should be the primary domain of penetration testers, code reviewers and other security professionals. It is in the best interest of organizations to simply introduce security guidelines and rules that make contextual sense for their needs, not just because something has been published.