Gayatri Prakash, CloudBees | DevOps World 2023

This is Textron tv. Hey everybody. Welcome.

We are live here in Santa Claras, California for DevOps World 2023, and we have our first interview session. Uh, I I introduce our guest in a moment. We wanna welcome you to our live broadcast livestream of the conference.

We have a whole lineup of people to, uh, come talk with us, some thought leaders in different areas of, of technology and regulatory compliance and future ai. We kinda have all the, all the good jelly beans in the jar that we're gonna go explore and share together. So, speaking of which, uh, have Ga ri, uh, Prakash, who is VPN GM of Compliance at CloudBees.

Welcome. Thank you. Thank you for having me.

Good. I haven't had my second coffee to get all that out in one breath, so I appreciate your patience. Thank you for that.

So, you know, compliance is one of those topics we used to talk about. Like, oh, at the end we, oh yeah, we need to get that information to the compliance and auditing people. Mm.

But of course, we've rethought that completely, right? About how do we make this a continuous part of security and compliance as we're from the very beginning. But throughout the dev development and, you know, CICD pipeline, the entire software development process, and you're giving a talk later too, I wish, I love doing the interviews.

Wish I could hear your talk too, but sures kind of where, where things are at and, and what you're thinking about these days. Sure. Yeah.

Yeah. So Mitch, I'll start with one of the stats I read yesterday while I was flying down, 70% of the DevOps initiatives in 2022 failed, um, to hit the KPIs. mm-hmm.

And the common factor there is security, because security still is very much, it comes in at stages into that DevOps ecosystem. So, as you said, we need to figure out a way of making security continuous and part of the fabric of DevOps so that the interpretation of DevSecOps that we've ended up with is a lot of tooling at the left, which is push early detection, push everything to developer as quickly as possible, but the developer is not a security expert. And developer has joined their job to create features, cool features, service CU customer, things that light up the customer, right?

They are there to create code and they are not always, I shouldn't say this as a generic statement, they're not always the best judge of which CVEs need fixing, which security vulnerabilities could get you hacked versus the ones that can live for the next month's developments lifecycle, right? So, so the trick here is to try and shift security in a smart way. Shift smart, put security steps right from the start.

Absolutely. Security secure by default is my favorite phrase. Not as much as we've heard secure by design.

Of course that's needed, but it should also be secure by default. And how do we do that? It's by shifting security into, like I said, smart, put each stage of security verification at a place where it is most effective, accurate, and scalable.

So whether that's SAS scan or DAS scan or or SCA scan, there is a place for every, every scan to happen, the ability to orchestrate that intelligently from outside of the pipeline. So it's not the DevOps engineers burden to build security into the pipelines they're building. They build the pipelines that deliver code from developers, worktop, desktop through to production.

We take care of the security agnostic to that. Outside of that, that's one part of it because triggering scanning, whether that's, you know, any one of the scan scanners that we just talked about, typically if you take a service, it is made up of a number of assets. Uh, I call them assets, but they're, you've got your infrastructure, you've got code, you've got binary, you've got pipelines.

All of this stuff needs governance. But at the end of the day, if you get separate reports from each of these and push it down to the developers, you're severely hampering their ability to do something with it. Mm-Hmm.

At the end of the day, the scan is a means to an end. It's detection is one is a very first step. It's the remediation and the long-term security posture that is the strategic goal.

So for that to happen, a, you need to know what you've got all the time. What is, this is an application, I can't protect what I don't know. So first of all, have a real time view of what you've got within that application.

We build in the ability within our security and compliance tool to provide that insight to the customers given in our service, given an application, what assets does it use at any given point in time. Second thing is, how are those assets changing? As the developers committing code ci pipeline is running, artifact is getting pushed into artifactory.

How are those assets changing based on change? Detect what needs to be done for that. IE if a source code has just been merged into a release branch, figure out what security scanners that are that can are there in your ecosystem that can act on that source code, get that security posture updated if a binary artifactory just artifact gets pushed into artifactory, trigger the security scans that relevant that is relevant to that action.

And at the end of that, bring all of that together into a single dashboard that is powered from this common source of truth, not a separate report from this, a separate report from this and a separate report from this. Bring that single view that that, that's kind of cube if you like. If one, this developer on one side, security on the other side, your, uh, shared services on the other side, they are all looking at the metrics that are relevant to them to make this whole machinery work.

But it's coming from that single real time source of data. Right. This is just the internal stuff.

If we get this right, the auditors can come and knock on our door anytime. Mm-Hmm. We've just got the evidence ready outta the Box you's great.

Is is you're talking about sort of this kind of what I saw 4, 5, 6 years ago is we're creating all this data and information we have this flow and this process and how, how do we leverage that data, whether it's, you know, security scans or new code being checked in or new dependencies on, on third party code, whatever, whatever things might be introducing potential security issues. Yeah. And how do you make that part of the workflow?

How do you make that part of the flow of the process? Not something that, you know, if you were driving down the street and your car suddenly popped up the latest safety report for your vehicle and all the recalls you might need to do. I don't need that right now.

I just need kind of a few, I need to know what's, I need to know somebody's in the lane next to me. Right. I need to know what I need to work on Yes.

At this moment while I'm in this piece of code or while I'm doing this kind of work. So it seems like, you know, CloudBees make a lot of advances of thinking about this as a, not just a security discipline, but a engineering discipline across the entire kind of workflow pipeline. Yeah.

Yeah, absolutely. And I think that's the point you've made is very valid, which is there are a lot of problems. There's, you know, there is a start that, again, I'm very big fan of these, but there was a start that was released that out of all the CVEs that we know, only 5% need fixing.

Mm-Hmm. The problem is none of us know which 5%. So anything we can do to invest in making that decision more accurate, I bring all of the data prioritize agnostic to everything specific toolings that are out there.

How do we make sure that the information that we are providing as a, as a platform provider is actually going to result in a positive trend in the security? Because if you look at compliance, what is compliance? We mean cloud-based compliance is, it's called compliance and security solution.

What is compliance? Compliance is demonstration to your customers that you have got security covered. Right?

But it's table stakes. It's a point in time accreditation security is much wider than that. It is about making sure that you are secure all the time because the hackers are not waiting for the audits to happen.

Right. They don't read the audit reports, right? Yeah.

They don't read the audit reports. Exactly. So, so there's a, you know, the prioritization that you mentioned, which is, you know, what, what is my today's problem that I need to know it, that is super important.

So a scanner will tell you something is critical, something is high, but is it though, you know, how do we and something that is medium flagged as medium could be a higher risk to your service because it is affecting a service that is very, very exposed. And you know, that that's the decision that we've gotta help the teams make. And we are, as you rightly said, we are providing a single platform as cloud-based.

We are providing everything that is needed for an organization to take developer's code safely across all the environments and ultimately to the customer. Right. And security and compliance is just weaved right into that process.

Mm-Hmm. Everything that we do is about making sure that the customers don't have to do one thing for developing code, one thing for deploying code, one thing for orchestrating code and something else for security then, and something else for compliance. Because that is not cost effective and that is not effective as a process because it introduces friction and multiple stages, right?

Right. We're so used to discrete steps, uh, vertical disciplines, right? And all kind of, it all supposed to fit into its nice matrix of how it works, but it's, there's a lot of friction in that process.

Many things you mentioned that were important, and one of the things I really relate to is the cognitive load, the distance of addressing work that's not in the flow of what you're working on, whether you're the developer or the security engineer context, whoever it might be. What are some of the things that, that help people decide what, what's relevant to provide to a developer at this point in time versus things that might be relevant to a platform engineer or a DevOps engineer or somebody building the environment, but you kinda get the right information to the right people at the right time. Yeah.

So what we do, that's a very good question. Because there is a right skillset required and they have to be, they have to be introduced at the right stages of the problem. That's a very poignant question.

So what we do is we provide what we call the security center for our customers, which is a, again, going back to that single pane view of, for this service, for this application, what are all the problems I have? And think of it as a, a triage center with the help, a little bit of help from ai, um, to say, these are all the problems I have, but developers don't yet need to get involved with all of these problems. So if you have a security champion in your team or an AppSec person in charge of that application, there is a triage process that you could follow because we understand the context, because context is so important in security.

So we understand the context, we understand the composition of your application, put the context in the composition along with the severity and things like the EPSS score, which is the historical exploitability, um, of a, of, of a problem. When you put all of those data points together, it, the security center is allowing or empowering the security champions to say, does this need fixing? Does this need developer input?

It's only when they mark something as business as usual that that would then go into a developer's workflow, end up in a Jira board somewhere for them to do something about it. But there are other examples of where developers might benefit from knowing things quickly. So for example, if you know that log four j package X, y, Z is vulnerable and you've already got that detection intelligence, you've already got, you know, you know, we provide dashboards for our customers to say insights if you like, where they can go and put a third party package that is just being declared as vulnerable, put a version number, and within seconds you get a list of all of the services that are impacted, all of the repos that are impacted and who needs to do what to address that.

Because that's the biggest problem. Detection is the biggest problem when it comes to third party vulnerabilities. So come bringing this back to some problems when I made the point that some problems should, can be pushed to developers and should be pushed to developers.

So this is a good use case when you know you've got a list of vulnerable packages that stuff developers should know straight at the point where they're trying to push a PR into the system with a vulnerable package Mm-Hmm. That they've just introduced. That'd be the point in time to take care of it if yes.

Yeah. Right. And, and that makes sense for them.

So there is a balance between what should be pushed to developers early and what should be triaged before it's pushed to developers. And we support both of these workflows provide the tooling necessary to follow a triage process, track and remediation automatically. And, and, you know, let's face it, not all problems can be fixed.

That is the reality of where we live today, right? Mm-Hmm. And you need to have mitigating policies, mitigating controls, and this is where we allow our customers to build their own policies, provide outta the box policies that can be activated and they can use those policies to risk accept something, right?

Because you are, it doesn't matter how big a security team as you are going to risk accept so things, right? Right. But it's about what mitigating controls do.

You have to accept that risk. Right. Well this, you know, this is such a, a changing landscape, right?

It isn't just the cyber attacks, but it's also regulatory compliance and how do we address all those things? I know people are always looking for information tools. You know, what, what, how can I present this to my board or to, you know, a security team to help kind of get some of these things adopted?

What kind of resources does CloudBees help? Where could they go to get some information like that? Sure.

Um, sure we can, there is, you can go onto CloudBees compliance, uh, CloudBees website and put forward slash compliance. There's a number of use cases, capability reports, and you can also get some white papers there. But there's also a button you can hit to reach out to an expert, watch a demo, and we could do custom demos.

com/compliance and you'll get the resources you need. It's always nice when you can say it's on the web website. Go grab it.

Thanks doctor. Thank you so much. Thanks for having me, VP and GM of compliance with CloudBees.

Stay tuned. We've got a number of interviews lined up. Conversations don't go away.

Same station, same channel right here at DevOps World.