On this episode, James talks about identifying responsibilities and updating job descriptions to include security. Tackling the challenge to integrate security into the development process? Looking for insights, answers, and practical solutions to avoid getting overwhelmed? Welcome to the DevelopSec podcast, where our focus is your success in securing and improving development processes. And here is your host, James Jardine. Hey, everyone. Welcome to this episode of the DevelopSec podcast where I wanna talk about an approach to help drive the adoption of secure development. This isn't new. As a matter of fact, I started doing this when I was a dev manager back in 02/2011 on a very limited basis. So what's our current approach? Currently, we've designed that a nondevelopment group is responsible for securing our Application. Whether that's the DevSecOps group, the application security group, or some other nondevelopment group, we've yet to really put a foot down to say that the responsibility of secure applications is on the very teams that create those applications. So we currently have a group tasked with building applications and another group, often with limited access, that can't actually make any updates to the code or anything like that, tasked with making Secure that the applications are actually secure. Guess what we've learned over the last few decades? It doesn't work. We can get some gains, but it is a painful process that is full of holes. So where can we go from here? What are our next steps? Well, I think there's two things that we can really look at to have a bit of a dramatic effect, but it's not gonna be easy at first, and it's gonna take a little bit of time to start merging it through. But I would also like to say, I think that we're already starting to get there a little bit. So what are the two things? First, we need to stop dancing around the topic of the development teams being responsible for building secure applications. I get it. The security industry has been built on the concept that you don't have to do anything. We'll secure your applications for you. As I stated earlier, this just doesn't work. Unfortunately, at every level, everyone is too afraid to stand up and say, this is your responsibility to the product teams. We have to say that part of the cost of creating an application is making sure that it has reasonable security from the ground up. You may hear things like shift left, start left, shift right, shift smart. All of it really is about trying to make sure that we have security built in to the application, and we're not bolting it on later on because that's where we find that it never works. So let's consider some of the costs associated with many of the applications that we build today. First, we have security tooling. There's lots of tools available out there to help perform some automated testing of applications, whether that's static analysis, dynamic analysis, interactive analysis. Right? All these things, your SaaS, your DaaS, your IaaS, just a few that all have some sort of different level of cost to them, not just from the actual cost of the software, but just importantly, the cost to implement and maintain those tools. I can't just have a tool sitting out there and it works. Right? You have to kinda maintain it this whole time, and there's a cost to that. So making sure that we have that. So we wanna consider that cost. We also have professional testing requirements, so penetration testing, ethical hacking, maybe bug bounties. Many applications require some form of third party penetration testing on an annual basis. If not an annual, at least, you know, semi regularly basis that's going to occur. Not only can a penetration test be expensive, it also requires time allocations for both performing the test and addressing any findings found during the test. So, sure, maybe a test is only a week or two weeks long, but we still have to make sure that with the busy schedules that development teams have, that they actually have a scheduled out time period that if there's results from this pen test, which rarely are there no results back, that they have the capability to be able to address those, in a timely fashion. Next, we have third party components. Almost all of our software today is composed of many different third party components, and these aren't all commercial components. Think about PyPI, NuGet, and some of these other providers where we get a lot of the functionality for our applications. And while, typically, many of these are open source components, they have no cost to them, there are indirect costs around keeping those components updated. You have to have some sort of plan in place to be able to apply updates even after the main development of the software is complete. We talk about after the development is complete. But even before that, while you're still doing development and, you know, you're actively working on that application, you're going through and doing updates maybe every two weeks, three weeks. Maybe you're doing daily updates. But how often are these components getting updated? And, usually, there's a lot of components within an application, especially a large Application, that we need to make sure that we're keeping those up to date. Because one of the biggest downsides with the third party components and even the framework itself is that if you don't keep it up to date, the more times you miss that window, the harder it is to keep it up to date. If I start getting out to jQuery 10 and I'm still on jQuery one, it's a lot harder to go from one to 10 than it is from one to two. So making sure that we keep that. But that's a cost that we have to consider. And then once you're kind of done with the main development of an application and it maybe goes into maintenance mode, you still have to have that time to go in and still update Secure those components are still gonna get actively developed and updated as they go forward. And some of those updates are security updates, so they have to be included. Speaking on that same line of third party components, also the ongoing maintenance of just the software in general due to the changing technologies, platform updates, new vulnerability categories coming out. If anybody has been watching, recently, they had double click jacking pop up that had never really been talked about before, something that we'll talk about on another show. But it's a new kind of I don't wanna say class of vulnerability, but it's a new vulnerability out there that nobody or most nobody has any actual mitigations for at this point. The stuff for click jacking doesn't work for it. So it's something completely new that even if your app has been up and running and fine, now it may be vulnerable to this. So we have to be able to stay on top of those things, and there's a cost, of course, to going back and ensuring that we're staying up to date on those. But if you're building your applications on dot net or some other framework, those frameworks or updating their end of lifing, All that stuff has to be considered when you're looking at the applications and its security to make sure that we are getting that all handled that, you know, we're not still sitting out there on dot net two point o twenty years after it's already been end of life, and, you know, trying to get to the next version is gonna be much more difficult. The final thing I wanted to cover on costs, and these it's just a small list, so it's not everything, but training. So there's always new types of risks that may pop up. The double click jacking is a good example. And, also, there's a lot of stuff just in the security realm to understand. So it's important that developers and product teams understand these different vectors to mitigate them. And there's a cost to being able to, one, obtain that new knowledge, and then, two, to share it with the team and make sure that it's understood across the members that need to know it. So I think there's a few different things that we need to consider when we talk about the cost of applications, that as we look at this, how does that fit? So as we think about these different items, we can start to consider how each team can be beneficial. Our goal should be to reduce friction where possible. In many cases, the security team acts as the guide in the verification center. Security can help to find out what types of testing is required and help identify the vendors or tools that are supported within the Application, we may find that development teams are actually more efficient at identifying how to properly implement those tools within their teams. We've seen this before where if you can supply the tooling and say, hey. You need to use this SaaS for whatever reason. Maybe it's some sort of compliance reason. Here's what needs to be done, but you identify how it fits best in your workflow, in your pipelines. Oftentimes, the development teams will come up with a much more efficient way for that to be implemented to fit how they work versus when the security team is doing that outside of the development team and saying, oh, well, we'll just put it together like this because this is how everybody does it. And then it doesn't actually fit the workflow of the development team. So if you can get the development team to help set that up and, usually, that's kind of a one time setup. Hey. How do we get this working in our SDLC? It's gonna help reduce that friction. Security teams can help stay on top of the latest trends and risks out there to help identify appropriate training opportunities for the development teams, but it should be the responsibility of the development teams to enforce the completion of that training. And finally, as the development teams are given the capabilities to execute the needed security requirements, the security team is there to help verify that the required tasks are being properly completed and provide guidance when needed. So it's a little bit of a shift of what we typically think of application security or product security where the devs sit on one side. They just work on the coding, throw something over the fence. Security looks at it from a security only perspective, gives that information back because security can't go in and fix those or and my opinion usually shouldn't be going in and fixing that Secure if I keep fixing it for you, you're just gonna keep doing it incorrectly. But we get that back and forth, and that doesn't really work that well. But if you can let the teams do what they're best at, the development James doing the Development, and the security team's going out there and finding what are the biggest risks and identifying that information. That's gonna be a much better use, and then they provide that back to Development James. And then Development teams understand, hey. This is how we can now implement this information that's being provided for us. And that gets us away from that need for the development team to spend a whole bunch of time trying to research new risks, new vulnerabilities, even sometimes mitigations because the security team can dig into that and be able to provide back. Here's the risk. Here's some ways that the way we develop our applications, we could look at resolving this risk. Now let's work through of how we can go ahead and do that. But we can't stop there. Just identifying the responsible party would do no more good than what we have now as we are starting to see the shift slowly starting to happen. So what's the second thing we need to do? I think the second thing, and this is important, is we need the development community to realize that Security development concepts are required for jobs just like the experience with Agile, object oriented programming, test driven development, and understanding their current frameworks. I quickly browsed a few software engineering jobs on LinkedIn the other day. Not one of them had a mention of security in them. Even when they mentioned building quality software, none mentioned building secure software. And we can argue that, you know, secure software is quality software or vice versa. Right? Security is part of quality when we look at that. But we have to get to the point where we are requiring our new developers that we're onboarding to have some secure development experience and understanding. We've fallen into this trap where it is the security team's job to provide training to our developers on secure development. This at a is at a company level, wherein not all companies do it, so it's not across the board. This training is seen as a burden, both from the security side of creating it and the dev side of taking it. It is seen as something that security wants you to do because of some compliance requirement rather than something that should already be done as part of the general development role. This isn't a ploy to get rid of the security team. Instead, it is a direction that is needed to be taken to scale our capabilities. The security team can't secure your applications. It's just not possible. The security team can help reduce some of the risk by adding in some controls, but it will never be as effective as the development organization building with security in mind. If we actually want to see the security no move within application development, we need the people building applications to step up and take on the challenge. Otherwise, we'll just keep doing what we're doing, which clearly is missing the mark. I remember back in 02/2011 when I would interview new candidates for a software engineer position. I would ask them about how to protect against cross site scripting or SQL injection. Honestly, I didn't come across any candidate that even knew what those were. To be fair, I was asking the questions, but I was not basing my decision off of the responses because I didn't expect many to have the answers. This was well before AppSec really took off with mainstream outside of being more of, like, a testing side of the house, maybe building the policies. It's definitely really grown a lot since then. But I would expect that ten years later that a developer would know the answers to simple security questions. However, I would not ask them in the same way this time around, which I will cover my thoughts on that in a different episode. The point being that at this point, there should be an expectation that DevelopSec understands some security concepts as part of their role. Your job description should start to reflect the desire for security related knowledge. For example, some understanding of how to handle keeping third party components up to date. The expectations would change based on the level of the DevelopSec, requiring more understanding the higher you go. I plan to talk more about this in an entire other episode. I've met quite a few developers that have a pretty sound Security understanding. I think we're seeing more every day. I believe that if we start to formalize the requirements and vocalize it more, it will become normalized much quicker. It is hard to hold someone accountable for something that you haven't clearly defined your expectations for. Unfortunately, I think we do this too much with application development and security. There are plenty of fingers pointing the other way and too much hesitation to look for simple solutions. Hopefully, this has provide a little bit of idea provocation to start thinking about ways that we can update and make simple changes, honestly, to our systems and our organizations by modifying our job descriptions a little bit to get people a little bit in line with what our expectations are for the different roles. I think simple changes to your job descriptions make a big difference. And a lot of James, there's this concern that, oh, well, if I put this in my job description now, all my current employees won't match this. But most places already have some sort of corporate security training happening. Pick stuff, one, that is relevant to your organization and to your application development. Don't overdo it. Ease it into those job descriptions. And then if you're picking something that's super relevant but you're not actually confident your developers have, then you've now just picked your next team training topic and go forth and work with that to make sure that you're getting them to that level that you want them to be at. This shouldn't be a situation where, oh, I'm a senior developer, but now that you've updated my job description, I'm gonna drop down. I'm I'm I don't need that anymore. We've just added security into this. If there's something we need to do to get somebody to that point, then let's provide that training. But don't try to boil the ocean. Put in one or two things to start the idea of updating these job descriptions. So I wanna thank everybody for listening, and stay tuned for the next episode. You have been listening to the DevelopSec podcast with James Jardine. To find out more about how we can help you with application security, follow us on Twitter at DevelopSec, or check out our website at www.developsec.com.