The Joining of DevSecOps and Cloud Native is the New Software Delivery Path at Cloud Native Now 2024

Hi everyone. com, cloud Native now, uh, security Boulevard Techstrong, AI Tech, strong, ITSM, digital CXO, and of course, tech Strong tv. Um, we're so happy you join it.

You're joining us here on, uh, cloud Native Now virtual event. There's about the fifth year in a row that we're doing our cloud Native now virtual event here in the summer in between Q Con Europe, which is usually in the spring, and Q con, Norther Q Con CubeCon, north America, which is usually in the fall. Uh, and as you've probably seen today, we've had quite the lineup of some really great speakers talking about the current state of, of cloud native.

You really can't talk about cloud native today without also talking about security and where we're going to get into that. Um, but we hope you've enjoyed our day. And of course, all of these sessions, in addition to when they're streamed, are available on demand.

So do check them out. I'm really happy to be doing another fireside chat here for, for this particular session though, I want to introduce you to Melissa McKay. Melissa is head of developer relations at J Rog, and Melissa's been on a few of the different text drug TV shows that we've done over the years.

I know for sure the DevOps Unbound, uh, event, uh, show that we do with the folks at Chiantis and then what have you. But Melissa, first of all, welcome. Thank you for coming on, and it's great to see you.

Thank you, Alan. It's good to be here, and thanks for inviting me and for having this chat. Mm-Hmm.

We always love chatting with you for sure. Okay, so, well, Ester, I don't think Jfr needs a any introduction to our audience here, cloud native. Now, uh, some people out there say, but wait, they're a DevOps company.

And, and that kind of gets to one of the points I wanna make here today. Well, yeah. Jfr is a DevOps company.

They're also a security company and a DevSecOps company. And really, when we get down to it, can you have cloud native without DevOps and without security? And I think that's a question that has an easy answer in my mind, but who am I?

I mean, what do you think? How can you have cloud native without DevOps or without DevSecOps, Melissa? Oh, you certainly can, but be prepared to have a lot of issues.

Yes. You try. It just won't be very good.

Right, right. Yeah, Exactly. You know, I was, I was talking with some folks earlier, earlier, actually, one of the fellows was from the, uh, dev Re for CNCF, George Castro.

I don't know if you know George, great guy. You know, and he has this really interesting, um, kind of theory on cloud native and how all of these things fit into it, security, DevSecOps, DevOps. And to him, it's kind of like a, like a biosphere where you start with single cell organisms and evolution comes in and eventually we get the dinosaurs, right?

And then, you know, the dinosaurs get wiped out and you get MAs. And here we are as people. It's been kind of like that.

There has been an evolution, if you will. Right? com 10 years ago, almost 11 years ago, 10 and a half years ago.

And at the time, there wasn't really a cloud native per se. You didn't hear much about it, but there were certainly people who were kind of at odds about how security and DevOps fit together, believe it or not. Now, today, look your head of Dev re at, at jfr, do you still run into people who say, well, DevOps is not security, or the security has no place in DevOps, or DevSecOps is just a marketing term where, where do you think, you know, maybe I'm in the bubble.

There are a lot of terms flying around out there, and, and honestly, it does get a little bit exhausting. You hear, you know, DevOps, DevSecOps, um, ML ops, um, uh, JFR is currently working with every ops because we're, we're of the understanding that it is all a process. It all requires, um, strategy and some best practices to put all these components together so that you can get a good product at the end, right?

Mm-Hmm. And then also get feedback to improve that product as you go. So then, then we start talking about, you know, runtime stuff.

So, um, as far as security is concerned, um, you know, I, I've been a developer for years, um, and it, it was just, you know, my desire to prove, um, the circumstances that developers have that brought me to, to get into developer relations. But part of my experience as a developer was joining a DevOps team. Mm-Hmm.

And it came, it was pretty quick for me to understand. That doesn't mean that everyone on the team knows all the things, right? It everyone has their own expertise.

That's Why it's a team. Team. Exactly.

And security definitely has their own expertise. There's a talk that I've given a few times now at several different conferences in, in different areas, and it's called Don't expect Developers to be security experts. Um, there is a lot that we can do to improve security posture, definitely some responsibilities that land on our plate, but a developer themselves, they're not gonna know all the things.

Uh, they're not gonna know the same things about security as your operations folks, you know, that need to worry about network security and, and the security in the, in the runtime environment. Your, your developers that are building the initial applications may not be exposed to those as much. So as far as security being involved in DevOps, it absolutely must be at every stage, right?

Yeah. At the beginning, the develop, It's not the developer's job. That's the issue.

You know, my friend George, back to his evolutionary thing, right? He, we, we spoke about this. I think when we first started seeing security, you know, coming into DevOps, there was this whole shift left.

What a great idea. We're gonna take security, we're gonna shift it left. You know what, that works good.

Let's shift it further left. Wow. Let's keep moving.

It left until finally we put it squarely on the developer's shoulders and said, okay, developer, you're responsible for security now. Well, no. Of good.

You're surprised that that didn't work, right? Right. Right.

Um, So again, that evolution happened, but then evolution continued because someone said, or enough people said, wait, this doesn't make sense. We can't expect our developers to be security pros. Maybe they could be security champions.

They could be security conscious. Right? They can make sure that built into the process, it may not be on them, but within that process, there's security checks and, and, you know, best practices and so forth.

Yeah. The whole platform engineering thing, right? We, we build a platform that has security protocol built in so that the developers can do their thing in it.

Um, yeah. I'm gonna play, I'm gonna play on, uh, go ahead. Uh, I'm gonna play on J Frog's.

Little metaphor about liquid software. A minute. We get asked about that a lot.

I'm gonna change it up a little bit. So think about, go think about a river. Think about the source of your river.

It's pure, it's fresh. That's the whole idea of shifting security left. You start with something that's pure to begin with, right?

But is that as that water runs downstream and makes its way, you know, down the mountain, through the rivers, all the way to the ocean for delivery to production Mm-hmm. To speak. Anything could happen along the line, right?

You could have, you could have a service that could be dumping stuff in the river that is not safe, that isn't clean. Um, you've gotta have monitors all along that river, all the way to the end to make sure that by the time it's delivered, it is still pure, it is still fresh. And then even then, uh, you have to repeat that and, and, um, monitor that as you go, as it's running.

You know, your software is running in production. It doesn't just magically stay fresh and pure. You know, like, like food that's been delivered to a table.

It foils after a period of time. You have to keep an eye on it, keep watch on it. So, yeah, I, I agree with you.

And, you know, to quote a Greek philosopher, you can't dip your toe in the same water twice, right? And, and 'cause things change as that water goes from high up in the mountains, you know, down, down into the ocean. Let's talk a little bit about cloud native though, because this is cloud native.

Now, we said that, you know, without DevOps and security Cloud native wouldn't be all that good, right? You, you could do it, but it would be a lot harder and security would be an issue and everything else. But let's turn that on its head.

Now. How has Cloud Native Melissa affected our ability for, you know, to do that water, to have that water remain pure as it comes out to the ocean, right? Because cloud native is, especially in Greenfield, like new applications is kind of the dominant, um, platform back that we're, we're deploying it.

So how is cloud native influencing DevOps and DevSecOps and jfr for that matter? Yeah, it, it is, it presents a lot of different issues, a lot of different problems. Um, think about, well, cloud native was in response to a specific problem, right?

Um, we needed the abilities to scale our applications. We needed abilities to, um, deploy applications and have them be reliable across different regions all over the world. Um, this was the results of our organizations that were, um, servicing these applications, getting bigger and, mm-hmm, more clients, more customers, but also it, it, uh, allowed for smaller organizations to also take advantage of this cloud native, you know, infrastructure as, especially when we start talking about serverless, you know, and you start controlling your costs a little bit better that way, if you don't have to, uh, maintain your own server farm, right?

And you can, you can rely on other companies to do this. The issue is, um, all of these capabilities comes with a little bit of a risk. And that is all of the disparate tools that are being brought in, all of them are, are built for reasons, good reasons.

You know, different groups have different use case scenarios. They build a product that solves a specific purpose. We put all of these together.

And what we need to be careful of is to make sure that we know the providence of all of these things that are coming together. We need to understand how they're being built. We need to make sure that the product that we're receiving is, is legitimate.

It actually, you know, is coming from, um, the legitimate owner of the product and, and hasn't been, um, subverted in some way by a malicious actor. Um, we need to be confident that these things are built, uh, in such a way that the developers have paid attention to all of the packages and libraries that they've brought in, making sure that they're up to date, that they don't have vulnerabilities. Um, all of these things are coming to play.

So, you know, the bigger it gets, the harder it can be to manage. So now we're seeing these organizations come in with platforms to help solve some of that pain. Um, to be able to take inventory of all of the components that are involved in the development and deployment of your application to scan all of those binaries, for example.

That's what Jfr is good at, right? Mm-Hmm. And be able to notify your developers and also your security team, your ops personnel.

If there is a problem that has been discovered, um, it, it's something that we do need to pay attention to. It cannot be skipped. And we've seen this time and time again, uh, in the media, every time something happens, we're all informed of it.

And, um, we get a little more terrified every day of coding anything, to be honest. Well, you know, let, let's rip something out of the headlines, right? This past weekend, kinda all hell broke, right?

Especially if you were traveling and I was traveling, um, with this CrowdStrike update, alright? CrowdStrike was a security company, but that was really kind of immaterial to what really happened here. What happened here is they pushed an update that maybe wasn't tested as well as it should have been, that it didn't go through that right.

Software supply chain kind of thing. And it, it bricked, I know that's an old term, but, you know, but it bricked, it bricked windows on a lot of, a lot of systems, a lot of important systems. Was it, was it, is this a, was it a DevSecOps failure here?

Was it a software supply chain failure? Was it just purely testing? I mean, I, I'm not looking to blame anyone.

Yeah, we can, uh, we can guess all day long what actually happened, what really happened. But I think the most important lesson to learn from this is that the more exposure the world has to our products and services, we've gotta have a plan for when things go bad. Because every now and again, will, and I think instead, you know, we focus a lot on, uh, deterrence and prevention and things like that.

But I think we need to start focusing a little more on when it happens, what are the consequences? Yeah. What can we do with that response?

How can we recover quickly? And yeah, this is me back to this age old debate, especially when it comes to updates. Um, I'll get in arguments all day long with other developers about this, but whether or not you should always have our rollback plan or just roll forward, you know, just move forward.

Get the, get the patch out there as quickly as you can. And depending on the industry you work in, you're gonna get a variety, you know, extreme on either side. You know, know you never just roll forward.

That means skipping steps in your DevOps processes potentially to try to fix the problem. And then introducing more risk with that. Um, having to roll back all the time, you know, that involves a lot of resources at times.

It involves a lot more testing. I know I was on a team where the risk was so great to just put out an update and have it fail that we were required to not only test the upgrade, but test the rollback just as much, you know, to make sure that we could undo Well, that, that was the real problem here, right? You roll it back, can't hold It back.

You, you literally had to like, hit the, the buttons as, you know, you need, I, I was telling someone the other day reminded me of, you know, 20 years ago where you'd get a message that said, pull out your boot disc on your CD ro and boot it from a another device. Remember those days when you, you would actually do that? Yep.

But that's what you needed to do here. 'cause the thing was not bootable even, and it's just, you know, it, you had to go into bios and start doing things and, and we haven't. Maybe the answer is, Melissa, you hit it right on the head.

Maybe you need to have a rollback and you need to have a tested rollback before you update. But the problem is DevOps culture is, you know, the, the, the, the, the goal is 10 x per day, we're gonna release 10 XA day, right? We're gonna release every day.

And when you, when you have that as your culture, I'm surprised we haven't had something like this happen before, quite frankly. You know, that's where, that's where a lot of the testing comes in, right? It, it doesn't mean just commit all of your changes and, and push to production all of the time.

Um, I mean, it, if you're doing that, it assumes that all of these automated process has have been happening and going on. But again, I would, I would push back on that a little bit. It just depends on the industry you're in.

I mean, imagine, imagine a health device of some sort getting constant updates, right? You're breaking, there might not Be no rolling back from that. Right?

Right. Um, these, these are things that we do and we need to make sure that we understand the risk of what we're doing before we just push forward with a culture or a thought, you know, um, the rules, you know, I, I've always, I've always, uh, even taught my kids this. I'm like, it's important to know the rules and follow the rules, but you're really wise if you know when to break them.

Right? Right. When, when it's necessary to break them.

And sometimes it is necessary, but there's also consequences, right? And, and I, I, I think that that's part of it here too. Well, listen, we only have a few minutes left, but I wanted to kind of focus in now on specifically Jfr, if it's okay, and how they view that cloud native economy, the cloud native ecosystem.

You know, over the years, Jay FAR has had a big role in, in CNCF, the CDF, the open source, the OSSF, open Source Security Foundation, um, you know, big supporters of open source in general, but specifically cloud native. How, how do you guys kinda view, you know, be because it, look, it's a, it's a, it's a monster, right? The the cloud native community is growing.

It's, it's enthusiastic. It, it, you know, it, it, there's so many successes to point to and where, how's Jfr play in there? Well, you know, we really want to make sure that developers have the confidence to release these tools, have the confidence to continue developing new stuff, and putting new stuff out there.

Um, being able to, uh, for example, you know, like our scanning technology, we have, we have a product called X-Ray. Mm-Hmm. So anything a developer builds, um, you could, you know, scan the binaries, find out if there's any existing vulnerabilities in there before pushing it out to production.

Um, you know, there's, there's some, there's some exciting news that we're gonna be, um, giving at our Slum Up event, which is coming up on September. That's in Austin, Texas, by the way, if you're in Austin, I'll be there. Yeah.

Awesome. Awesome. I will be there.

Um, you know, we have a lot of news that's, that's coming down the pipe, uh, regarding this very thing and, and integrating security processes at every stage. Uh, one of the things that we want to work on a lot is, um, you know, we, it's like whack-a-Mole, uh, um, just knowing all the vulnerabilities is not enough. You know, just, just getting a list of CDEs, for example, for, uh, you know, particular, particular product.

That's not enough. Uh, we do go with the shift left methodology. We do believe that the earlier you can find a security issue, the easier the, you know, less cost it's going to be for you to fix it down the line.

But we also support, you know, the other stages of checking it. Uh, for security vulnerabilities as well, including runtime. You need to know when your systems are running something that is, that is vulnerable.

So what we focus on a lot is context. We, we need to relieve our developers and our security team from just having this list of CVEs and understand which ones are actually applicable to you. Because A CVE more times than not, may represent a tiny portion of a package that is used for other things.

If you're not using that particular component, the CDE may not be applicable to you. So don't waste your time and energy trying to fix it. Right?

Absolutely. Highest to fixes, um, can help your, you know, improve your efficiency and getting your software out there faster and feeling confident that, that you've done the best you can. And then you'll be able to continually monitor it after it's in production.

Fantastic. I wanna close, you said something earlier, JFR using a new term anywhere. Ops everywhere.

Ops what? Op ops, every op, every ops. Yeah, every ops.

We're, we're done with op God goes different variations. The silos of ops. Every ops.

I love that term. I'm gonna, I'm gonna steal it. All right.

Melissa, thank you so much for joining us here on Cloud Native Now virtual event 2024. We will see you at Swamp Up. Looking forward to that.

And uh, hopefully we'll see. Uh, JFR is probably be at CubeCon as well. Cloud Native Event, cloud native Con in, uh, salt Lake City, I think in November.

So, we'll, we'll see you then. But until then, say hello to Shlomi and all of the frogs, and thanks for participating with us today. Absolutely.

Always a pleasure, Ellen. Thank you. Alrighty.

Melissa McKay, head developer, head of developer relations, not head developer, head of developer relations at Jfr. Enjoyed the rest of Cloud native now. Thank you very much.