Amy Demartine – State Of DevSecOps – Empower Developers To Find And Fix Security Flaws

Allow me to introduce our first speaker, Amy Demartine, vice president and research director with Forester, speaking on the state of DevSecOps, empowering developers to find and fix security flaws. And we will cover the dynamics of fitting the square peg of security into the round hole of DevOps and what's needed to be successful. Be sure to engage with Amy in the chat during and after her presentation, and if you'd like to see how you compare to mature best practices, check out the resource link for our security maturity assessment along with other recommended resources.

Hi, everybody, and welcome to the state of DevSecOps Empower developers to find and fix security flaws. We're going to talk today about how you can really energize your development team to really understand, find and fix security flaws. But first, let's take a step back and talk about what are developers really caring about, what do they need from us in security?

Well, the first thing you have to understand is how they're measured. And developers are measured quite differently than a security team. The top two things that developers get measured on are quality and direct measurement of customer feedback.

So when you think about what they're looking at and how they're measured and what their success looks like, security plays into both of those. So, for example, with quality, security is just another issue in quality and with customer feedback. If data is lost because an application is breached, customers will definitely not have good feedback.

So security actually plays in both of the things that developers care most about. Let's also take a look at what developers want, what they're going to be doing in the next 12 months, and it starts with increasing automation of the software delivery lifecycle. Why do they want to do this?

Well, it makes it smoother and it makes them faster, which is the second thing that they want to be doing. And so with the software delivery lifecycle, it's very expected things run automatically and they can check in their code and have it built and produced into production very quickly. And that's the second thing which is speeding up their release cycle.

They're trying to release faster. They're trying to get their genius out to customers faster than they ever have before. And then the last thing is, is they want to use open source components.

And the reason they want to use open source components is because that is not what's going to be differentiating for your application. It's common code. It's stuff that building blocks.

Think of them as Legos to your application. They're not the secret sauce on tap that differentiates you. It's just building up to that functionality, to that secret sauce.

Developers are moving faster and they really do want to get that genius out to customers faster, and what we found in twenty eighteen is that twenty seven percent of developers indicated that they were releasing monthly or faster and that took a huge jump in twenty nineteen where it moved to thirty eight percent. So it's a huge jump and moving faster now. Has everybody started to work from home.

I have a suspicion that when we start to see numbers coming from twenty twenty, we're going to see another nice jump, meaning that developers are able to move as fast as they can. They're not traveling, they're not going to conferences. They are focused on building their apps and moving them faster.

So I wouldn't be surprised if we see another jump. But what we're seeing is developers are moving faster. They need us to move fast with them in security.

This is a quote from Douglas Adams, one of my favorite authors of Hitchhiker's Guide to the Galaxy fame. And what he said here is we're stuck with technology when what we really want is just stuff that works. Now, this is true from two perspectives.

This is true from the developer perspective. They just want security tools that will work. And also it pertains to our customers.

They also want applications that we can deliver to them to work. And so when we go back to what developers are trying to achieve, fast, good quality code, good customer feedback about what they're delivering goes back to, they just want something that works. And security is a key part of that.

Unfortunately, sometimes we miss the boat on these. We have these huge surveys and we give them out to, in one case, security pros and then we in this survey we ask, have you suffered a breach? And thirty three percent of firms said, yes, they do suffer a breach.

And then we ask that next click down. OK, so you've suffered a breach. How did you suffer it?

The number one method was software vulnerabilities at 40 percent. The next is Web application flaws, things like sequel injection or cross site scripting at thirty eight percent. Now, these two flip and flop between year and year.

In fact, last year they were they were swapped where Web application was number one and vulnerabilities was number two. But what I find most interesting is the difference between the two that affect applications and everything else. Applications are actually getting worse and everything else is getting slightly better.

And so what we're seeing here is a nasty trend where applications are actually where malicious attackers are the method of getting into our applications and our sacred data and unfortunately, everything else isn't. So this is where we really need to tighten up. We really need to make sure that our applications are secure.

So let's go back to what developers were doing, so a lot of them want to use more open source, not less. Now, why is that? Well, going back to the building blocks, they are just fundamental pieces that developers can use to quickly apply to applications and then add their secret sauce.

Unfortunately, while they're doing that, they could be including a lot of vulnerabilities that they are aware of. And what we saw between twenty eighteen and twenty nineteen was a 50 percent jump in vulnerabilities and open source. Now, I don't know that I would say that we're writing worse open source than we were before, but we're writing a lot more of it at a faster clip.

So we may not be doing the right kind of checks that we are that we should be doing to release these open source components. And the developers are going to need help with this. They're going to need to understand when not to include a common component, what common component to use, what's safe.

So we did a survey last year, we looked at the top 40 computer science programs in the United States and we actually rifled through all of their different courses and the syllabus of those courses. And what we found was disturbing. None of them taught secure coding practices, none.

And some of them offered optional security courses, but most of them focused on network security, not application security. So our developers, even the ones coming out of university today, do not know how to write secure code. They don't understand that open source may have vulnerabilities.

They don't know how to remediate weaknesses like sequel injection or cross site scripting. And so a security process. We really need to empathize with developers as they are trying to create good quality code that has great customer feedback.

They don't know how to secure it. And that's where we come in. Now, Forrester, we recommend that three different types of tests be run on every piece of code.

The first one is static analysis. That is, code at rest goes through most thorough kind of inspection you can do on code. The next is some kind of dynamic analysis running code.

This is going to find flaws that SAS can't find like dynamically generated code, for example, code that it only exists when you're running. And then the last thing that we recommend is software composition analysis, which is really that code that that tool really looks at the open source components to highlight where you've got vulnerabilities in your code. So with that in mind, where are we?

Where are we with including these tools as part of the SDLC in an automated fashion? Well, I'm going to start off with some bad news. The first one is sassed.

And what we are seeing here that I would love to see is a bump in development. So let me explain a little bit about what you're looking at here. So the dark green lines is what people are planning to do in the next 12 months.

And what is in the light green is what is currently implemented. And the numbers are OK in terms of implementation of these tools. But what we really want to see is that dark green line and development to be a big bump that would show that security pros are implementing it earlier and earlier in the software delivery lifecycle.

Now we are seeing a decrease in fraud. So that's great. But what would be even better is that sharp uptick in development and SAS can be pushed really early in the software delivery lifecycle.

In fact, when we talk to most clients who have already implemented it, they implement either in the idea themselves or right after checking. So that's right at that development phase. I asked and tasked.

So these are the dynamic application, security testing and I asked you might also be known as directed dast, where you are taking tests that you've maybe made for business logic like selenium. And what you're doing is you are directing the dynamic application, security testing to look at those business logic tests. And I asked can actually be put pretty early in the software delivery lifecycle, so there's good news here.

Let me explain a little bit about what you're looking at here. So I asked, is the purple Dast is the blue? I asked is on the top fastest on the bottom.

And what you see is the planning is in the top two bars and the implemented is in the bottom two. And what we're seeing is the planning is great. Development is actually getting a little bit of a bump, especially for I asked, which is fantastic.

Exactly the tool that can be run early in the software delivery lifecycle. In fact, it can be run right at Chaykin. And so you can then spawn a test environment and have Astron even on unit tests.

So that's fantastic. So that is good news. Wish that it was a better news, but I asked is certainly a good story.

The last tool is software composition analysis. This one also has some pretty good news in this case. Not only are we seeing a drop in production, but we're seeing a nice bump in development.

And that's great because as developers are including those common components, we're telling them right away, hey, you've got something that's got a vulnerability in it and you've got to replace it. So while they're already thinking about what components are using, they can go find a different component, one that is going to suit exactly the purpose that they need it for. So is actually good news.

Once again, wish it was a better news, but at least offer composition analysis. And I asked is pulling through for us. So why are we doing this in the first place anyway?

Why are we going through the trouble of including ourselves in the software delivery lifecycle? Well, there's a few benefits that I want to cover. The first thing is fewer security flaws.

The next one is the dev team actually gets to scale and their security knowledge. And the last thing is real time education. And let's talk about education first.

So we talked about the fact that developers do not know how to write secure code, and as unfortunate as that is, I don't see the university system, at least in the United States, changing quickly enough to produce a whole ton of developers that will understand how to write secure code. That means we need to do it ourselves. And the best way to do this is to stop them.

Once we know that they've got a security flaw and say, hey, you've got sequel injection or you've got cross site scripting, and hopefully the security tool is able to give them remediation advice in the form of sample code, for example, videos, training. How do I learn right in this moment? I get asked in in the past about, hey Amy, what about training all of our developers?

Couldn't we just train them all and have them all be happy? Unfortunately not. What we find is that those classes are developers learn one or two things from those classes, but not enough to take with them back to their desks and really change fundamentally change the way they write their code.

So unfortunately, what works best is to actually stop them in their development and say, hey, this is how you fix your code. And what we've seen is that also the more you scan, the faster time, faster fix time. And you might think, well, that sounds totally obvious, but we actually have the proof.

And what we found is that security flaws actually persist three point five times longer in organizations that scan less than three times a year to those that scan seven or 12. And if you are ones that really scan every day, then those that scan fewer times than three actually versus eleven point five times more. So what we see is the more you scan, the better off you are.

So not only are you educating your developers, but you're actually going to decrease your fixed time. So I mentioned scaling the developer team and one thing that we have found is that security has a totally different language. When we start talking vulnerabilities and weaknesses and sequel injection and cross site scripting developers, their eyes may just roll right back into their heads because they have no idea what we're talking about.

We have a specialized language. So what we have found is this very interesting trend of assigning security champions. They are people that bridge the gap between security and development, and they really understand the language so they can translate the fact that security flaws, equal quality issues, and they're able to make it real for developers that oftentimes security pros aren't able to make it real for them unless they're part of the team.

So they're automatically trusted. They also can scale the security team, meaning that when you think about how many developers there are two application security folks, we find that in general there's one hundred and one from developers to just security pros. And those aren't just application security pros.

Those are all security pros. So really, there's a fraction of application security pros to developers, and that means that they can easily be overwhelmed. It may be hard to get advice on how to remediate something.

If there's an issue with the tool, it can be very difficult to get an answer. And so what we what we found is if there's a security champion assigned to a group, they can answer the questions. They can be that front line person who's answering questions for the developers and even speed the developers more than they were before.

There's really five steps that I want to highlight here for creating our security champions program. Now, the first thing is you want to make the case, you want to get support and you want to get funding. And even in these times of budget cuts, it's important to make sure you highlight the fact that what you're trying to do is make your developers faster and have less flaws.

So the first thing is you want to get your funding and this needs to come from development and from the security side of the House. The next thing is you want to pick the right security leaders to interface with the security champions. You need somebody who's going to be empathetic to the plight of developers.

Developers do not have the easiest job in the world. In fact, their job is incredibly difficult as they are trying to meet both the business as well as customer pressures. And so you need security pros who are going to understand both.

The next thing is to train the security champions. And who you're going to look for is you going to look for people who ask a lot of questions about security, who are naturally good at finding flaws, fixing them, who naturally help others in the team fix flaws. That's what you're really looking for.

And once you find those folks, train them up on what the common issues are, how to fix them, anything that go beyond what they've already learned thus far, then you're going to support and reward them. And this is important, even if it's just a competition between security champions on how fast they can fix their flaws, how long they can keep, for example, know how long they can keep no serious or critical defects. Those things can go a long way to keep the developers interested and active as champions.

And then the last thing is to measure, monitor, improve. So, for example, maybe you see a huge uptick in sequel injection, probably time to do some education, especially if it's in a particular team. And if it's across the board, then educate all the security champions.

And that's how you create a great security champion's team. There's one thing that I want to talk about, I've talked about the SEC part of Deb SEC ops, what I didn't talk about was the optics part of deficit drops and it's something that people often leave off. And that is don't forget your feedback loops.

You actually have invaluable information that you're producing from your application production tools. Last year, there was a huge amount of interest in threat intelligence and in fact, companies didn't seem to have money enough to throw at threat intelligence teams. They definitely wanted more and more threat intelligence.

But what they were missing was they actually have customized threat intelligence at their fingertips. So if your company is already implemented, something like Web application firewalls, but management, container security tools, all of them have logs that show exactly where in your application attackers are trying to get in. And so you actually have information about where you should beef up your security.

So as your developers are looking at what to fix, the security flaws, the weaknesses, the vulnerabilities, you can actually tell them where in the code they should prioritize. And this is very important. That feedback loop back is all part of maps and makes dev ops complete.

So my key takeaways are these first look for any and all opportunities to automate throughout the software delivery lifecycle, make sure you are pushing those tools fast. Dast, I asked in software composition analysis as early as possible in a software delivery lifecycle, even if you're migrating through the end, destination is the earliest, the earliest spot you can get it. The next thing is to push development and automation and use your security champions.

That's really how you're going to scale not just the automation, but through your security champions, those people who are embedded inside the developer teams. And the last thing is, don't forget your feedback loops. Don't forget the apps part of dev stickups.

Make sure you're able to give that information to your developers so that they know where they should be fixing how they can prioritize their fixes. Thank you.