[tl;dr sec] #3 (in)Secure Development - Why some product teams are great and others aren’t…
[tl;dr sec] (in)Secure Development - Why some product teams are great and others aren’t...
tl;dr sec is a newsletter about AppSec and scaling security, automated bug finding, conference talk and paper summaries, and useful links from around the web. See past issues here.
(in)Secure Development - Why some product teams are great and others aren’t…
I hope you've been doing well! I've been a bit busy traveling, but things are great. My birthday was last week, and I did a bit of
It's my birthday! 🥳🎉 So I thought I'd reflect a bit on the last year:
1. What went well 👍
2. What went less well 👎
3. Open questions / what I'd like to work on🔨
— Clint Gibler (@clintgibler)
Jun 18, 2019
This issue includes some key takeaways of Riot Games' InfoSec Development Manager
's AppSec Cali 2019 talk:
"(in)Secure Development - Why some product teams are great and others aren’t...".
You can read a
Sqreen published a nice high-level
broken down by areas of concern (employees, code, app, infra, company, product users) and company stage (seed, series A, series B). I like that the descriptions are concise but useful and have links to supporting resources.
, the guy behind
, manually audited all 500+ of AWS' managed policies looking for security issues and silent fixes. In this blog post he
, including tagging secrets, privilege escalation, resource policy privilege escalation, and more.
As you might guess, I'm a big fan of security summaries, and
from this past ICSE, which is a top-tier academic software engineering conference. The papers cover topics including static analysis, SMT solving, fuzzing, concolic testing, and of course #blockchain.
New Summary: "(in)Secure Development - Why some product teams are great and others aren’t..."
Koen describes analyzing the security maturity of Riot product teams, measuring that maturity’s impact quantitatively using bug bounty data, and discusses one lightweight prompt that can be added into the sprint planning process to prime developers about security.
Based on observing how development teams discuss security and interact (or don’t) with the security team, Koen groups dev teams into 4 security maturity levels.
Teams at these maturity levels range from largely not thinking about security (Level 1), to having one or two security advocates (Level 2), to security being a consistent part of discussions but it’s not yet easy and natural (Level 3), to security consciousness being pervasive and ever-present (Level 4).
To examine if a dev team’s level had a measurable impact on the security of the code bases they worked on, Koen analyzed Riot’s 2017 bug bounty data group by team maturity level. The differences were
clear and significant
Compared to teams at Level 1, teams at Levels 2-4 had:
A 20% / 35% / 45% reduced average bug cost
A 35% / 55% / 70% reduced average time to fix
The average issue severity found from internal testing was 30% / 35% / 42% lower
Riot chose to focus on raising Level 1 and 2 teams to Level 3, as that yields the biggest security benefits vs effort required, makes teams’ security processes self-sustaining without constant security team involvement, and makes them more accepting of future security tools and processes provided by the security team.
They did this by shaping development team behaviour, rather than purely focusing on automation and technical competencies and capabilities.
How to uplevel dev teams? During standard sprint planning, dev teams now ask the following prompt and spend 2-3 minutes discussing it, recording the outcomes as part of the story in Jira/Trello/etc.:
Though the dev team may not think of every possible abuse case, this approach is highly scalable, as it primes devs to think about security continuously during design and development without the security team needing to attend every meeting (which is not feasible).
Some final thoughts:
The security level of a team influences how the security team should interact with them.
If the majority of your teams are Level 1 and 2, rolling out optional toolings and processes isn’t going to help. First, you need to level up how much they care about security.
Work with Level 3 and 4 teams when building new tooling to get early feedback and iterate to smooth out friction points before rolling the tooling out to the rest of the org.
You can read the
How does your company do threat modeling?
One thing I hear from friends at a variety of companies is how tough it is to a) stay on top of architecture reviews and threat modeling with a rapid pace of development and b) keep threat models accurate as features and requirements change over time.
How does your company handle these challenges? If there's any specific tips and tricks your team has found effective, I'd enjoy hearing about them.
Sharing is Caring
If there's anyone you know who would find this newsletter interesting or useful, we'd really appreciate if you'd forward it to them.
Have questions, comments, or feedback? Just reply directly, we'd love to hear from you.
Thanks for reading!