The Future of DevSecOps

Hi, welcome to Predict 2020 The Future of DevSecOps. My name is Mitch Ashley and I'm CEO and managing analyst at Accelerated Strategies Group. Thanks for joining us today.

Of course security is a ever important topic and certainly becoming more important. We talked about application security, so we we're be talking about some predictions for 2020 and beyond. And also kind of tied them back to what we experienced during 2000 and 19.

So first, before we get onto the predictions part of this talk, let's first talk about a myth, one that I would like to so hopefully do away with, and mostly because it's one that I've also kind of fallen victim to. And I'll also help propagate in some cases with development teams and organizations. And that's the myth that security is everyone's job.

Now, in fact, it may be there's an element of security we all, of course, don't want to click on. And also, we shouldn't or write code that's not that's not secure. But the problem with pushing that kind of an idea is sometimes it becomes nobody's job when it's everybody's job.

We forget that we need some people who are taking the charge, taking responsibility, applying some leadership coaching and mentoring to the rest of the team about security. So now I like to not go down that path, that it's everybody's job, but instead have some champions, have someone responsible in the dev team for application security, for network security, cloud security. And we have those roles all the way up to the executive suite.

So let's help not promote that myth and really take security seriously at how we do applications, software and cloud native apps, cloud environments. So that's the myth. Now let's get on to predictions.

Great thing about predictions is you're almost guaranteed to be wrong. So we've kind of pushed the envelope a little bit here and there and see where we hit the market the end of the year. Prediction number one, developers choose the security software stack.

That isn't typically how organizations work. It's usually we think of let's let's sell to the CSO or sell to the security team or sell to the CIO and the managers within our organization. Software has changed.

And I go all the back, all the way back to open source software has really enabled developers to choose the software stack that they want to work at. Now, we work in an environment not just because it's open source, but it's so prevalent that software teams are being enabled to choose their own technology stack, not relying on management or the CTO, someone in a higher level position necessarily for laying out what specifically we're going to use. T.

team like a business unit or department. So there's development going on all across the organization. And I think we need to recognize that we already are in this world where development teams, developers are selecting their own technology.

Matter of fact, even in job recruiting, hiring things I've experienced is developers have a choice. They can go to organizations where they get dictated to about how they're going to develop and what tools they're going to use. But honestly, the really good folks, they look for organizations where they're going to have a say.

Matter of fact, they're making those choices and CEOs and managers are beginning to recognize that. And I think as security organizations, we also need to recognize that as well. And I think there's an important factor of why dev spec ops, dev ops teams will be selecting their own tools.

You want them to adopt tools, whether it's a code scanner or something that's running within a test environment or production environment. You want the developers to pick and use whatever they pick. So it's important for them to feel empowered to do that.

So it's an environment we're not experiencing just in the security world, but it's also happening up and down the software stack. So next, let's talk about our second prediction. Security vendors will start to shift to Dev REL.

Now, this is already happening with other parts of the software stack where organizations, vendor companies are recognizing developers. If they're choosing those technologies, they're probably having a pretty significant say at about how they choose it. If you talk to any developer, they're going to say they don't like to talk to salespeople.

They don't like marketing. They don't like being sold to. They want to try and try and use it.

Imp.. If they can use open source and stay with that, they most likely will. And that's begun this shift to open core time types of vendor companies where open source software is not just an element of how they build their product.

And then reduced or less functional feature capable of their downloadable open-source version of their product. Their. It is a real serious thing where most of the product, if not all of it, is really available as open source, as open core, and then hopefully they're going to build a relationship with those developers.

They're going to build trust with developers, trust by the developers that believe that this vendor believes in open source just like they do, and they can sniff out any vendor company that really doesn't buy into it. It's just a way of marketing software to them. And that's becoming a true business model.

The companies are beginning to prove this predictions about the same thing happening to security vendors, security software companies that are selling it to develop environment better companies are investing in development, relationship roles, community roles. There's lots of different titles for it, but that's all about working with the deaf community to help them get access to their product, support them, give them care, feeding all the support that they need, hopefully to use their open source product or the version of it and then maybe upscale BI to an enterprise version of that. If there's additional services that can be as much as rewarding the company recognizing that they believe in open source like the developers do.

So this move to Deverell means you're not relying just on download freemium types of approaches or salespeople calling on developers because it doesn't happen. It's not how most folks buy. So I think we'll see more security companies start to invest in creating those positions.

DEVERALL And again, those are people that need to know software development, need to know developers, how developers talk, think work, etc. There probably were one themselves, maybe still are and can sell. Really let the developer sell themselves and support them and going through that process.

It's happening in software industry. It's going to happen in security. So number three prediction.

Let's talk about the rise of the app savvy security engineer. We always think about the chasms between application groups and security groups, and sometimes those are tough chasms to cross or bridge or even bring together. Of course, I understand there's there's different interests.

Security staff have to deal with things not just about security, but also compliance and reporting across a wide swath of the technology stack, the infrastructure, the cloud. But I think well, things that will help bridge that gap is having engineers in the security environment who know or come from application development. And here's why I say that I think this is a reasonable prediction to think about.

We've already seen this happen where developers who have gone into software teams oftentimes are moving out of that role and to doing just regular software application development. They're moving into dev ops because they've got development experience. So it's not just admins moving sysadmins moving into a DevOps roles, but also software developers.

I've talked to several in the last couple months just doing podcast interviews and discussions with companies. I think we'll see the same shift for people who really have a passion about security. There have been developers, but now can step into the development into the security world.

Here's why I think that's important. The more the security team can understand the real intricacies of the architecture of software as we move into cloud native, we do containers, as we do micro services, service, mesh these kind of capabilities, they'll start to understand what's the attack surface issues around containers and what kind of products or tools are we using. And in fact, the development teams are using those things.

You'll have greater confidence if you have that knowledge. And experience doesn't mean all security people need to go back and be developers. But I think that's a skill set.

We want to add into the mix of security teams to help start to bridge that chasm prediction number for mainstream container server server lists. Security really enters the manged stream for us. We've had, of course, containers of being very popular Cuban entities, etc.

as the kind of buzz word of the then 2019 and beyond. And it will continue to be. Of course, security around containers is an important topic that many vendors are working to address and selling products into market, open source tools, etc.

We also have server lists, environment where that's becoming popular, more event driven kinds of application that can take advantage of server loss architectures. I feel like we're still scratching the surface on what some of those security concerns are. The best way to address those to the security teams understand that architecture enough to feel confident or feel good about the capabilities, tools and technologies they're using to make sure that those environments are secure.

I think that's going to continue to be a major focus for us into 2000, 2020 and beyond. Certainly a big focus of mine prediction number five. A key thing is our SICAD and security integration.

Now, it's not new that we know we will need to integrate security into the CCD process. The good thing about that is if you're a security organization, you're. Your company is embracing DevOps.

Maybe you're starting to put your CSICOP pipeline in place. It's typically the first place that you get the biggest benefit from dev ops. He says many, many organizations start.

It's a great opportunity for security, get involved and assist the development teams with the kinds of capabilities that make me want to use to do things like code scanning, do testing, security testing at the integration and deployment process into testing as well as into production. D. environment to help identify vulnerabilities and take care of some of those things while they're doing code development.

So something like a sonar cube. No mentioning a few products and there are many others. So I'm not here to endorse a specific product, but there are capabilities there that I think developers will be very interested and they'll sort out which ones they think are the easiest to use and feel like our effective member of the security teams understand those and can support the development teams the better.

Those CIC is not just a development team thing. It's also something for security teams to work closely with the development teams in implementing. So I hope you detected a theme in the predictions that I've made as part of this discussion.

Our talk on Predict 2020, certainly the way we select software and who is involved in that is rapidly changing. It's going to affect the security market and the better that security vendors can respond to that proactively and serve the developers, all the better. And the same thing goes for the security teams within organizations.

Now, I'm not saying that security teams should do the developers jobs and vise versa. But I've always been a believer that you provide people the two tools that they find easy to use. They're going to adopt them.

And the more you can provide guidance to support development teams, they're gonna appreciate that as opposed to being the police or cops. Also, your engagement with DevOps practice. Dojos.

I even think we'll get to a point where we'll see something like a security dojo that will help teams go through how to write better, more secure code so that we don't see the trends that we've seen over the last 15, 20 years. We can start to see reductions on SQL injection and cross site scripting, which today are nearly as prevalent as they were 10 or more years ago. We still see a lot of those same kinds of vulnerabilities.

So present bridging that chasm that we've talked about can really be effectively done by putting yourself in the shoes of the other team, supporting them, providing them support, letting them know that you're there for that. And also, of course, if you're a developer, not thinking as security teams, as the enemy or the bad guy, but also you want to write secure code. And that's probably another myth that we could talk about, is that developers actually do want to write secure code.

Now, a developer would hear me say that. Of course we do. It's kind of insulting.

You would say that. But I've heard security teams say individuals, security engineers say developers don't care about security. They actually do.

They care a lot about it, which is why I think we'll see the rise of security kind of dojo. Sometimes developers may need some support, some help, some training, some understanding about ways to improve the security in the code that they write. Other times they do perfectly well and they may be supported by tools that do code scanning and testing within the CIC process.

But I think that belief is there. No one wants to write code that gets compromised. No developer wants to be known as someone who doesn't write secure code.

That's certainly not an intention. So that's the myth that I would like to wrap up on. It's let's also dispel that myth that developers don't want to write secure code.

They absolutely do. They may need some support. They need we need some empowerment to choose the tools that they want to choose, which has led me to the kind of predictions that we've talked about today.

So thank you for joining us on this Predict 2020 session on the future of death sic ops. And I hope these things come true or some variation of it that help us move down the path towards more fully integrated security into the DevOps application development process. Thanks for joining me.