Developer Threat Modelling
There isn’t a single vulnerability in the OWASP top ten that couldn’t have been avoided with a conversation. A simple conversation to discuss what could go wrong with the piece of work that a team was about to undertake, what to spot in the code review and what the tester could have done to validate the control. So, before we start talking about static analysis tools, automated fuzzing, scanning, penetration testing and various other tooling – can I ask, are you even having the conversation yet?
In this talk I will share my experiences at the UK Hydrographic Office, where I work with a variety of agile teams to promote secure development practices. I will share with you DTM (Developer Threat Modelling) which is a developer-centric and fast form of threat modelling. I believe through a process of setting expectations, developer focused threat modelling, driving out useful security criteria, code review guidance and abuse cases we can enable efficient collaborative security conversations.
Zero gimmicks, no Lego, and not only can we help teams reduce the number of security threats that get into master, but we can do it for free and for a fraction of the time.
Session takeaways
- You will learn a light weight process for encouraging continuous security conversations within software teams
- You will get to hear about my mistakes (so you can avoid them) and what went well (so you can try them)
- Advice on how to lobby stakeholders to take security seriously
Bio
My name is Seb Coles, I’m an expert engineer at the hydrographic office where I specialise in application security. I care about anything that prevents vulnerabilities from getting into products such as threat modelling, secure coding, pen test skills, SAST/DAST tooling and conversations. I also work as part of a delivery team building geospatial products using .NET/JS & Python.