Resource Center  >  Webinars

Best Practices for Developer-Centric Application Security Testing

Webinar

00:00:05
Speaker 1: Welcome everyone to the best practices for developer centric approaches to applications Curity testing. I’m your host of this Bright Security webinar, and I am here with a lot of awesome people. I’m going to have all of them introduce themselves in a minute. But I just wanted to explain, like, you know, we’re going to talk about what is what do we mean by developer centric? We’re going to talk about all sorts of different ways to test your software. And basically it’s going to be an open discussion. We would love for you participants to ask questions in the chat. We would really like that. All the people here are, well, experience with live streaming. And so your questions help us know what you actually want to know. And so with that this is our agenda today. So we’re going to do some brief introductions. We’re going to have audience Q&A at the end. But you can ask questions whenever you want. And if it has to do with what someone’s talking about, I’ll kind of like try to weave it in and ask them after they’re done speaking. But if it’s something totally off topic, I’ll wait until the end. And so yeah, we’re going to talk about best practices and what are the risks. How can we do better, how to go faster? But rather than reading a bunch of words on the screen, what if you just met our guests? So did we have a there we go. We do have a slide. Would you like to go first?

00:01:30
Speaker 2: Yeah, sure, I have one. My name is Coso. I’m Cecil out here. Out here is a company that is part of our security, specialized in credit card fraud prevention. We’re a leader. And. In card fraud. I would say not in car fraud, in the prevention of the fraud. And we work with almost, let’s say, any bank, almost any bank in this half of the globe. And I’m happy to be here.

00:01:58
Speaker 1: Nice. Thank you. And next we have Randall.

00:02:05
Speaker 2: Hey, what’s up everyone? I’m Randall. I lead developer relations and community snyk. And basically, I’m like an engineer that does a lot of security stuff and I really love it. So I got started doing operating system security and was a CTO for a long time, building developer services and tooling. And now I work on finding and fixing security issues at Snyk, which is super fun. So thanks for having me.

00:02:29
Speaker 1: Nice. Oh, me.

00:02:33
Speaker 2: Hey. That’s me. Hi. Naomi. This is what I look like. I’m the director of product security at contrast. And we do all the things. Product security on my team. We’re small but mighty. We do threat modeling, security architecture reviews, QR code reviews, helping our engineering teams be awesome about what they do and ship the products as quickly as they want, but in a secure way. And I guess I have over 20 years of experience. Yes. I’m old. Yes, I am old.

00:02:59
Speaker 1: Represent.

00:03:04
Speaker 2: Everyone. I’m Han, I’m also old and with years of experience. I’m coming from a lot of background in apps, pen testing, and recently as part of the sneakers, part of the acquisition of security, where I cofounded together with my partners to really enjoy earlier. And thank you very much for having me.

00:03:27
Speaker 1: Them and. Oh, this is me. I’m Tanya. I’m also old. I, I I’m the founder of We purple. I wrote a book called Alice Babbler and Application Security, but I feel like my. Oh, this is a really old and incorrect bio. That’s not true anymore. But basically, I’m a giant nerd that really likes helping people build more secure software. I feel like you could just put that and that would be pretty accurate. So with that, what the heck is developer centric testing? So we wanted to talk about like what is this how this goes. And so I was thinking I could start with a question. And then anyone from the panel could answer it. And more than one person can answer the same question. You can add on to someone else’s question, like, basically it’s going to let us do whatever we want, which is pretty awesome. So the first question is like, in what ways can actually let’s okay, so I’m going to I’m going to cheat and not answer the first. That’s the first question. So what does developer centric mean. Right. Because security tools used to be built for security folks. What does a developer centric tool look like? What does that mean? I know that’s not on the list. I’m sorry, but all of you do it. So I feel like you really know the answer. Who wants to go first?

00:04:44
Speaker 2: Yeah, I can start. Okay. To be honest, it’s a way not to fight too much with R&D because at the end, security tools built for security guys developers sees that and freaks out. What hell is that? We don’t know that. That’s not part of our job. We have no idea this is lying. Mean it’s all false positive. This is usually kind of those are the answers that you’re going to get in some point or all the time. And by the way, I’m all too. So I get those answers for almost 20 years now. So oh, I get tired of that. So eventually a some companies decided that, hey, although it’s a security tool, but let’s make developers understand what the hell they’re watching mean and not feel dumb when they look at that dashboard. They this doesn’t actually make sense. Let’s check it. So this is what it says. Listen to me.

00:05:44
Speaker 1: Nice. Who wants to add on to that?

00:05:48
Speaker 2: I think I’ll go. Oh, wait. Oh go ahead. Sorry. Go ahead. Go ahead then. Well, I was just going to tell a story because I like telling stories. But one of the prior companies I was at when I was doing some development work there, my introduction to Astec was essentially the way it worked is. So let’s assume you’re you’re building some software and writing some code, right? So you’re like shipping stuff and you’re getting things out the door. Whatever. And then once a year, our security team would run like a very code scan or, you know, whatever the big OpSec scanning tool is at the time, or it just analyzes all your code. And essentially the net result of that was there’d be like some massive spreadsheet file created and the spreadsheet would essentially say like, okay, here’s like the the file name of the file in which a security issue is found. Here’s the line number in that file. And then here’s like a two sentence description of like what the issue is. Then our security team would tack on another column at the end. So add a fourth column that said like owner and then another column that said like fixed like yes or no, like a boolean option. And they would basically spend like the next six months just tracking down the last person who edited the file in which the vulnerability was found, almost doing like a git blame, and then like following up with them via email and slack and like sending them messages like every other week, like, hey, you needs to come in here like you have like 600, you know, unfixed things. And the whole process was really just about getting people to check off. Like the I looked at this box and like, did this thing. And so my impression was that this is absolutely terrible. And as a developer it was extremely annoying. So that’s like the opposite of your question. But maybe that is more relatable to some people.

00:07:36
Speaker 1: Um. Let’s think. Think that for me, I came to the point from application security perspective and think was on the other side of of that story. Um, but then, then try to take that in and do this as a, at a large scale development organization with dynamics of powers in the side of the organization that brings the business and that kind of OpSec didn’t really just just work as it is, had to somehow include that and think that. As part of this journey. To learn what this means, just recognize at some point that we are not the hero here in the story of software development developers, how developers are the hero. And if you’re trying to do a good to to to lead a good journey to save software, you have to recognize this. And you have to start thinking, how can you let them get to that point where they understand security and the road is not that short and simple, but it starts from recognizing that their their product is the main thing that drives the entire industry, is the thing that we’re trying to protect. And we are we are the sidekick here. We’re trying to protect it.

00:08:52
Speaker 2: Want to add on just one more thing that when we make things developer centric, it works with their processes, not with the security teams processes necessarily. Like I’ve worked with so many security teams where the devs are doing sprints or the devs are doing this and they’re like, oh, well, we’re going to have like a code freeze for like three weeks where we do a code review. And I remember my team saying, are we doing that? Like, we’ll do whatever we want. We’re going to keep writing code. That’s ridiculous. Where are we going to just hang out for three weeks now? Just ignore them. We’ll just check it all in the Monday after, like so. You have to. It’s working like making tools that work the way devs work and work. Like with their tools. Anyway, I digress, okay, so I’ll ask the real questions.

00:09:36
Speaker 1: Now I just wanted to add something to this. That’s 80% of dev centric OpSec is about trust. At the end of the day, it’s not really about the tool. It’s creating trust between security teams and developers because usually everybody is defensive because developers see security themed apps, apps, guys smiling. Yeah, we have findings. And then they said, no, it’s all false positive at the end. They need to trust us. We need to trust them. And it’s about trust of all the findings.

00:10:08
Speaker 2: Like it. Okay. Next. For real, I’m going to do the first question. Now we’re only ten minutes in. I’m doing great. So in what ways can developer can a developer centric approach to securing our software help organizations identify and address security risks earlier in the system development lifecycle, and is doing things earlier good. Yes. Know the answer?

00:10:37
Speaker 1: Do you need more than that? It’s like. Yes, yes. We all. We all knew that. I think I think the term is like shift left, but I think that term is dying in the way of the dinosaurs. It’s more like shifting smart at this point. It’s like the developers know they care. They do care about security, even though sometimes they give you pushback. As a security person, they do care like people, like people. I wrote code for ten years. I am proud of the code that I wrote, at least the later stuff. But, you know, like we care because the developers want to do a good job. And that includes doing good security too. And if they don’t care, then that’s a problem. We should have a conversation with them. But in general, I think the developers would want to do the right thing. We just need to, as security people, give them that guidance and the tooling and all the stuff that they need to do that stuff and maybe even do it for them sometimes.

00:11:27
Speaker 2: Yeah.

00:11:28
Speaker 1: It’s so early detection of what a reduction of an ability is. If you’re not ready to take in a backlog of inabilities, maybe the early detection is is where where is important to invest, what are the critical assets. And also the early detection is about detecting your controls. What is your actual situation where the real problems before you go all the way to push early detection of the vulnerabilities all the way to the developers. So I think it’s a complicated question. Like like a like pointed out shift left is in the way of dinosaurs, I think. I think it’s exactly to that point that we need to be a little bit smarter on how we do this and how we how we loop in developers in the right way.

00:12:15
Speaker 2: I’ll.

00:12:16
Speaker 1: Oh, no. Randall. You go.

00:12:18
Speaker 2: I’m just going to add one more.

00:12:20
Speaker 1: Thing, which is if you’re watching this and you’re a developer like me, I would say, um, the the main thing is, you know, it’s like part of any sort of hygiene task for a developer. Like when you start out and you’re getting started writing code and building stuff, you probably just using like a text editor and like writing some code and like running it and seeing if it works, you know, and then as you like, do stuff a little bit more, you realize it’d be really nice if I could like, link the code first as I’m writing it. So maybe you install like a fancier editor, like them with a bunch of sweet plugins like me. Or maybe you’re like more visual and you really want VS code or something. And some great extensions to help give you the little red under highlight thingy and say, oh, you forgot the semicolon or whatever, and you’re catching those things earlier, so it’s not as annoying to constantly switch back to the terminal. Terminal rebuild rerun. It’s just it’s time savings, right? And then maybe you get even more sophisticated and you start applying like nicer linting. So you say if you’re a Python developer, maybe you use Python black and it helps auto format your code into a consistent thing. So you have the same whitespace everywhere, you have the same, you know, amount of spaces between the imports and where you define your classes and functions. And it just looks way nicer so other people can read your code more easily and maybe get better comments. Right. And you have some tooling to help identify those things. Security is the same way, you know, it’s just a part of like writing good code and like caring about the craft is using the tooling early. And as you’re writing code, finding the issues that are going to be problems. And so maybe you see a little notice that, oh, Randall, you forgot to sanitize. This is your input here. You need to do that or call this function or method you’ve already defined to help help out with it. Right. But you just want to have a nice development process to save yourself pain in the future, which is really what it’s all about.

00:14:16
Speaker 2: Yeah. Think think that back to this point, like you’ve been everyone everybody has been on engineering project, whether like for fun or professionally experienced, this kind of evolution and looping in more capabilities. And, and now in 2023, we have a lot of capabilities that are quite mature to loop in without so much hassle. I think that the security industry started deliver first generation of scanners and security tools, and they were not ready to the level of maturity developers are expecting, where the looping in additional things, like if you try to integrate with, say, you want this mono repo facility and you want to start building on it, but it’s not complete and it gives you a lot of frustration, you will get antagonized by it, and it will take some time until you try to onboard a different one. Please keep me honest here. Um, but I think the same thing happened with security solutions and things like, like what white offers is to loop it in in the right way, give a lot of a lot of transparency into what is going on in the scan itself. Get the developer involved brings a lot of a lot of options to get this good infusion of the workflow to the natural, organic workflow the developer.

00:15:35
Speaker 1: I will add one more thing to that. One thing that’s usually in the past. I mean security. Our goal is to bring findings, create noise, bring me alerts every vendor. Yeah let’s pile pile them up. You see a dashboard with 10,000 alerts and everybody’s smiling. Yeah. We have we have everything we know everything about. You think that today our goal is not to create more alerts we want. To cut the noise, get rid of all sorry for saying bullshit and all the low level and all the noisy findings, and be focused on things that are really critical. And this is what actually rights bring to the table. And this is the level of maturity that I expect from all of my vendors. At the end, I don’t want just, you know, loaded, be loaded with alerts. We don’t necessarily alerts that at the end will investigate and waste a lot of time and realize that there is nothing to do. There is no risk. DNA won’t cut through the noise. Focus on what are the top thing, what should I leave everything and take care of right now? This the most important part, at least for me.

00:16:42
Speaker 2: Nice. Okay. This is good. So I’m going to have I’m going to ask if Naomi could start on this next question. And so the summary is how do we balance speed and security. But basically like when we’re trying to start security earlier, we’re trying to be more dead focused. How do we balance that? How do we balance. Because devs want to go fast and security people want to be secure. What are some things we could do maybe to help us balance?

00:17:11
Speaker 1: I love that question. Dude. Did you make that one up? Or was that like.

00:17:15
Speaker 2: No, it’s totally Amanda.

00:17:16
Speaker 1: Totally Amanda. Great job Amanda I love it. This is like the crux of it. It’s such a human problem. Like you have to get their buy in to to love security with you. Like if you are the most passionate person about security in your team and your company, like that’s going to be a tough sell. But if you can maybe infect them with your security virus. That was a terrible analogy. I’m so sorry, but if you get them on the bus with you, like you’d be like, security is awesome. It’s fun. It’s. And here’s and then show them a couple of exploits and be like, look at what could actually happen to our app and to our data and to our company. And then they get the buy in, they’re like, oh, okay. So like and then the eyes are like the light up the, the, the angels are singing. The heavens light up and their eyes go, oh, it’s like once they get that, they get it. Then they will do it with you. Like it’s no longer like, oh, we need to take a week out of our sprint to do security things. It’s like, let’s build this in, like, let’s make sure we do security. And and then you as a security person, make sure you have the process in place. You’ve got you’re with them during the sprint. Like you’re not just delaying their request for meetings and request for advice like you’re right there with them so you’re not slowing them down. That’s like a huge part. So you get the buy in. That’s the one. And then to like really be available. I think someone mentioned earlier like we are not the heroes in the story. Like we are not the heroes in the story. We are the sidekick. We are the plucky sidekick with the big teeth and weird haircut. Like, that’s us. So we need to help the developers get to where they’re going. We are the sidekick. We’re helping them get there and then like, whatever speed they need to go to, if it’s fast, help them go fast, but also do it the right way, right? Good question. I like that, Amanda. I’m a fan.

00:18:52
Speaker 2: Me too. Does anyone else want to add on to this? Like how we could try to balance speed and also still getting things safe when they’re at the door?

00:19:00
Speaker 1: You know the analogy. In some of my lectures, I always compare security to cars and to brakes in the car and always ask, why do we need brakes in the car? And everybody says to stop and said no, so you can drive faster. That’s exactly that’s exactly the point. We put security and we embedded security in our processes, in our applications. So we will not fear to run fast. We want to do it. We want to do it once. We want to do it right. I mean, starting from the beginning, not to build everything. And then, oh, then we forgot something and then let’s start building security around it, near it. And I mean, my perspective once we were built right from the beginning, it will work and it will last for a long time.

00:19:48
Speaker 2: I like Randall’s comment in the slide. I’ve got a lot of experience of driving fast in Mario Kart, and that’s the handbrake for the power slides. Awesome. Does anyone else want to add anything in who’s named Randall?

00:20:02
Speaker 1: Oh, I’ll add one thing, but I do a lot of cryptography work. And in cryptography there’s usually like a direct trade off a lot of the times between speed and security. Like, password management is like the canonical use case that everyone thinks of when they think of this problem in computer science. But let’s say you’re building a website and you’re storing someone’s password, but everyone knows you shouldn’t store your password in plaintext. And so what do you do? You use a password hashing algorithm to take the password, convert it to something that is verifiable in the future, but unrecoverable, like you use a one way function. And there’s a lot of different options you can choose from there, but the good ones take more computing resources to generate. And the reason why is because that information never gets leaked or breached, or whatever it is. You want to make an attacker’s life as expensive as possible. So they need to rent like a ton of CPUs. A ton of GPUs have a lot of available memory in order to just guess and try to brute force your password hashes. And so there is a direct tradeoff between speed and security. And in our space, though, that trade off is very small. So when you’re talking about building things as a developer and literally like speed in terms of like getting things out the door, you have a couple options, right? Like imagine using some tooling where every time you you save a file in your ID, you run a security scan and you scan through the code and you’re like trying to find obvious security issues, right? If that scan takes like ten minutes to run, that’s a problem. But thankfully with modern tooling, that’s no longer the case. Like, you can run those types of scans within an ID, not even realize it’s like impacting the CPU. Use a super low amount of Ram and get results pretty much instantaneously. And so it’s like a non-issue. I think some people are still sort of, you know, if you’ve been doing this for a while, like all of us in this panel have been, I think everyone has a little bit of PTSD from back in the day where this wasn’t like a feasible thing to do. And I think the whole term shift left in having developers do more of this stuff themselves. The most interesting thing, if you’re new to this, is just understanding that, like, there’s great tooling to do all this stuff today that isn’t slow and does not impact your speed stuff at all. And so, you know, while whereas in cryptography, you have this big trade off between the two here in the real world when you’re doing OpSec like there is no trade off. And so it’s really nice. And so that’s all I was going to add.

00:22:33
Speaker 2: Awesome. Okay. So we’re going to slightly slightly switch gears to use some management words. So the management C word collaboration. Um so what are some challenges that application security professionals or teams face with devs when they’re trying to collaborate like and and also like, what can we do about it? Has anyone ever had a problem collaborating or asking?

00:23:02
Speaker 1: It’s like asking how preparing react through fire. Usually, hey, that’s usually the first introduction. Hey, this is the apps. Those are the developers. And then boom. And we usually allow them to fight a few days before we tell them, hey, you’re the same team. You need to work together because nobody leaves until we’ll sort it out. But yeah, collaboration. And I believe at least in my organization, we try to build a culture. I mean, security is not just a thing that because the CSO wants it or because the object wants it. And we try to get try to give hard time to each other. And it’s a we see that as a kind of is a joint goal of the company. At the end, we treat security, security findings for abilities as bugs in the code. And we all want to at the end, we want to produce a better code, a better product, and, you know, protect ourselves from bad things to happen. And this is part of everyone’s goals, by the way, in the company mean once we managed to edit it as a part of the developer’s goal goals. It works because it becomes part of their job.

00:24:19
Speaker 2: Nice. Anyone else?

00:24:24
Speaker 1: Um, it’s not it’s not super structured and structure this perspective, but I think that there is a point in, in the kind of different frequency between developers and OpSec. And this has been in this panel already for discussion from different angles, but eventually, traditionally, as abstract people try to leech to the standard process of development through like a secure in the SDLC. Very presumptuous, by the way. And by that time developers were so unhappy with it, with the waterfall style process. So just completely broke it and unleashed agility. And and the challenge is, is in there is in us a little bit stuck in this old model of ghettos, of waterfall developers unleashed and looking forward like a and looking forward for for new options to do the things better all the time. And and we we kind of think with shift left specifically we kind of had we missed out on the ownership question like it’s not just developers own and developers own part of it. We own part of it. The problem, the challenge is in there. And for developers, this challenge is like our story in it is a subset because they already have this challenge with the product teams. They try to prioritize and make decisions and choose compromise. They deal with it all the time and we are only just one additional or an important thing, additional thing in there. And and I think this is a huge part of the challenge for the solution. Probably will have another question. But but this is I mean think the core of it.

00:26:10
Speaker 2: I want to add a brief story. So I was a dev for a long time, and then at the same company I switched to application security so I knew everyone. I was already their buddy. I’d already had coffee with all of them and like had inside jokes with everyone. And so I’d be like, hey, I found this thing and we would chat and it was really peaceful. And then I started doing security at another company, and it was so different because the previous security team, in my opinion, were a little abusive of the devs, like when I saw the way they spoke to them, the things they said to them, I’m like, don’t treat them like that. Why are you being so mean or like that’s not helpful. And I remember having to explain like the problems us, it’s us and trying to break that down. And so I have I’ve had many professional mentors over the years and one’s named Nikki Becker. And she the way she introduces herself is she’s like, hi, I’m Nikki, I’m from security and I come in peace. And she’s like, it sets the stage of, I know someone might have been mean to you before. I am not here to do that. I’m here to help you make better software. I am here not to get in your way. I’m here to help you do. Awesome. And she’s like. The conversation completely switches, so I just like, do what she does and it really helps. But that’s what that’s what we’re getting to next is how do like what are some of the ways besides being funny like Nicole? What are some other ways that we could try to maybe collaborate with them better? Or are there tools that we could use or processes like anyone have ideas other than making fun of myself?

00:27:50
Speaker 1: Mean, being good at what you do really helps give them like good, good advice that’s helpful and actionable. Give them the tools that they need. Like just be really good at your job. Don’t suck. That really helps win them over. But yeah, being nice that helps to self deprecation. That helps too. But for sure the being competent goes a long way. It’s like 99% of it. Being able to write code helps to know.

00:28:16
Speaker 2: Yeah. Anyone else.

00:28:20
Speaker 1: Now think, think your story. Tanya is is is also in the in the mega story like with this think snake is a company that chose this started from developer perspective. And now after after 20 years of OpSec, we have a lot of OpSec people who try to build security solutions and walked in the shoes of the developers and and think also it’s really important to deliver to like be competent. It is think it really is very very important and understanding this. So for example, it’s much easier for a company to build up workflows around integration and the right checks in the right time and the right feedback to developers, or the right instrumentation of some tests in the right flow, with the right control and the right transparency to what’s going on. I think that really shows. And this this brings us to this point that we we could actually really build this up.

00:29:16
Speaker 2: Awesome. Um, I also want to mention briefly the idea of Security Champions programs. I almost every place I’ve worked have inadvertently or on purpose started a champions program. Or if there’s just this one developer on each team that I tend to talk to the most, and they’re the person that’s kind of pumped up or interested or curious about security. And they’re the ones that always email me. And then before I know it, I have like my my group of people that I always talk to and I want to hang out with. And so Security Champions is something we spoke about at a previous webinar for Bright. And so that’s another way that maybe you could start building bridges with different teams is like trying to teach some stuff, trying to spend time with them. I guess it sounds weird, but like a cup of coffee can go surprisingly far. Um, or cookies. Cookies work really well. Okay, but I’m going to try to get back on track. Um, so has anyone seen any specific strategies that organizations can employ to encourage developers to take more ownership of the security tasks and contribute more to the security processes? So I realized I just sort of stole the answer to that. Oops. With security champions. But are there other strategies? Because there’s a lot of ways that you could try to engage with developers and try to help them take more ownership. So anyone want to add something to that?

00:30:39
Speaker 1: There are a few ways I mean, to, you know, bring them to our side and not just bring them to our site. I mean, it’s us coming to them kind of mid somewhere in the middle. And so we do have a security champions program, although we don’t call it security champions. Called security advocates. They supposed to protect their products at the end. And they mean by protecting it. Mean it’s their responsibility. I mean, it’s kind of a it’s a responsibility that they get from the team leaders, from the group managers. And by the way, it’s not a punishment. At least now it’s here. I mean, some companies consider to be punishment. I mean, the if you did something bad so now you will replace them, you will be the security champion and you’ll need to work with the security teams. But no, actually we get the good developers to answer. And the goal is the goal of all of this is actually protect and protect the software and and really discover the main problems and fix them as quickly as possible. Why? Because we all have joint goal joint goals. We want to protect software. We want to make our customer happy. We want to pass all our get all our certifications, make everybody happy and stay secured. And the way of doing that. Yeah, it’s a lot of communication. I mean, not something which is really common between security people and developers. Usually those are like like two kids today instead of talking, they just texting each other from one meter. I mean, I can see my kids doing that. They don’t talk. They just text each other, but they sit on the same couch. This this is how they communicate. And and yeah, this is like same as apps guys and developers think about ten years ago, they never talk. They always kind of shouting like divorced couple. And but I think in the end when everyone tried to understand the other side and at the end the management kind of help and kind of put it as this is your joint goal, you live together, you have to and and this is what works for us. And this is why try to implement in every company that I’m part of. And so far it goes pretty well.

00:33:00
Speaker 2: Nice. Oh, Randall. You go. And then I want to read out some of the things that are in the chat for when people listen to this later, because there’s a really good conversation going there. You go first. Yeah.

00:33:10
Speaker 1: There are really good chat comments by the way. So if you’re if you’re paying attention, then shout out to you for leaving some cool comments. I was just going to add one other thing. So depending on the culture at your company and the types of people you hire, etcetera, this may or may not work, but I’m a big fan of like security teams, just like jumping in as engineers, just like help with stuff. Because fundamentally like the biggest issue that you run into it like larger companies anyways, is you have like a couple security people usually, and a lot of engineers building stuff, and the security people are looking at these dashboards where they just see like a ton of issues, a ton of risk. Developers don’t look at that at all. And so, like, if you’re on the other side of the house, you’re building stuff you’re thinking more about like, okay, cool, we’re like shipping this thing and we’re doing this other thing. So security isn’t like the main thing on the top of your mind. So if you’re in a culture where the OpSec people are friendly and able to just jump in and do stuff, I would just jump in, say like, hey, here’s some low hanging fruit issues that I can fix as a knapsack person. So maybe I’m going to send a pull request and then hit up, you know, the lead developer for this project and be like, hey, I submitted this pull request. Maybe it’s not perfect. I’d love for you to do a code review or whatever it is, but it’s fixing this issue and just like build rapport that way, like you, you sort of bond in the trenches a lot of the time, just like having shared trauma or just like going through something difficult together, there is no better way to go through something difficult together than to just jump in and like, try to fix stuff and have a good time. So if you are in that sort of organization, I would also highly recommend that as a fun way to bond.

00:34:46
Speaker 2: Actually. Yeah. Like. Like that.

00:34:48
Speaker 1: But be cautious. It’s not suitable for every organisation and every engineering team. Be cautious and be respectful of the fact that, you know, they might have a different professional standard than you. So proceed with cautious.

00:35:02
Speaker 2: For sure. Okay, so in the chat we’ve got Rostam saying, I think it’s worth platform izing, depending upon where you come from, the security function and having a more platform engineering approach to security by providing and enhancing a platform for developers to write more secure code and giving them more responsibility. And so, adding on to that, gray says, one thing we’ve done is to also make everything we do as a security team be visible. So we do an open source approach with the tooling and capabilities we build. We welcome developers to join for tooling, evaluations, etcetera. And then it breaks down the silos between the two teams. Another person added in, one thing I like to do is be flexible on certain requirements of the testing activities and understanding the limitations of the dev teams I work with. Some of them may be having a lot on their plate, and they always appreciate when we give them some extra time on non-critical issues. I feel like all of this is around communicating more and talking more, and I’m really extroverted and so I’m not your average IT person. Like with all the devs, they’d always be like, Tanya will just talk. You just tell them what we said. And and when I was like the dev lead. Right. And so I feel like if we can get people talking more and more comfortable, that’s a huge win and everything moves forward then because I feel like a lot of all of the answers come down to like, what if we just had a coffee and chatted or something, or tea teas allowed to? I have some more questions, but I want to tell the audience that we’re getting close to the part where you are encouraged to ask questions, and so get ready. So the next section we wanted to talk about was basically tips on how we could empower developers and how to implement effective apps strategy. And so my first question that I have in this section is, what are the key benefits of empowering developers to take an active role in apps? Well then then I don’t have to work so hard. That’s the number one one. But what what are other? So if we can get them to be more of an active role when it comes to securing software, like, what are some of the good things that could come of that? Everyone’s quiet.

00:37:19
Speaker 1: I know there are plenty of things. First, we usually offers in cookies. By the way, it’s always helps if you do this. Hey, we can take care of you. And that’s the first thing. But usually, I mean, think at the end it’s part of shared responsibility. Mean this is not just securing the product or security software. It’s not just security team goals at the end. It’s it’s the whole company’s goal and it’s a part of it. We want to have working software, and at the end we want our applications to to run and work and, you know, give benefits to our customers. And we wanted to keep it secure. Why? Because if something will happen, that mess, everybody will need to help clean it up. So at the end those are joint goals. And and think it sums up in the end that building culture, that it’s a shared responsibility. It’s not just about security. It’s not that, you know, it is only responsible of making sure that everything is working at the end. We all want it to be that way. And part of the advantages of working in a company that runs more than 20 years, that culture is already exist. And, and, and I honestly believe that it’s really helps a building this culture that security guys will spend enough time with the developers build, build those bridges. I mean, make developers part of security decisions. A now it’s here, for example, we when we testing new tools, we add R&D into and we give they bring their opinion. They they help us to test the tools because at the ends know the ones that are going to use them more than us and think this is one of the number one. When they feel part of it, they will take part of it. When they feel aid. Somebody brought a tool, he scans bring and then we just get tickets from the other side. Usually he doesn’t help and they feel like, so they don’t care about us. So we’ll do we’ll fix whatever we want and think. As I said at the beginning, I think it’s all about creating trust, creating a organizational culture. And they work together.

00:39:35
Speaker 2: I can share a story and maybe a little bit different than than what the question was aiming for. But we had, um, so one developer when when we were my partners right before ends, we were part of the Wix security application security team, and at some point we were very active with developers. We tried a lot to facilitate that modeling processes to to explain and also to use Wix platform to build up a system to take this data in. Um, and then some developers got more interested in one developer really digging into something and found a remote code execution through template injection in a very interesting consideration. And. And so what we did was to just completely celebrate this. Like we just made it into a to a video showing everything that they didn’t fully exploited it and pushed him to present it in a server guild and like, fully made a huge fuss from it. And, and the impact was that at some point this guy asked to join the team, the application security team, and with a lot of ammunition of a very strong developer, he built up some really cool capabilities in dynamic scanning and like really, really took all his knowledge, inspired in him to be more in security up to a level that he was. He came as reinforcement for our team. So I don’t recommend this as a practice for everybody because you get mad and when you pull people to your team. But this is an impact that that can happen and think that another version, they get more interested. Think Naomi said before it’s about making them intrigued, interested in in security.

00:41:22
Speaker 1: So what are some of the ways that we could try to incentivize them or attract them or get them more interested in this. Like so obviously there’s cookies. We’ve discussed that at length. That’s an important strategy. Bribery like with goods. Carbs and sugar. Yeah, but. But there’s more.

00:41:45
Speaker 2: That’s so healthy.

00:41:47
Speaker 1: Well, they’re developers.

00:41:49
Speaker 2: And we’re security. None of that is healthy. So mean.

00:41:52
Speaker 1: No mean to the relationship. To build it this way that you get cookies for you build.

00:41:57
Speaker 2: You build addiction. That’s what you need.

00:42:01
Speaker 1: I think I have a good answer for you, Tanya. Maybe a little non unconventional, but so so in general in your developer community, within your your company there should be at least one person, 1 or 2 people depending on the size of course. But like there will be people who care about security. There just will be. So what you want to do is focus on that person, whether they’re on a development team or like an architecture team, whatever. Like focus on them and like get them involved with their own team. Like, so you are the advocacy program. Like you get them to spread the security virus again with that analogy around to their team. And then they actually are like the most important piece in this puzzle. Like if you get them to start getting the other developers, like be like, oh yeah, that’s cool, that’s cool. I really like security stuff. Then that’s a lot better instead of you just like spreading all your eggs and be like, okay, my analogies are all over the place, you know what I mean? Like, you don’t want to you don’t want to focus too much on the other developers who really won’t want to talk to you honestly because you don’t have the rapport, they just don’t care. They have their work to do, etcetera. But if you just get that one security for the security interested person to advocate for you, and that’s the whole premise of security champions, I get that. But like they will do the work for you and it’s kind of beautiful. I will say.

00:43:14
Speaker 2: When it works, like when you manage to convince them to work for you, it’s kind of have an insider in the team. By the way, another thing that we did, and I think we started at like last year, is to add secure coding education and not by mean bringing another lecture. I mean do it once a year. Everybody is interesting security for ten minutes after and then it’s all gone away. So we brought a platform that actually give them free access. They can do all kind of tasks and tools and kind of capture the flag. And at the end of the year, the team that will make more points than everybody else will get something mean. I mean, this is kind of an incentive. And it’s like kids, you bribe them a little bit mean. And we try to do a security hackathon. Using that, we created a terminate. So we put them in teams and let them play. And we funded full day. We already pizzas and beers and make something fun out of it. And it’s all about security. It’s all about secure coding. And everybody was happy. I mean, it was kind of a team building event, but it was an airplane in security, which was kind of great.

00:44:29
Speaker 1: And I’ll add one other thing onto that too, which is we’re essentially just talking about like psychology, like how do you convince people to do something new. And there’s fortunately a ton of research in these areas, right? There’s a lot of techniques. If you scroll through Instagram, you get like flooded with them constantly because marketing and advertising people have nailed these things for years and years and years. Um, one of the approaches we’re we try to sneak, which has been pretty successful. This is just the, you know, one use case or one data point, I guess, if you will. But we tried gamifying it just to, like, provide positive reinforcement and show recognition to people when they do cool stuff. So what we do is we actually have an application we built and customers can provision it, and what it allows them to do within sneak is normally if you’re using a product like sneak, you’d have like a dashboard where security admins take a look at it and it shows them a list of all the vulnerabilities that are there, what the priority is for each of them, you know, when they’re getting fixed, all that sort of stuff. With the new tool, though, it’s more meant for developers to look at. So it’s like a web page you provision, it’s like a leaderboard, and it shows you how many points each developer has for fixing vulnerabilities. So you get more points for fixing critical vulnerabilities than you do for fixing low severity vulnerabilities, as an example. And we even started running an event every year called The Big Fix, where you compete against everyone in the world to see who can fix the most vulnerabilities and make the most positive impact on open source software and things like that have been really positively received. Because even for people who like, don’t really know or care about security, it’s like a fun way to like, learn something new, get recognition, and feel like you’re part of something and like making a difference, which I think everybody craves at some level. So I would say positive reinforcement, a little bit of gamification and just show appreciation to people when they do cool work. And if you do those, those things, I mean, you can you can have a very nice culture and everyone feels like they’re part of a group and like making progress and all sorts.

00:46:32
Speaker 2: Okay I’m going to add something on. So a thing that. So I read this blog called Hella Secure. My friend Ray and Aaron write it and Ray has this thing where he’s he’s like, the developers are my customers, and it’s my job to provide good customer service. I’m here to help you. And he’s like, I help them with anything. I don’t care what it is. Because then one day when there’s a really big bug and I really need help and I ask, they say yes. And so I started doing that myself, where I’ll ask, okay, so is there anything else you need help with or and, and it can be like anything I’m good at. Right. And sometimes that means like reading over a technical document for them for like language. Because English is my first language and French is my second language and my French sucks, but my written French is not very good, right? So I would want someone to read mine over if it was in French. So whatever. The thing is, and I find that at some point they’ll ask you for a thing that’s they’re trusting you just by asking you. And I remember two years ago these devs said, so you said you would help us. Yeah. And they’re like, so there’s this thing and you could tell everyone got like really tense. And someone else, two other people in the security team had rolled out this product, take away admin rights. I did broken localhost for. So the loopback was gone for every single day. What this means is in their ID they couldn’t run their code. You can run their code and see what they’d changed and if it worked or not. And they only released to dev once every two weeks, and they had to do the stupid change management thing because because life there was hard sometimes anyway, so they couldn’t see any updates to their work for two weeks at a time. And they’re like, we know we’re not allowed admin rights. We really, really like localhost. And is there? Yeah, of course. And so it turned out the tool had been rolled out wrong. And so we scrapped it and we redid it. And it was a whole project. Right. But all the trust was built from that going forward. Like whatever we wanted to talk about, they were open to it and it took them a lot of guts to say it because they had said to the other team, like, you know, it’s like making our work really hard and they’re like tough, blah, blah, blah, and they like, didn’t. And I was like, did you ask them for feedback? And they’re like, no, they should just know to give it to us. I’m like, so you did something to the way they work. You didn’t ask if it’s a problem, you know what I mean? And so, like opening up those lines of conversation and I feel like rewarding and, and all of those things is good. But sometimes you need to have that hard conversation where it’s like, we made a mistake and we need to like, reroll it. The security tool and I actually rolled out a security tool there a few months later and totally screwed that up, and then had to reroll it out and take another day to scrap in two more days to roll it out, because had messed up the notifications and was spamming everyone into oblivion. And so we all make mistakes and we just need to learn from them. And so does anyone else want to add anything else, because then I’m going to go into the whole, like we’re going to wind down and tell everyone how to reach us and and have some final thoughts if anyone want to add more. Nope. Okay, so there we go. So the second. So the audience has already been asking us things throughout which I might have taken credit for some of their questions. Um, but I wanted to first just, like, put this on here. So if you want to contact someone from this. Webinar, you have our contact info and which companies were from, etcetera. But I wanted to ask each one of the panelists my favorite last question, which is from all the things we talked about today. Which thing would you want the audience members to remember and maybe apply later? What’s the most important thing that that you felt you heard today? And it can be what you said or what someone else said. Who wants to go first? Well, Naomi, you’re at the top.

00:50:32
Speaker 1: I like I like Naomi’s idea about hunting for the developers that have, like this already. Some some interest. Think that this is a good advice and and recommend following and and generally the theme of making it interesting and the theme of of instrumenting and making it easy. So like a tie, transparent, interesting and easy. These would be the three things that I’d recommend taking from here.

00:51:03
Speaker 2: Nice. Who’s next?

00:51:07
Speaker 1: I like the idea of us being second. We play second fiddle to the developers. They are the heroes of the story. I forget who mentioned that one. I think it was maybe Chen. I like the idea of Gamifying that was from Randall. I love that one and just being more approachable as humans. I think that was you, Tonya. So those are the three things for me. Nice.

00:51:32
Speaker 2: And who’s next?

00:51:34
Speaker 1: I’ll go next. Think communicating more communication between security teams, developers and you know, building bridges, not just throwing tasks, you know, from the other side of the floor on each other, usually a good thing. And, you know, sometime a cup of coffee together. Great. It makes all the difference.

00:51:57
Speaker 2: Absolutely. So true.

00:52:01
Speaker 1: And I liked a lot of stuff. I think it’s pretty cool to quote from a security blog or whatever. Like developers are like your customers essentially if you’re on the security side of the house. And so what it really boils down to is just like, be a super cool, nice person to work with. Whether you’re in security or development, try to improve your craft as much as you can. The curious part of that craft and so like, feel like you would in any other part of the job. You want to be good. You want to like focus on it and like care about it and just like, be able to work with people. You know, it’s weird being in technology because I’m not sure about you all, but part of the reason I got into development in the first place was to get away from talking with people, and it turns out, damn, no matter what you do, you pretty much have to work with people no matter what. And so if you are going to work with people, you might as well enjoy it and not be a jerk to everyone. So that’s my $0.02 there.

00:52:55
Speaker 2: I really like that. The thing that I liked the best, because I hadn’t heard it before was Naomi’s. Be really good at your job. This might sound ridiculous, but like, I have worked with many teams where no one has ever coded before but me, and none of them know what SDLC stands for. And they’re like, my last job was helpdesk, and I press the run button on this tool, and then I email the report and I do APS and like, no, you do administration. Like I could definitely hire. I think my nine year old could probably do that job. Um, she’s really smart though. She’s very smart, nine year old. But the point is like being able to speak their language, being able to understand their processes, being able to sit down with them and saying, I know this is a tough bug. Do you like, do you want Pear program on this and do it together? Like I remember saying before, like, can I drive? And the guy looked at me and I and he’s like, yeah. And I’m like, let me write that regex for you. And he’s just like, this is awesome. Like being able to to walk the walk that you’re asking them to do. I think that goes really far. And it seems so obvious when when you said it, Naomi, I was just like, oh, that’s. Yeah, that’s so obvious. Once you said it, but before it hadn’t occurred to me. So I really liked, I really liked. How all of you brought really different perspectives from like the product side, the practitioner side, and like the empathetic human side of like, we all need to get this done. How can we make this work? And like contorting yourself in ways to try to still get to the end that everyone needs to be at this. I really liked everything. Thank you. All of you. So am supposed to wrap up now. Saying goodbye is not my best skill, I think. Yes. So we’re supposed to say thank you. Does anyone else have anything else to add, or are we just going to wave goodbye?

00:54:50
Speaker 1: I want to add one thing, but shout out to Laurent Grace Dorham. Rostam.

00:54:57
Speaker 2: Hold on. I didn’t want to leave anyone out there. Uh.

00:55:02
Speaker 1: I think I got it. Yeah. So. Oh, also. Wait. Hayley. Yeah. Everyone who is leaving comments and talking in the chat like you’re all super awesome. So thanks for joining and participating.

00:55:12
Speaker 2: And you.

00:55:14
Speaker 1: Excellent. Thank you so much, everyone. Thank you for all of the companies that sponsored this event with us. Thank you, Amanda Ellucian, for organizing and making all of us look extremely organized and sound really good. And thank you, panelists for being here, because it’d be really boring if I just ask questions by myself. It’d be really awkward with that. Thank you so much to everyone. Thank you for the participants and we’ll see you next time.

00:55:39
Speaker 2: Thanks, LaTanya. Yeah.

00:55:41
Speaker 1: Thank you. Thank you.

00:55:42
Speaker 2: Everybody. Bye bye.

 

Get Started
Read Bright Security reviews on G2