Events Add an event Speakers Talks Collections
 
Duration 40:01
16+
Play
Video

Developers Dislike Security: Ten Frustrations and Resolutions

Chris Romeo
CEO at Security Journey
  • Video
  • Table of contents
  • Video
RSAC 2021
May 20, 2021, Online, USA
RSAC 2021
Request Q&A
RSAC 2021
From the conference
RSAC 2021
Request Q&A
Video
Developers Dislike Security: Ten Frustrations and Resolutions
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
65
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Chris Romeo
CEO at Security Journey

About the talk

Chris Romeo, CEO, Security Journey - Top Rated Speaker Developers dislike security and won't always admit it. In a DevSecOps world, devs become security people, but did anyone ask dev? Devs dislike security because security doesn't understand, and often tries to force a process and toolset. Explore the ten main frustrations that cause a security dislike, dev empathy, and a collaborative- and culture-focused solution to address these frustrations.

Share

Hey folks, welcome to the session developers, dislike security, 10, frustrations and resolutions. My name is Chris Romeo on the CEO of security journey and super excited to be here today to talk about security culture Through The Eyes of the developer. So the agenda that I have for our session, here's one. I want to introduce you to the idea of the dev SEC. Disconnect. Don't worry. We're going to get into what that means. But I'm going to talk about 10 frustrations that I've seen the developers have with security, and I'll introduce an idea called developer empathy or how can

we walk a mile in the shoes of our developers? And from there. We'll go into the 10 frustrations that developers have with security. And for each of those, I'm going to give you a description and then I'm going to talk about a resolution because we can't just sit here and talk about the problems. We got to talk about some solutions as well. And so that's what we're going to do with the resolution. This is talk about how can we build a positive security culture? That's collaborative. How can we counter the frustrations that our developers are experiencing? And from there? We'll go into our

conclusion. I'm going to take questions throughout the session here. So feel free in the the question-and-answer panel to ask me any questions and we'll talk about him as we go through the session. I want to start by introducing this idea of the dev SEC disconnect. So for me, we're talking about developers were talking about security. There's definitely a disconnection that exist or tension between developers and security regarding the security of new features and Bug fixes. And so let's talk about this, from the perspective of the developer and then from security. So, as a

developer, I'm sitting here thinking to myself, these security people there always get in the way. They're always. Slowing me down. They have arbitrary requirements that can't make up their mind. We had to push these new features in the production. That's what what drives us on the other side of the coin security saying, these developers are lazy. They're not applying the guidance. We provided in the security process and the pipeline, the code is insecure and our tools always blow up when we scan their code. Cuz there's so many problems. They can't push this feature into production.

And so this is the depths Disconnect. There's this tension that exists between developers and security. It manifests itself in various different types of frustrations. That's what I'm going to talk to you about today. Now, I wanted to stop and make a quick point because last year, I came to our stake conference and I talked about 10 Things. I wish every developer knew about security. So last year. I felt like I was talking to secure and one of my friends challenge me and said, why don't you flip this around and think about this from the developer's perspective, think about why developers are

frustrated with us as security people and share that with the security community so that they can understand where their developers are coming from and how they can better serve them. How can they can, they can better help them in the process? So, this year I'm talking about developers. And so these two things together, you can always go back in. And look at the talk. I did last year to, to get more of a security Focus perspective. So here's the 10 frustrations developers have with security and right up front. I like to share these with you so that you can see the landscape for where we're

going. I counted backwards. I was trying to do a top 10 thing. I don't know. But counting backwards number 10, security tools are loud. Obnoxious in an accurate. Number 9. The sky is always falling. We never celebrate success. Remember this is developer speaking to us a security people Security in busy work Securities, a silo and then they act as Gatekeepers and there's not enough time in my development scheduled to do security. There's the first five frustrations. The final five security changes their mind all the time. The security process is difficult is undefined. I don't know why we

put so much effort and time in the security. Nobody ever showed me how to security. And number one security, doesn't understand what I do and doesn't know how to code. Remember. These are the frustrations that I've heard, as I talk to developers across the industry. I've pulled different development audiences across Twitter and I brought all of this together and synthesized, it to help us understand where we is security. People need to go to serve our developers better. Developer empathy in its most simplest form. We is security. People. We need to walk a mile in the

shoes of our developers, if you stop and think for a second about what the word empathy actually means, it means vicarious experiencing of the feelings thoughts or attitudes of another In this case, I'm talking about security people who are experiencing the feelings, thoughts or attitudes of developers. Howard developers being impacted by the security tools and things that we put into their pipelines into their process and developer empathy. It really happens when we have security. We walked that Mile in the developer shoes. We understand what are the real

struggles that they're challenged with. Many of them are challenges that we presented to never, we provided through the way, we were approached security and an embracing developer empathy and allows us to security experience those frustrations first-hand from the eyes of our developers. That's really what's going to help us to change our approach, change the way that we were can interact with our developers. Let's Jump Right In and get into it. So as a developer frustration number one security doesn't understand what I do and doesn't know how to code.

This is kind of an interesting one cuz it's it's one of the more controversial frustrations that I listed here. That's why I went with. It is number one and that is there is a big debate about. If you're going to be in the application security world, you're going to be in devsecops and your security person. How much do you need to know about the actual code? And I think you need to know a lot. That's part of what the frustration is. That our developers are experiencing here is perspective. Let's imagine, you take your car in for service guy. Do you stand there next to the mechanic and

tell them how to fix the car? No, because you don't know how to fix the car or the car. If you could fix your own car, you would fix the car at home. You went to take it to the mechanic in the first place. So it's frustrating for developers to be coasters cover. Are orb worked with by folks that don't understand what they actually do. It's like you standing next to mechanic. Tell him how to fix your car, telling her, how to fix your car. This is a frustrating thing. When you come to think about it from a summary statement perspective, we, as security when when,

when this frustration occurs, we're looking at our developers and at the end of the day, we're saying, you know, I'm important enough to govern the process that you're you're using too busy to understand the work that I govern. And soaps for every frustration with got to have a resolution and it's a resolution. Number one is become a developer and learn how to code, you must learn the primary language in framework of the developers that you're trying to work with as a security professional. Not everybody is working in application security or product security. If you're an information

security, I do. And maybe you don't need to learn how to code, but if you're going to work anywhere, adjacent to developers, you have to understand the programming language is the constructs, the Frameworks, the things that they're using. And let me tell you this, the more you know about those languages, your eyes are going to open the code review process. When you when you're looking at someone's coat and you start to have an understanding for how code works and how it all fits together. You understand one object oriented language and you can code review, a lot of them. The

second thing is being able to explain the bill pipeline. So as a security person, if we're using this bill Pipeline and that's what the developers are using to build their code. And that's what we have, our security tools, integrated into a security person. You better understand how it works. I've heard too many stories of of different security people sing. Yeah, you know, our developers that use Azure devops as the tool to build their code and that's where we integrate the security tools and I asked him, like, do you understand that all the details of how to add your device works? Not

really? That's the wrong answer. That's something that you was a security person. Need to understand as well. The third part actually, right? And commit code, you want to blow the developers of mine's, right? Some code and commit some code into the thing that you're trying to help them with, with each of these. I've got an M50 boost to. So I want you to realize as you intelligently. Advise developers about the language in framework, specific issues you show. Women who care about their plight. Because you've taken the time to understand to learn the coding language. Learn the

framework that they're using. If you don't know how to do that, check out codecademy has a great place to start to learn a particular language or Pacific. Particular framework, at least enough to be to be able to talk intelligently with your developers. Developers. Frustration number two is nobody ever showed me how to security. And so, in your organization, developer knowledge and experience with security may be lacking. U.s. Security may be expecting your developers to react and do the right thing when they have no idea what the right thing actually is and you haven't taken the

time to explain it to him. This is the developer looking looking at us and saying, or us looking at them, they have security people looking at them and say, hey do the right thing for security and privacy. Okay, even though we haven't really talked you what the right thing is. Imagine going to your development staff and saying, hey, you know, we got a lot of SQL injections that are happening in our code in our applications right now. We need to stop that and the developers look at you and say, what's a SQL injection, right? That's the frustration. Nobody ever showed me how to security

well. Resolution number to says, build a security coaching practice in an education program. I don't chance to interview an individual from a large financial, and he was telling me about how they had built the security coaching practice inside of their organization. And the security coaching practice was set up in such a way that the, the members of the application security team would coach one-on-one various developers across the Run, has a shape, that is a brilliant idea. What a way to connect with those developers and walk shoulder-to-shoulder

with them as theirs. They're working through various security issues and being able to coach. One thing you got to do here, suggested path is Define a document. How you're going to coach for security figure out how to build that coaching function. Number to empower, your security team members in your security Champions, to perform coaching. This is more than just a Central Security team. This is all your security Champions. They are Neil of security and power them to go out and Coach other people, encourage them to coach other. The third one roll out an education program that touches

every product that Jason person when I say product adjacent, you have a number of people that's around. Whatever it is that you build theirs developers testers. Our site reliability engineer as a product, managers are program, managers people managers directors Executives. Anybody who is adjacent to the product needs an education and security license. They don't need this same specific things, but they each need lessons that are applicable to what their role is for you, listen to the developers all the time for feedback about what they need help with and build solutions to

teach and coach them. Frustration number 3 is, I don't know why we put so much effort and time into security. This is your developer talking to you and saying all this security stuff. Why do we have to do all this? When you think about how developers are compensated, that'll help you to understand why they asked this question. And the average organization developers are compensated in, in bonus, according to the number of features that they can produce number of bugs that they can fix. And we have the security team, were rightfully telling them all the time. Hey, there is a need and there is

value in building secure things we forget to do. If you forget to share the value proposition with them, the return on investment for the work that they're going to do to secure new features from the start shifting left. And also the rework savings they're going to be generated. So it's more than just Securing new features from the start that's super important. We want to shift left in our approach to security and, and start doing security as early as possible. But the other thing that we always forget to lean into, is there is a rework savings, every security issue. We can eliminate

left in the process means less rework after something goes to production and developers don't like doing rework think anybody likes doing rework, but I know developers especially don't like doing rework. And so that's something that we got to lean in to hear the resolution. Number 3 is start with Y and security Roi starting with why security is a very important idea and I didn't come up with this. Simon sinek wrote a book called start with why I read this book and I thought, huh, that's pretty interesting. And what he talks about is how we always jump into the what and the how when

were, when were taking something to someone. So you need to do this. We don't step back and say, Here's why you need to do that. And that's what I'm recommending here. Start with Y, start launching a campaign, to help those Proctor Jason folks, understand why security is important for your customers, not for you as a security team for your Executives, not for some other group inside of your company position this Through The Eyes of your customers. Because I think about how customers think about security these days. It's three hours its reputation as retention is requirement

reputation. Meaning your customers looking at you going, is this a company that takes security seriously or not? Cuz if they don't I don't really know that I want to continue to work with that, which is retention. So if if you don't have that retagged, you don't have that approach to security. Your customers are going to be looking to go elsewhere. The last are there is just requirement. A lot of customers have specific requirements. They send you this long list of requirements when they want you to become a new vendor. All of this, because they are so serious about security. Second part of

this is provide real metrics for security return on investment. Analyzed the data provide real metrics for the return on investment for security. That your developers are experiencing. I'll throw a metric out here. We got to throw. When I mentioned, I can't just walk away and not give you an actual metric to work from here. Start to calculate the percentage of flaws that require rework because of some security division, whether that's a tool finding whether that's a cobra view, finding it regardless of where it comes from, start to track that number start to look at that metric, start to

balance it, and try to build a case around the return on the best app for security. The more things we fix early in the process, the less we work, we have to do the more new cool features that we can build this developers can sell this. And 50 boost on. This was when we open the door for developers to understand why we do what we do. They're going to get on board and say I'm with you. I'm on board with our mission to secure the planet, whatever the planet means for you. Frustration number for the security process is difficult or undefined without guidance in a framework developers.

Just don't know what we want them to do. They don't know what the requirements are. They don't know what the expectations are for new future development, going back to the previous thing. I said, they're compensated and bonus to bakes based on being able to complete features fix bugs. And if you don't give them clear guidance, they don't know how that impacts what they're trying to do. Developers me crave predictability of the process. If you are operating a semi Out of Control process, then you're messing with her whole world. You're messing with their whole flow is developers

because they don't know what to expect. And if you don't have that predictability the process, it's just difficult and frustrating to gauge how much time they need to set, aside to do the security process. Related items were asking them to do. And what if your marching towards a Friday deadline where hey, I have to have these three things done for this Sprint, you need predictability. So that's the frustration. They have yours that often, we forget about predictability. We tell them follow the security process, you know, the hundred page document on the wiki. The resolution number for here

is use the security about my life cycle is guardrails. So when I think about guardrails, I think about a car going up a mountain. We have guardrails there on both sides of the road to keep us from going off the side of the mountain to protect us, but what the guard rails don't do with their not just to in wider than your car. So you really can't maneuver a whole lot. You got to stay really close and really tight to the right spot guardrails, give you some Freedom around the security process to have some creativity and leaned in to what you have to do. And so leaning into your secured of on

the life cycle, like it's 2021. You better have an STL at this point. STL is table Stakes YouTube on the life cycle. You don't have one get one quick. The other thing is just said, expectations, that define communicate the clear developer expectations regarding a secured of a life cycle in any other security processes. Remember the guard rails that? Keep that car from going up, the side of the mountain is this the developer and how they can stay in the security Lane and still do things a little bit more creatively. Frustration number 5 in this one. This just burns me when I get when I heard

this from a couple of different people. And as I continue to think about it, security changes their minds all the time. And so you'll hear this sometimes we're at the developer say, okay, when security was working with James team, they said acts, and when I spoke with our team, they said why, what gives, How can there be two different answers to what seems like? It's the same exact question. When you think about it, though, depending on the knowledge level of the people who are listening to the answer. Both answers may have been correct. The frustration that it's not about accuracy. It's

about the trust that the development teams have with the security people that are advising. Developers are looking for Clear concise, guidance on what security wants them to do. Just tell me what you want me to do, clearly and the experience frustration. When we lose that process predictability lose faith in the advice is Source. If it's not consistent, and if a developer loses faith in Securities capabilities, for many reasons, they're going to avoid bringing things to your attention. They're going to just say, well we'll just do this one without any advice or security, which we all know

what's going to happen? There. We don't want that. We want to be trusted advisors. This is security saying we don't change our minds. We re interpret the data. Sometimes we change our mind. Sometimes we get it wrong. It's a resolution. Number five is gain understanding an offer. A second opinion. You have to search for understanding and I do realize this is going to, this is going to grind some security people going to make them a little bit angry. And okay, I don't really care this attitude of us the security people saying. I'm always right. I'm from security. This is my discipline. I

have all the answers on how we work in a collaborative world. We can't just continue to believe that we have all the answers and nobody else can offer anything to help us. So, you got a search for understanding here when you're working with these. These developers, you have to search for in question, understanding, in any of the interactions that you have with them. You have to ensure that your team is giving out the same guidance, at least had a high-level perspective cuz there's nothing worse. Than if that example, I gave was true where One Security persons talking at Team backs and they're

giving one side of advice and somebody else is talking a team. Why not? Give it a completely different set of advice. That's really frustrating. Another thing that's going to scare some people here, provide a mechanism for developers to get a second opinion. Mean in the world of medicine. We get a second opinion all the time, right? We get a doctor tells us that we're like, oh, I don't like that answer. I'm going to go get a second opinion. Now, I get it. We don't want to create this world where there's this whole distrust and nobody thinks they can believe anything, anybody

saying? But a security, people, we have to be willing to once in awhile. Say, you know what, you might need a second opinion. Let me bring one of my colleagues, let bounce, this idea from them and they'll see what they conclude coming out of this. Here's the empathy boost for this one. Once again, this is going to scare a lot of people, but if you're wrong admit it and move on nothing builds. Trust like a person who's willing to accept. Hey, you know what? I'm not perfect. I don't have all the answers all the time. I'm trying to do my best to help you build the most secure product that's going

to serve. Our customers will protect our customers data. I don't have all the answers. Just just that little move right there can be enough to really build and gain some Trust. Frustration, number 6. From the developer's perspective, is I don't have enough time to do security. And we all know the old adage. Right? Fast. Cheap, good. You can have any two or three that you want off that list. But developers experience pressure everyday. Tied to the amount of resources. They've been allocated to do their job. And when we we live in a world where resourcing is confusing and we don't know if

security has been given the right mandate, the right resource, right? Allocation of time does is build frustration and it does it to the developers. It's not really Austin, even feels that thing. When a developer has a manager that hasn't bought into whatever the corporate requirements are going to be for security than the developer to do, what's right for security has to push against their manager and to comply with what security is degree. They just have to have to go against them and that's, that's not healthy. That's not good. And so I think about, you know, what if development flipped back

around on us from from a security perspective and said, hey, you know, you got 10 minutes to perform this code of your. You got 15 minutes to do that threat model right there. Like that pressure and not having that time, allocated that resource would be a struggle for us as well. So, frustration number 6, is not enough time to do security, the resolution. Here. We have to raise awareness about security resource need. We have to get by in at all levels. When I say all levels. I mean Frontline. Managers directors, Executives, everybody has to buy in, to what we're asking each developer to

do in regards to Security in our devops pipeline. We also have to provide estimates for how much time these activities are going to take. We got to do. So we got to create some metrics. We got to track these activities so that we can better advise our constituents and say hey here is the amount of time you really need to allocate. And I'm going to, I'm going to call and everybody launched a campaign to make everyone aware across your company. What the security resource needs actually are and what are the times that are involved with this? And from an empathy boost perspective as developers

start to receive this management support that they need a happier and more productive. They're going to be with you as a security team because they're not fighting against their own management. It's been allocated at the organizational level that we have to allocate time to do the right things for security in our devops pipeline. Frustration, number seven is security, is a silo and acts as a gatekeeper. In the world of devops, we promote open communication amongst everyone on the team. We say we cannot have a bunch of different silos that are that are

bumping into each other that are separated and doing their own thing. When we have that type of a silent environment. We know that the feedback is going to be slow or not going to share information, frictions going to be high. Everybody's going to be miserable. The classic security answer to devops Is to say that we live in the security Silo and we have all the knowledge and experience and we get to make all the decisions. So, you know, if you need something just let us know. But we're just going to stay here and guard this gate as a gatekeeper right here. This is nothing. But

frustration though for developers in a devops world because we want to move fast, we want to get stuff done and we want to get out of the way and just be able to do stuff. And so Gatekeepers are going to be frustrating because they try to control the process. I try to slow everything down to a crawl. This is devops. We're doing devops and security of got to do this at a high rate of speed. I don't want to be a gatekeeper. We don't want people to get keep against us as security. Imagine. If this got flipped back around and the gatekeeping was happening on the development side and they said,

hey, you know what? We're not going to run that static analysis tool. Yeah. I've been 2 weeks, but we're just going to we're going to slow this thing down cuz we got a lot of a lot of cool code to push the production so we can do that later that would never pass from our perspective. All I'm doing is flipping it back around and changing the perspective to make us the people who are receiving the bad news from our perspective. The resolution of a 7 till about partnership. We got a partner with the development teams. We got to let go. We have to build an automated process that takes security

integrated in devops. We tested we validated, we make sure we're happy with it. And then we let it go when we let it do its thing. We don't try to keep sticking our noses into it and trying to date. I want to do that. All that doesn't slow, things down and make everybody angry. We want to perform a proper assessment to ask. Are we gatekeeping? Do we have some of these bad habits? Ask your development audiences? Hey, is there any hint that we're gatekeeping here? Like a tough question. To ask you to be very vulnerable to be able to ask that what, that's what true developer

security connection collaboration, communication is all about. Partner with the developers, they want to work with us. They really do and by treating them as partners to look for opportunities to reciprocate, they look for opportunities to bring us into conversations, where things need additional security help, restoration number 8, for developers security, busy work. Developers need to see the value in any activity that were asking them to do. And so if you require a risk assessment or a threat model, for every new feature, then you take that and you just file it somewhere. Nobody looks at

it. You're wasting everyone's time you waste in developers time, you're wasting your time. You're wasting the resources of the cloud service, where you're copying the risk assessment. That's how passionate I am about not wasting anybody's time. If you're doing anything manually in your process, you're wasting some time as well, but we'll do that. It's a little bit more of an operation. I mean, we don't like doing busy work. But then as a security person, we might sometimes respond with busywork. How can you call riding a 100-page document by

security architecture? Busy work? We may think that's fun. Not necessarily every developers going to have the same conclusion that that's fun. So how do we resolve this when we optimize the process? And we make a note, busy were cruel. And with this, we have to review the artifacts value. Everything that we're collecting in our process. We have to determine is this adding value to the product to the application, to whatever it is that we're building collect feedback from developers. Say your developers to say, hey, would that new process for risk assessment? We went through. What would

you say on a scale of 1 to 10 is the value? What are some things you would you like? What are some things you would change about that process? Imagine the feedback you get coming out of that? And we have to be ready to cancel any artifacts in our process that we determined through communication. With our developers that they're not useful for the Improvement of security and or privacy. If they're not get him out of here, the empathy Bruce here is just thinking about the fact that hate you don't like to do busy, working your job. Provide them with security and privacy work, its

meaning bull to them and has value. Frustration number 9, the sky is always falling. We never celebrate success as security people would not known for our positivity, just not because our job is to chase the next boner ability the next problem. The next bug we seldom stop to celebrate and Pad anybody on the back and say hey that was a really nice job that you just stood there. And so in this environment where we live, you can always appear that the sky is falling and things are

getting worse all the time. But it's frustrating for a developer to work in that environment where they feel like they have this perception where nothing is getting better. Nothing's getting done. Why am I continuing to do these things over and over again? And there doesn't appear to be any different results. So frustrating to always constantly be negatively communicated with about security bugs with no hint or no, no, success. Ever being celebrated. As security people are going to say, hey, we would celebrate, but we just got to page for another incident.

Not excuse resolution number 9, is to celebrate our security wins. It's not that it's not that difficult of a thing to do. But the first thing you got to do, she got to get a feel for? Hey, are we doing this at all right? Now is this who are developers think that the sky is always falling? Is that how they're receiving us. Is it a security people that are that are causing this perception and then get ready to celebrate it all levels? And there's a million ways. You can do this Summer that cost money. Some that don't you can send an email or a team chat to a group of people or an

individual that's in a, in a chat, you know, in there for their particular group. I just saw you do something cool and I just want to let the whole group know about this or you really fix that security bug that we brought to your attention. Quickly, that thoroughly I did a CO2 gun. I was like, wow, that was a nice fixed right there to eliminate the security problem. Those types of things. Don't cost you anything a little bit of time. Sure, but they don't cost any money look for other places to celebrate your security wins, whether that's a group All Hands, whether that's creating a

program called the security wing of the month where you're picking, something that happened once a month and sending out an email or something that says, hey this really cool thing happened by celebrating security wins. We can make things better for our developers. When you work on a team that values these things. It just makes you look for other opportunities to do stuff to improve security and privacy. Restoration effort and security tools are loud, obnoxious and inaccurate as security people. We love our tools. We think they have all the answers for us. Guess what? They don't, they're

good. They're useful. There. Things that we want to ensure that we include are not the end-all and be-all and developers are frustrated. When we send them the results of a tool that generates ten thousand entries were supposed to do with that. How are they going to deal with ten thousand individual items? And so they're frustrated. Also, when tools provide false positives, left and right and so this is a security asking them will. Can't you just address all the problems with two reported but yesterday, It's frustrating to have a tool that's loud. Obnoxious and inaccurate

resolution of our tenants to tune. The tools. Assess two lengths. Are there tools that people developers are just super frustrated with that are in your pipeline. Even know that answer that question right now. You should you got to ask people, you got a survey you got to see how are our tools supporting our customer security. Our customer is the developer in the pipeline will not be overseer, gatekeeper for a partner slash. There are customer when it comes to the tools that we provide practice, the least possible, configuration mode, with a new tools are tools that you did, have a

terrible reputation, change that configuration. If it's generating a bunch of noise tick, the top thing, that's a problem for your organization and then use that set the policy to look for that. One thing build some trust in that tool. The last one here is don't be afraid of Yank, A Tool out of your pipeline dismissed, the underperforming tools people have this idea that I spent all this money on this tool. I could never pull it out of the pipeline, rip it out. Send it back, demand a refund pick, something else has best-of-breed in that particular class of tool and move on, but

don't let underperforming tools. Hang around and cause angst amongst your development staff. Properly tune, the tools that provide security and privacy value for Developers for you as security and the end of the day for your customer. So, here's the summary of the 10 resolutions that I had. It starts with tuning backwards. Make sure that you're turning the tools, such a way, is that they add value celebrate. Those winds security look for an opportunity to Pat, a developer on the back and say, hey, nice job. That was a great fix. You had their optimize the

process and we don't allow busy work. We want to be partners. There's no gatekeeping allowed. You want to raise awareness about security resource needs. So nobody feel that pressure to to argue with your manager, about doing what we're saying. They should do for security gain. That understanding are your developers offer a second opinion. If you need to use the SPL as a guardrail to keep them within a boundary, but not locked them into exactly. What they have to do, is make sure the developers understand why build that coaching practice, that educational program, and most important

become a developer, learn how to So you can do it. Last thing. I want to leave you with here is just remember we talked at the beginning about developer empathy practice that developers have empathy for security security for operations operation for everybody for everybody. Everybody's got to practice empathy. So here's my apply slide for you next week. You should find a developer job shadow for at least a week in practice developer empathy with them directly work side-by-side with them, shoulder-to-shoulder asked a million questions and understand what they do. And the pain, the

frustrations that they are experiencing and then the general frustration level within your organization within the first three months spent at least one developer to partner with. On these efforts. You can't just look down from the mountain and say, well, I went to the stock at r s a and now I know, all these resolutions, I'm going to start throwing these things out for everybody, to get to, to absorb some developers in practice developer, empathy and partner with them. So that they know that they're important in this process and that you want to work with them. I sent your organization

against The Temper stations, build a list. You can't fix them all at the same time. When in six months, you should deploy. Multiple resolutions to improve your security culture. Cuz at the end of the day, that's what it's all about. So I can clusion the dedsec disconnect. I talked about that tension between developers and security regarding the security of new features and Bug fixes talked a lot about developer empathy to say it again. Developer empathy is when security walks a mile in the developer shoes, understanding the struggles that you're your developers have with implementing

security. Pushing features doing bug fixes, understand where they're coming from, find that developer job shadow. Your eyes will be open so much wider than they are today in practice at developer empathy with them directly. Last part. Build a programmatic approach to understand these frustrations and apply the resolution of these things will work for you. But you got to understand where the true frustrations lie and how to take these resolutions and put them together into a programmatic approach. Thank you very much. You're listening for this conversation.

Cackle comments for the website

Buy this talk

Access to the talk “Developers Dislike Security: Ten Frustrations and Resolutions”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Ticket

Get access to all videos “RSAC 2021”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Similar talks

Joshua Corman
Snr Advisor at CISA
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Nick Jones
Senior Security Consultant at F-Secure Consulting
+ 1 speaker
Alfie Champion
Senior Consultant & Global Attack Detection Lead at F-Secure Corporation
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Wade Baker
Collegiate Professor of Integrated Security at Virginia Tech
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Developers Dislike Security: Ten Frustrations and Resolutions”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
816 conferences
32658 speakers
12329 hours of content