Shift left? Spread left? Regardless of terminology, we want to be thinking about security earlier on in the development lifecycle. Ideally whilst we are still gathering the business requirements.
But how do we do that? Not everyone can think up security requirements on demand and we need to do this constantly for each new feature or development.
As a project lead for the OWASP Application Security Verification Standard (ASVS), a list of requirements for building secure software, this is something I have spent time working on as well as discussing with a variety of development teams. In this talk I want to show you what we came up with.
After a brief overview of what the ASVS is, we will then talk about how to:
- Get buy-in for security at this stage
- Balance trade-offs and prioritize different security requirements
- Trim the ASVS to focus on your current context
- Make the process repeatable and maintain a view of security state
You should leave the talk with not only a better understanding of the ASVS but also clear ideas on how you can take this and implement it as part of your own organization's requirements process.
What's the focus of your work these days?
I come from a security background. I started off in the hacker world doing breaking and penetration testing. Gradually I realized that if security people want to improve the security of software and be able to build things securely, we need to work alongside developers. Specifically, how can we bring security knowledge and security guidance to developers in a way that matches the way that they're working, day to day.
So that is the basis of my work today, working with development teams and helping them with their software security processes, either to implement them or to improve them, but in a way that fits with their existing processes and brings them higher value.
What's the motivation for your talk at QCon London 2023?
I'm one of the co-leaders of the OWASP ASVS project, which is a really great project for giving comprehensive guidance, over a variety of different areas on how to build software in a secure way. The problem with the ASVS is that it is very large. There are about 280 requirements in total. So, how do we make it accessible? How do we make it usable?
The motivation behind the talk is to bring some ideas of how to do this and how to break it down into manageable chunks. We want to find ways of integrating it into the overall software lifecycle in a way that doesn’t add friction or slow things down.
How would you describe your main persona and target audience for this session?
The talk is aimed at people who've got experience with development and are familiar with different working methods but have seen the challenge of trying to maintain development velocity whilst also trying to integrate security.
Ultimately, I think anyone who's interested in how to make security more usable for themselves and their teams will benefit from this session.
Is there anything specific that you'd like people to walk away with after watching your session?
The focus is on ideas that are actionable, and I'll show examples of things I've used within actual organizations during the talk.
Aside from what I wrote in the abstract, I hope people leave feeling confident that security doesn’t have to be slow and painful as long as it is planned and targeted correctly.
Application Security Consultant & CTO @BounceSecurity
Josh has worked as a consultant in IT/Application Security and Risk for 15 years now as well as a Software Developer. In that time he has seen the good, the bad and the stuff which is sadly/luckily still covered by an NDA. He is currently Chief Technology Officer for Bounce Security where he spends his time helping organisations improve and get better value from their Application Security processes and providing specialist Application Security advice. In his spare time he co-leads the OWASP Application Security Verification Standard project and is on the OWASP Israel chapter board.