This is a big week for those of us in the application security industry. One of our iconic foundation organisations, 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 every day — libraries that were 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, and which have since been adopted by a range of international compliance organisations 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), providing 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), offering an effective and measurable way to analyse and improve secure development life cycles.
We’ve had these at our fingertips for so long, it’s easy to forget they came from somewhere. Teams of people are working hard behind the scenes to create them and to make sure the OWASP Foundation’s dozens of other flagship projects work as references and community resources, too.
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 a lot 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 seeing design and architecture principles included in what’s historically been an implementation-specific list.
No 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
In my opinion, these changes to the OWASP Top 10 aren’t just needed but overdue.
Making application security more inclusive
Software development moves at an accelerated pace. The rise in distributed and service-based architectures means teams are often writing in many programming languages, 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 largely 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 life cycle
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 teams involved in securing our applications from the design phase onwards.
This is a good thing. For many development teams, security is an important 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 to them and our fellow application security enthusiasts and professionals as we look forward to the next chapter.