20 years of OWASP: Beyond syntax
This is a big week for those in the application security industry. One of our iconic foundation organizations, the Open Web Application Security Project (OWASP), reaches its 20th anniversary, and that’s a time for us all to celebrate.
On a personal level, OWASP has been part of my life since 2007.
When I got involved with the PHP ESAPI project as a junior web application developer, I was thrilled to find reusable libraries in the languages I used daily—libraries built to address common software security flaws.
While my contributions to that project didn’t go far past contributing some tests, I’ll always be grateful for how it introduced me to secure development principles and remediation techniques.
A 20-year legacy of world-class, free resources
OWASP is now a significant part of our web application security landscape. We often take for granted the vital resources the OWASP Foundation has created, which have since been adopted by a range of international compliance organizations as their north star for standards in secure development. These resources include:
The OWASP Top 10, covering the most common security vulnerabilities found in web applications
The OWASP Application Security Verification Standard (ASVS), provides a basis for testing web application technical security controls as well as giving developers a list of requirements for secure development
The OWASP Software Assurance Maturity Model (SAMM), offers a practical and measurable way to analyze and improve secure development life cycles.
We've had these at our fingertips for so long that it’s easy to forget they came from somewhere. Teams are working hard behind the scenes to create them and ensure the OWASP Foundation’s dozens of other flagship projects also work as references and community resources.
Looking to the future
The latest version of the OWASP Top 10 has been released in draft this month, and in OWASP’s collaborative spirit, it’s open to the community for comment. The 2021 edition has come a long way from its humble beginnings, and the style and content have shifted significantly in that time. While the common vulnerabilities we all know and love are still there, we’re starting to see a shift away from syntax-specific entries to groupings and families of vulnerabilities.
We are also witnessing design and architecture principles included in what’s historically been an implementation-specific list. I doubt there will be many feelings and opinions about this new OWASP Top 10 and how it relates to the changing world of application security. The shift from syntax-specific flaws to more high-level themes and the inclusion of more subjective design principles will be a challenge for many of us.
Understanding the impact of these changes
I believe these changes to the OWASP Top 10 aren't just needed but overdue.
Software development moves at an accelerated pace. The rise in distributed and service-based architectures means teams often write in many programming languages and are hosted on many technologies.
By focusing on families of vulnerabilities rather than specific instances of them, this guide will be widely applicable for software developers in a range of contexts, as it will cover more software types and frameworks, and more languages.
Our development teams are now free to apply this knowledge to their stack in ways that are appropriate and relevant for them.
Changing the educational focus from syntax to design
In the last decade, secure development education has primarily been built around teaching the specific syntax and semantics needed to avoid common vulnerabilities.
This guidance has focused only on developers and only on the implementation phase. Courses offering a 1-day dash through the OWASP Top 10 have been commonplace. Will this be possible now that it includes more design and architecture principles?
This refresh of the OWASP Top 10 will be the nudge many need to rethink their approach to development team education.
Broadening the scope of compliance regimes to consider the broader software development lifecycle
With this new approach, education starts at design and includes a broader range of roles and topics. In short, we should see our entire development team involved in securing our applications from the design phase onwards. This is a good thing. For many development teams, security is an essential part of quality.
Bringing security into our software development life cycles earlier on will improve code quality, reduce rework, and avoid preventable issues reaching production environments.
Of course, our compliance auditors will need to do some upskilling as they decide how to measure compliance against this new, broader standard.
Until then, however, we should all send our thanks.
Looking back on its 20-year heritage, there’s so much good that’s come from the efforts of the OWASP Foundation and its hundreds of volunteers.
Practitioners like me owe this community enormously for their years of hard work. I hope you’ll join me in raising a glass for them and our fellow application security enthusiasts and professionals as we look forward to the next chapter.