It’s time to uplift developer security maturity and erase common mistakes

[Music] there we go so my name is Erica Wass I'm the VP of product at secure code Warrior which is located just a couple of blocks from here I noticed on my way in and for those of you who don't know secure code Warrior is focused on developer driven security perfect so we focus on helping developers and businesses uh code more securely at the very start of the software development life cycle today we're going to be looking at some common pitfalls that are plaguing application security teams with regard to developers and look at how we can break some of those Trends and really start to lift organizational security and maturity throughout organizations I should mention a little bit about my interplay with the topic uh because it's twofold probably threefold the first is the thing that we all have which is that we are all consumers and we're all humans that are affected by breaches and vulnerabilities in a variety of ways the second is that as a product leader throughout my career I've been embedded with development teams Building Product understanding what it is that we want to build and then working with development teams to get it shipped and then most recently with secure code Warrior I've been working with businesses to better understand the challenge is that they're having so the one thing that I can say through each of those areas is that I'm very much leading with empathy toward the developers toward the security teams in how they manage these complicated Dynamics great breaches are everywhere every day and you can see that the average cost of a breach is more than four million dollars and so there's a constant need and a constant overhead of what's going on in the market with data breaches and how they're caused a Verizon study showed that 95 of them are caused by human factors in addition Security Professionals feel unprepared they feel overwhelmed by what's happening and developers are constantly releasing more and more and more code at a quicker clip at a faster pace and the incentives aren't aligned there's a lot of issues there if we look at an example of SQL injection for example a vulnerability that came in the late 90s you'll see that the same problems that were happening then are happening now which gets to the topic of why is it that these issues continually keep happening we knew at the very outset within days and weeks of that vulnerability had to fix it and yet it's disincentivized at the outcome of producing that so we want to look at some of those disincentives uh and and really see if we can reconcile those two things with the audiences at hand developers any developers in the room hands up a couple have you knowingly shipped bugs or vulnerabilities questionnaire can be yes then the majority are and it could be because there's time incentives time pressures lack of knowledge secure code Warrior did a research study with Evans data Corp of of 1200 developers to look more closely at their security practices and their security needs what we found was of the 15 that we're a software developer that we ask the question do you think that you leave vulnerabilities in your code 48 said yes 33 said no and 19 said well it depends on the project so then you dig more into why that happens to be why do you think the vulnerabilities exist and the reasons here are across the board numerous but also there's a trend toward we prioritize functionality over security so already we're starting to plant the seeds that the development teams and the security teams are a little bit at odds in terms of their goals their priorities their rationalize their rationalizations and their incentives next was we needed to meet a release deadline the business says to the development teams we have to do a thing in a big hairy audacious goal kind of way uh and and there's no time and so 36 said that we needed to meet a release deadline and that's why vulnerabilities exist lesser still but still up there is we may not know what makes our code vulnerable all code has vulnerabilities and we lack the knowledge to address it so there's knowledge issues Bulls at the start and the end of that cycle as well a common problem that we see so developers in security we had a little showing of hands a couple people in the room who are developers what about those who are on the the security side a few more hands so it won't come as a surprise then that the two aren't playing that nicely together as a result of these disincentives and these misalignments you see that that there's not incongruity there in how the two teams play together let's see how it plays out a little bit more specifically now I know this as well from the teams that I've been on there's a task to do it takes time the team will scope it out and we'll do the work and sometimes it takes a long time and sometimes it happens more incrementally but when they're done the development team feels good about high quality code delivering value for the business and ultimately the end users seeing the the value of that in exciting new features or enhancements and so they're they're excited right they're they're there every deadline we worked on this for a long time look how the security teams do something very different the security team says whoa this is frightening this is not okay don't do any of that this can't go outside these doors this has some serious issues anybody any balance for anyone in the room uh don't let anyone use this and you really should have involved this the design stage we could have caught this earlier feel when that happens immediately blocked there's a log Jam as to why that's occurring they say well well we're on this track toward greatness and then suddenly the breaks are put on and so not only do they perceive the security teams as a killjoy but also as a blocking Factor toward that ultimate release which is the completion of the task so why is this happening they're speaking different languages not only the Penguin and the seal but also the security teams and the developers and you can see this structurally in how this is coming into play with regard to how the business makes the decision on pen testing the example being that pen testers are hired the business may not know exactly what's needed they're not digging in necessarily they're evaluating testers based on criteria like like price and reputation in the competition for that high quality testers will scope down right they'll downscope their proposals to to what's okay and what is manageable by the business but in doing that they're reducing the level of interaction and the level of knowledge that they're having with the team on point as a result their deliverable is a paper with a bunch of items to do as a result of that the developers received this right a mandate a bunch of things a bunch of tasks to do and there's little empathy between the teams their collaboration isn't there early on it's there at the end bringing negative feelings uh on both sides of that equation the security side developers are increasing the pace of code production inordinately teams are building faster building new things using new technology and security is not equipped to deal with the bottleneck the teams aren't staffed to say that they're going to uh to increase numbers and the same Hep as the the codes being written we know that over a hundred billion lines of code are being written there's no way that a human can address that in the way that we've been working and that's what's necessitating a change to really uplift the security maturity in organizations so if we look at devs and common vulnerabilities how is this working in more detail this is the cycle that we currently have right dealing with software bugs and vulnerabilities since the late 90s generally speaking code is written it's tested flaws are found they're then put through a machine to fix the flaws not a lot of thought put into the the initial stages there it's more like oh there's a task to do the task gets completed the person completing the task may have not have been the person who wrote the code in the first place so it really is a checklist item and then it repeats we test we identify the flaws it isn't a reactive cycle that is only perpetuating itself in negative ways for all the parties involved so old bugs still performing New Tricks we've said that the SQL injection has been there for decades and still the same issues continue to arrive but most developers remain untrained unaware incapable of solving that out in the first right so security code Warrior enables developers to engage in challenges to learn and to explore various vulnerabilities and here's the most played Talent content and what you can see which was reflective of what we're talking about is that the injection flaws and cross-site scripting are the top these are the long-running issues that we've had and these are the long-running issues that are most played and need to be most addressed in those cases let's look more specifically in the result of almost a million attempts at a SQL injection challenge what we found was it was a 64.36 success rate on the first one which means that nearly a third of the developers couldn't identify and remediate a SQL injection which issue in the first instance now 64 64.36 could be good but look at the wide Gap that that's leaving anyone could exploit that that space and so that's what we're seeing there in a bit of positive news though what we are seeing is the 89 success rate after multiple challenges which means that when developers have contextual training and are seeing the things multiple times and getting a handle on it they were able to increase the success rate showing that developers can learn and that we may have an opportunity here with these long-standing vulnerabilities to curb them through a different way of thinking about Security in business other challenges as well you'll see here in the xss and the Idora challenges that there's a nearly 50 success rate on the first run which developers are best at security we found that that rust developers have a 70 accuracy with others trailing and which ones are struggle the most and have the least these are those languages Developers so it varies in the detail but in the concept what we continue to see is that long-standing issues continue to permeate and continue to drive risk for those businesses we've mentioned a lot about injections last year was a milestone year it was the first year that the owas top 10 named something else since 2003 as the highest risk broken access controls so least privilege isn't as effective but a technique at mitigating these issues as one would hope and what the reasoning for that goes again to how the developers are thinking about their practices and how the business is aligned on understanding the goals of security and secure development the reasoning being that if we think about least privilege a lot of the issues that come up for developers include that it takes longer to deal with that there are more edge cases that they need to handle and work through that in doing the development there will need be needs to retract and redo that on the way to shipping and so it's an inefficient way of thinking when it comes to the development Pipeline and the incentives to remember earlier ship things faster right we have deadlines that we need to hit and this creates complexity to that so we need to rethink in addition to what we currently know and do about least privilege what it is that we can add to that to help the developers and the businesses be more successful on this front let's be clear it is not the developers here or the developers outside these walls fault this is a structural Dynamic that both the developers and the security teams have to deal with as a result of inadequate training tools that don't fit their Tech stack no time to learn the skills secure coding is not a measure of their success in kpis delivery to the deadline meeting the customer goals are so while the security team is aligned to the relevance and the importance of security the development teams are not on that same Journey from a structural standpoint not as individuals the appsec is a showstopper delivering bad news poor Solutions not necessarily being able to align and understand the developer point of view at the same time is really understanding the vulnerability and the problem so a wrong culture and mindset is to tackle the security problems hence what we see generally which is a low security maturity so what do we do there are things that we can do in in business to get the app sex and the developers more on the same page to work more jointly to understand each other's priorities to understand the inputs and why it's important and then to develop a develop pun intended developers or developing but to really produce better aligned more incentivized outcomes some things and this is uh looking at making it relevant the idea is to provide contextual tools to the developers that affect their day-to-day make it applicable to them a generalized solution a generalized discussion is only as good as a generalized output and the developers are not doing generalized output they're creating the actual in the weeds details and so making a job relevant with Precision content is important for them then we want to increase their skills engaging training building foundations keep leveling up it's not a one done thing there's multiple ways there are ways at the bottom to plug the most common deficiencies and then to continue to level up and build more competency there to do that you can certify you can Benchmark and verify skills the business can give incentives to become a security skilled Champion someone who's interested in security within the development space can influence others and and help them to uplift and up level themselves as well and then from a corporate to be a top-down this can be if this grows organically as a Grassroots motion it's great but it won't take root as really a fundamental aspect of the culture and that's needed to make sure that the incentives are aligned because if the mandates to one team is different than the other it's going to be near impossible to bridge that divide and so for cult for nurturing the culture you want to recognize top performers you want to call them out and say this is good we're going to celebrate what's good and we're going to we're going to see that we're gonna give time to the developers to learn to try this time is is the thing right early on the constraint that was called out was yeah we know we're shipping vulnerabilities but time pressures so clearly there's something that can be pulled as far as a lever to enable time for the developers to do this ultimately being proactive is time spent because it will reduce the fires that occur at the other end of that pipeline so it's really saying we're going to reduce the issues later and save the time now by becoming more structured about the learning and the abilities of our team at the outset which will ultimately have a downstream effect of reducing the fires and the business risk that come with those breaches and you can make it fun there's a lot of interesting nuancy aspect toward this work that developers would enjoy if they're given the opportunity and the platform to be able to do that there was an interesting discussion that we've had uh where people say okay you're Farther Along on your security maturity how's it going are you seeing less vulnerabilities that's the goal that's the metric what metrics are you using and it's an interesting interplay because what the result here is you can see the quote they say actually we've seen the opposite so far we see the number of discovered vulnerabilities going up so there's more vulnerabilities cringe everyone in the room steps back a little bit and cringes at that but the reasoning is really quite good and that is because as the developers learn more and know more they go on a Hunting Expedition they suddenly find issues in the code that no one had found before so previously unidentified risk is being called out through this process as a result the number of vulnerabilities is going up over time of course they'll come back down as they're being done so what businesses are finding is that as the developer maturity goes up they are actually able to reduce the risk in their code base in ways that they hadn't known about or foreseen earlier to best effect so before we looked at the kind of awful cycle of shipping code having it reviewed fixing it doing the same thing over and over again here's a more virtuous cycle this is looking at Key tips and how we can successfully employ developer-led security we can raise standards do we want to ship known vulnerabilities as a business that's an important standard to identify a line on if the answer is no suddenly the two teams are very well aligned those mismatches and incentives are no longer there because it's key that that if it is misaligned then at the very outset the standards are not allowing the teams either one of them to achieve their best work instill contextual learning we've seen that that works for the most common vulnerabilities and certainly will and does more Downstream of that as well you want to break down silos as we've talked about where the security teams and development teams are friends and find mechanisms and inroads into each other's workflows this is much more successful then assign and modern responsibility and ultimately give devs time to succeed it doesn't need to be a zero or one option it can be we're going to work on uplifting skills we're going to make space for the developers to do this because we think it's important as a business and a security team uh the security team to help and then the business can really achieve those goals of continuing to de-risk their code base and ensure that their customers are no longer at risk in the same way that they might have been before undertaking this journey thank you for joining me today I hope this was a little food for thought in terms of you and thinking about how you want to contribute to developers and security teams Bridging the divides and increasing the overall security maturity of organizations [Music]