How Pragmatic Controls Build Trust Between GRC, Security, and Engineering

Raj Krishnamurthy (00:01.058)
Hey, hey, hey, welcome to Security and GRC Decoded. I’m your favorite host, Raj Krishnamurthy. And today we have the awesome Mukund Sharma with us. Mukund has 10 plus years in security engineering. He’s the deputy CISO and head of product security at Chime. And Mukund has been a practitioner, a software engineer, and architect at companies like Credit Karma before. Mukund, welcome to the show.

Mukund Sarma (00:23.879)
Thanks for having me Raj.

Raj Krishnamurthy (00:25.612)
Mukund, what made you become a security engineer?

Mukund Sarma (00:30.663)
I don’t think it was like a very conscious choice. I think it just happened so I was working on a bunch of crypto when crypto didn’t mean currency for the government and working on a lot of key sharing mechanisms as a software developer and then

eventually moved into the space of security because I was like, I want to do a lot more than this pure cryptographic engineering. want to be able to like, I just realized that the scope of what I was doing didn’t really, I wasn’t happy with it. I wanted to do a lot more. So then I started just working on traditional AppSec and did a bunch of consulting for a bit, but then realized I couldn’t really get into problems too deep. I wanted to stay on a problem a little longer than

what the consulting gig let me. So I kind of moved into a traditional product security role after that.

Raj Krishnamurthy (01:26.35)
Got it. And I wanted to, I think I wanted to talk to you about particularly practical controls, right, or policy controls. I think we briefly covered it last time we spoke. But before we do that, I want to get your perspectives as a security engineer and as the deputy CISO, right? What is your view of governance, risk and.

Mukund Sarma (01:48.978)
Yeah, that’s a good question. And I think the answer varies very dependent on which company also you’re looking at and what you’re looking on towards it, I would say. But I think for me, it’s like a counterpart to what the traditional protsec function or the appsec function is trying to do. think…

It’s a way for you to actually validate whether what you’re seeing and what you’re doing is actually what is a reality. It’s kind of like a mirror is kind of the way look at it. If you’re going to an audit and telling that, we have x, y, we’re something for making sure we don’t have secrets in code or we don’t have bad configs or whatever, is that a reality or are you like, what’s going on there?

So like keeping making sure that you are in compliance with at the minimum of what your business needs but along with everything I think the way I look at it if you’d have a strong security image program with a strong maturity the compliance as follows along but there are things that you might not assume that is not necessarily but from a compliance perspective is needed so you it’s just like a good validation step and so I want to keep you grounded and honest is kind of way I look at it.

Raj Krishnamurthy (03:06.625)
Got it, got it. So if engineering and security had a linter, it’ll be called GRC.

Mukund Sarma (03:12.101)
Yeah, that’s all. That’s it. Yeah. Yeah.

Raj Krishnamurthy (03:13.197)
Okay. I think the reality is that I think there are people continue to operate in silos, right? The GRC team is typically is a second line of defense operates in silo from the security team. And the security team, not in all cases, in many cases operate in silo with the engineering team, right?

What do you see as the fundamental issue on why we, not in all places, in some places we continue to operate at silos, and how do we sort of bring them all together? Anything out of your experience or any ideas that come to mind?

Mukund Sarma (03:49.125)
Yeah, I think you’re getting down to very fundamental aspects as to how do we collaborate well as a function and if both the security and the GRC function is part of the security teams then in general like it’s is it is it better for the business? Is it much more easier for you to do it this way? There are so many places where actually it is not needed for you to like collaborate. It’s actually required that you for a possible potentially even like report to different functions just because there is a governance and risk function that

is like validating what the security team is doing. It’s closer to like the internal audit fight, but it really boils down to how you want to structure and what makes sense for the businesses kind of the way I look at it. I’m not sure if I answered the question, but yeah, that’s the way I approach it at least.

Raj Krishnamurthy (04:35.448)
But what do you think is outside of security, right? What do you think is the view of security and GRC from other business teams, the leadership, the management teams, engineering? What do you think their view is?

Mukund Sarma (04:49.189)
I think most places people are still recovering from security being the naysayer and being able to go and also be the…

bad guy for the lack of a better term here. And I think a lot of it comes with a job and I think it’s important for us to be that person to say, you know, sometimes this is not the right thing to do and people should hear that. But also like, I think a lot of teams have adapted into the world of like being more collaborative and aligned with what the rest of the business function is and trying to meet where they are. Actually a lot of the effectiveness of and culture of the security program is also like how effective and how well are you.

able to like meet where the business is and are you being pragmatic? Are you able to like work with the folks like convey the risk, convey what’s going on but also like meet where they are and say okay you know what I think the business risk is way more than the security risk so as long as you folks are aware of this and you are willing to make that call it’s on you to like do same but yeah I think moving away from like the gating function to like the advising function is the way I look at it.

Raj Krishnamurthy (06:00.032)
Got it. So you see security not just as, I think, not just as the gatekeepers, but also as potential advisors to the business.

Mukund Sarma (06:09.478)
For sure. Yeah, I think being the gatekeepers is kind of also, this might be a controversial opinion, but I don’t think we got to be the gatekeepers. think if you like, you can learn a lot from.

A lot of the legal teams out there, for instance, is like, they don’t really decide whether or not a product must go or not. I think they are just giving their guidance on here are the potential risks, here’s what could go wrong, here are some things that you could do to mitigate them or contain them, but it’s up to the product manager or the product person or the business people to make a decision on whether that risk is okay for them and they still want to go with it or not.

I think the minute a security function gets too deeply involved and is emotionally attached to it, it becomes their problem. And then once it becomes your problem, it’s much more harder to govern in a way which is being pragmatic in that sense. So there’s actually advantages and you just not like simple things like we say things like we do a security review. We don’t say we do a security approval because we don’t approve it. It’s your decision to approve it.

Raj Krishnamurthy (07:21.729)
I see.

Mukund Sarma (07:23.496)
We are giving you the risks, we’re telling you what could go wrong. Sometimes there may be nothing, but we’re just working with you to tell you that and then it’s your decision to say whether you approve it or not. We don’t approve it, we only review it for you.

Raj Krishnamurthy (07:37.389)
And how early do you think the security teams need to get involved in these reviews? And I think that’s a very good point you’re making. Words do matter. But how early do you think the security teams need to get involved?

Mukund Sarma (07:51.687)
The earlier the better is always true. think it’s like the bandwidth, do you have the capacity, are you able to keep up with the workload of what the business expects and

Also, how are you approaching it matters, would say. So if you are approaching it in a point of like going and saying absolutely no or things in that sense, then people are going to be like less receptive to come and work with you. Also in my experience, I think it’s a small of collaborating with you, understanding what the risk could go and understanding what it is. Like, I think everyone has this dream of like security is involved in every stage of the life cycle. And the earlier, the better and all that stuff. The reality is there will be a lot of people that are going.

and experimenting way before they talk to security. And that’s just the human nature of things. It’s just like when you’re learning something, you’re not going to learn, okay, how is the security best practice from the first day. You just find to figure out how to learn something, do it, use it well, and then come back. And once you have gotten a grip of how to use it, then you look at, how do you do this the right way? So there’s definitely, while the…

While the most ideal situation is that you’re always involved right from the ideation and things that sense, the reality is I think most people tend to have a version of it in their mind already before they reach out to security. But again, that’s where you like have built that collaborative environment to say, you can come brainstorm with us, give us your ideas and we’ll tell you what can go wrong kind of a thing.

Raj Krishnamurthy (09:26.177)
Got it, got it. And there is always this friction and tension between these two different teams, right, engineering and security. What is your take on that? Why do you, I mean, is this real? Do you see that there is an between engineering and security?

Mukund Sarma (09:41.69)
doesn’t have to be what I’ve realized. don’t think it doesn’t have to be it.

Raj Krishnamurthy (09:44.043)
It doesn’t have to be. So what makes it to be and what makes it not to be?

Mukund Sarma (09:52.367)
Yeah, I think what I’ve seen is a lot of security teams trying to push the security tools and functions onto the business, onto the engineering teams and make it their problem. And like Prasai said that.

We have this thing and we are not willing to understand the business context of it and we are just going to say this is a high criticality or high severity ticket and you’ve got to fix it in 14 days. Whereas in reality, I don’t think I’ve really met any engineers that outright come and say they don’t want to fix it. I think they are, if you explain it well, they understand what is going on. I think they are more receptive to doing it. It’s just like, they have the right tools? Do they have the right advice? Do they have the right way of knowing it?

And is that even a right assessment that gets down to boil thing into it because more often than not you start looking at it. might seem, your tool might say it’s a high or critical, but you actually go look at how it’s being used, where it’s being happening, and then you realize it’s actually closer to a medium or a low. It’s not really that likelihood. There’s no real likelihood of that being actually exploited. Regardless, think people should go fix it because you never know if that’s going to change. It’s kind of a point in time review, but at the same time,

working with them to like making sure that there are enough tools that the engineers have. There’s guidance on how to ask for an exception. There are like all these opportunities like to say that, know what, we will get to it. We just need a few more weeks or a few more days to get to it and trying to see if that makes sense. If it doesn’t make sense, you’ve got to like push back, you know, that is also part of the, that’s kind of what the security’s job is. It’s like advise and strongly advise when you spend

It is against what your reality of the situation is. yeah, think a lot of times even like making people, engineers, come and log into a security tool and make sure that it is resolved in your tool because you don’t want to like meet where the engineers are. I think that’s like right from there to like having low confidence in the findings, not understanding or having an ability of what other engineers even talking about or doing, all those kinds of things.

Raj Krishnamurthy (11:37.218)
Got it.

Mukund Sarma (12:02.372)
build that friction and they lose trust in your team basically that’s kind of the crux of it.

Raj Krishnamurthy (12:07.39)
Okay, so I think what I’m hearing you basically say is that if you collaborate, and if the intent is right and the spirit is right, that I’m here to collaborate with you, I’m here to sort of coach you, guide you, help you, more than not taking a high pedestal, then there is obviously an opportunity for us to be able to work together. So more of a carrot than a stick, right, in making this work.

Mukund Sarma (12:17.53)
Yeah.

Mukund Sarma (12:29.498)
Yeah. Yeah, I think…

Like I said, I think it is also important to have that stern hand and say, know what? I don’t think that is right. This is reason why we have, you can have telemetry from various sources, right? You can even have like, for example, if your runtime sensors are telling you, no, it’s actually being used and this is how it is and you have a good telemetry of that, then you can just point out or say that I don’t think what you’re saying is true. Like this is where we are seeing, like why would we see this if it weren’t really running it runtime or whatever and having that conversation because

You also don’t want to become that a team that will agree with everything. You just have to maintain that good balance is kind of the way I look at it.

Raj Krishnamurthy (13:12.012)
Now, you’ve been a security engineer, you are a security engineer even today, and the question is that I think this idea of shift left in security has almost taken a strong hold in the last few years. What is your take on that?

Mukund Sarma (13:28.696)
It’s incredibly hard to get it right. It’s very effective. It works well, but it’s also not a very simple thing to get right from day one. It takes a lot of…

building additional pay spots along with shift left tooling. I think that is, you can’t do one or not the other. I think it also depends on is that the right choice for the business, right? And that is kind of a conversation you need to have with your own teams to make sure that that is what is needed. I think whatever the shift left strategy and how much ever we want to do that, we also want to know the…

what’s actually happening at the runtime. Like as someone who’s responsible for the security program and want to have to know what’s going on there, yeah, I want to catch these findings well in advance. I want to be able to fix it. I want to be able to prevent it. But also I needed the reality of knowing what’s actually happening today in the ecosystem. so I think it’s a good mixture and combination of many, but…

I think a lot of companies have gotten this right, but it takes a long, time. It’s kind of the crux of the problem. It’s just like, it’s not, it involves a lot of tooling. It involves culture changes. It involves people wanting to like work with you to make sure that it is the right thing for them. They should also realize why it is important for their teams, not just for your team. So it’s a hard problem, but I think there is value in it.

Raj Krishnamurthy (14:56.734)
So what I’m hearing you say is that I think the idea of looking at shift left is one, make sure that you have buy-in, two, make sure there is a very clear paved path, three, make sure there is a very clear exception handling because not everybody is going to fit into that mold, and four, do this together, right, and where you are able to participate as freely as possible. I think those are great points, Mukund.

Mukund Sarma (15:09.509)
100%.

Raj Krishnamurthy (15:18.624)
I think one of the flip sides of this idea of shift left, right, I think the flip sides of is that you’re going to produce more signals. And I think it’s a debatable topic whether the signal or noise. To some it may appear signals, to some it may appear noise, and also from a time dimension perspective. What has your experience been as you try to shift left, right, and there are more signals that the developers have to consume? How do you manage that? How do they manage that?

Mukund Sarma (15:46.724)
I think this is going back to that paid path. Part is, if that existed and we worked on building that together, all those signal or noise, whatever that part is there, is handled because it’s much easier for the developer to just go through that paid path and be done with it. That way they don’t have to deal with all of these different downloads. At Chime, we tried this thing with this…

We have different classes of issues we have tried this way. Like simple, like we are a microservices ecosystem, so we have hundreds of microservices and the default, like, okay, how do you authenticate and authorize all of these various APIs calling each other in the ecosystem, right? We realized that if we, earlier when we started, we working on this, we just realized there were so many different frameworks being used by different teams because they didn’t, all of them wanted to go fast and didn’t really,

a good centralized framework or thing from the security team. So even for us, auditing became really hard. That’s making sure that, you know, is this actually protected endpoint or is this actually a protected method or whatever it is. And then what we did is we built out that paid path to say that, you know, all you have to do is define this one JSON blob in your code repo and we’ll take care of the authentication authorization for you. That gives us like very simple ways of easily auditing what’s happening. And at the same time,

It’s also very easy for the developers. They don’t have to build a complex auth system behind it. There are SDKs, and it supports every language. They don’t have to redo anything. All they have to do is spend five minutes to just get that set up and maintain it. all. That is an example of a paid path, which we worked on. It’s actually much more easier for someone to use that than go build their own auth and say that they’re just like, know what, we’ll just use whatever security has built because it’s like,

Raj Krishnamurthy (17:34.86)
Totally.

Mukund Sarma (17:40.487)
then we don’t have to worry about that from our platform perspective.

Raj Krishnamurthy (17:43.156)
Absolutely, absolutely. And you’re totally right, if I’m an engineer developing a business function, why would I want to know all the possible path to workflows or OpenID workflows? mean, it’s not that I shouldn’t know, but that’s my core job is something else, right? So.

Mukund Sarma (17:55.204)
Yeah, exactly. Exactly. And.

Yeah, even just simplifying that whole thing to make it easy for even the developers. For example, instead of going the traditional OAuth scopes kind of approach, we took the methods to say, you tell us who your callers are, and you don’t have to worry about scopes, and we will figure it out. Because if you talk to a developer, all they know is, OK, this service is calling me. They don’t really know what the scope name is, how is that related to the permission, and all that stuff. So the whole platform handles all of that for them. They don’t have to worry about any of that stuff. All they have to define is who it is.

Raj Krishnamurthy (18:28.0)
Makes sense. And I think this is where you’re saying that it is awfully difficult to do, because in some ways, you’ll have to understand the forest first about what are the possible opportunities for each of those application teams trying to do, let’s say, authorization or authentication, and then figure out what is the most common denominator that you’re going to build in terms of the platform for a paid path, right? Is that why you said it is very complex?

Mukund Sarma (18:29.447)
But…

Yeah.

Yep.

Mukund Sarma (18:42.842)
Yep.

Mukund Sarma (18:48.453)
100%.

Yeah, and also undoing everything that everyone has already done. So you have to migrate them over and remove all the older ways of doing it because ultimately now, yeah, it gives us that visibility and a way to audit it very easily. But it’s also not like a two-month project. It’s closer to the in-the-years kind of realm because of the scale of what it is.

Raj Krishnamurthy (18:54.667)
Yeah, exactly.

Raj Krishnamurthy (19:14.038)
Totally, But when you approach this typically, Mukund, do you differentiate between green field and brown field? What I mean by that is, do you draw a line in the sand and say, any application henceforth takes this approach, shall take this approach, and then you take a very different approach to the application that you’ve already built, I would say the legacy applications. Is that how you think about this?

Mukund Sarma (19:38.597)
So, yes and no, would say, because there is, it’s kind of in many ways, arrogant if I say I understand all of it and go and get it right. And I also don’t understand the complexities of what different, and sensitivities to like latency and other aspects that different teams will have.

I think we have built for the general use case, not the specialized use cases. And there will always be exceptions, right? There will always be situations where someone needs to go do something. Their intent is pure. Their intent is like they need to be able to do that. At the same time, they just can’t afford the platform that we have built because it adds a lot of latency, for example. For the record, I don’t think it’s high latency, but even let’s say that it was an argument up here.

At that point, we just have to say, as long as it meets our minimum requirements, which is to say that you’re authenticating all the calls and you’re authorizing the different endpoints, and we have a way to audit what you’re doing, you can do whatever you want. If you want to go build your own Authenticity that makes all those requirements, because it works for your situation, go do it. As long as we can still have a way to audit it. That’s our requirement. And that is kind of why we built it this way. But if you have your own reasons and you could very well have your own reasons, then go do it.

Raj Krishnamurthy (20:49.493)
Beautiful.

Mukund Sarma (20:57.606)
But as long as we have those met, we are fine with it.

Raj Krishnamurthy (20:59.947)
I love what you’re saying because I think it goes to the crux of being empathetic from an engineering perspective. had one of the guests earlier, Jiffun Satapathy, made, who was the CISO of Medalia. He made a phenomenally great point about it. And what I’m hearing about is that the idea of humility, right? That security needs to have almost inbuilt to make sure that you may not have answers to all the questions. You have to actually listen more than to talk more.

Mukund Sarma (21:24.758)
100%. That’s always, that’s literally my job is like always listening. And because there’s…

We are always trying to catch up. However mature your team is, they’re still trying to work with the rest of the function, and they’re always at a phase that’s faster than you, or you’re at their pace too, but you’re still catching up to what’s happening. Because in fact, security engineering jobs are much more harder than software engineering, because you also have to learn how to use it and then secure it also, whereas software engineering folks, most of the time, they just have to learn how to use it and go and build with it.

Raj Krishnamurthy (21:55.125)
Totally.

Raj Krishnamurthy (22:01.535)
No, And you made a point sort of earlier in the segment. And your point is that if you build this right, meaning if you do the security engineering right, then compliance is a byproduct. And I’m using compliance. said GRC is a byproduct. Compliance and risk are byproducts. Is that a fair statement? Did I hear that right?

Mukund Sarma (22:06.372)
Mm-hmm.

Mukund Sarma (22:15.842)
Yeah. Mm hmm. Yes. And maybe I’m oversimplifying it. There are there are aspects of it which

GRC can still like that doesn’t necessarily solve for the GRC aspect but for the aspect of are you making sure you’re meeting all the requirements? Are you sticking to the standards? Are you following the best practices? That part is true. There’s a lot of other parts of GRC which is like how do you communicate these risks? How do you build the process around it? How do you handle and track all these exceptions? All of that part which is not necessarily 100 % true in that statement. I’m not sure if I made sense but yeah.

Raj Krishnamurthy (22:53.215)
Got it, got it. And I’m going to look stupid for asking this question. I’ve spent an awful lot of time in GRC. Mukund, but there seems to be the looking down on GRC, typically from security and engineering, that I’ve not, in many cases, that I’ve come across. Why is that? Why is GRC one level below security?

Mukund Sarma (23:19.864)
think ignorance is my answer. I don’t think it is necessarily one level below. I think they’re completely different functions. And I think if you’re trying to like correlate the two in any way, you just don’t realize what the function serves for the business, in my opinion. I think a lot of that, I understand where you’re coming from. I think a lot of that comes from purely like people misinterpreting it as like, they don’t have to code. They don’t have to build tools. They don’t really understand what’s happening. They don’t understand.

this platform or they don’t understand XYZ or whatever it is and they just like coming with policy documents and asking us can you meet this whereas in reality what’s happening in the company or what’s happening down in the tech stack is like way different from what people think but I think that’s also like

a thing where the security team or the product security function should work with the governance risk and compliance team to say, you know what, this doesn’t make sense in our ecosystem for these reasons, but here are some compensating controls. And that is kind of how it is. But I think it’s purely, my answer is ignorance. I think it’s that. They don’t realize what the difference is.

Raj Krishnamurthy (24:31.007)
Got it. And do you also manage GRs? Have you managed GRC functions? Have you been part of GRC functions in current role, previous roles?

Mukund Sarma (24:40.153)
I don’t manage the GRC function. We work very, very closely, though. So, yeah.

Raj Krishnamurthy (24:42.699)
Closely with GRC. And so my question, I think you said this something very profound in my opinion. What do you, because you’re almost talking about sort of engineering as a discipline, of which there is application engineering, there is security engineering. GRC is typically not considered engineering as a discipline. It is considered more policies and sort of documents and authoring and things like that. Did I hear that right?

Mukund Sarma (25:06.046)
I that’s kind of my experience. I don’t think it’s necessarily having to be true. I think there are a lot of GRC functions that use engineering as a tool to get better at what they’re including the team where I’m at currently. So…

I don’t think it’s necessarily true, but I also don’t have an expectation that they are solid engineers and they go and build and build quality tools that everyone else can consume. I think everyone is building stuff nowadays to make their lives easier and that is fine. like I said, think the way I look at it and the way I’ve always approached it, it’s a very good mirror for me. I might be really mad looking at it myself because I’m like, we don’t meet those situations there, but

That’s a good thing. That’s a good reflection on my other program, but that’s kind of the way I looked at it. It’s like, yeah.

Raj Krishnamurthy (25:58.079)
Got it. And I think what I’m hearing you say is that I think the idea of mirror, it’s a very good analogy. And by that, you’re basically saying that GRC is an independent observability function for some of the work that is happening in security and in engineering. And my question to you is that you are moving at 1,000 miles per hour. You’re talking about thousands of releases. And DevOps is a very common theme for you, especially in the world of GNI. I think the number of releases are just exploding.

Mukund Sarma (26:24.035)
Mm-hmm.

Raj Krishnamurthy (26:27.22)
How can GRC not be an engineering function? Maybe I’ll ask you slightly a different perspective. What is your take on that? I think my question to you is that should GRC be as much an engineering function as security is?

Mukund Sarma (26:43.275)
Not necessarily. I think what we should have is a bigger picture.

What I’m about to say is it doesn’t matter if there are thousands or millions or whatever it applies it as long as they’re repeatable They’re meeting the requirements that you’re doing the things the right way there’s a there’s a way for you to make sure that whatever change you’re introducing is verified for Regression not make sure it has bugs or whatever it is Make like having that conversation with the engineering function and saying that we don’t care. Whatever speed you’re going at Whatever however you’re doing as long as it’s meeting these requirements and we have a way to like

Verify it we have a way to audit it. We have a way to like make sure it’s what you expect it to be and Even if you don’t have it necessarily today, like what’s your roadmap? What’s your timeline on making sure that that is the reality? Yes, if you don’t have it today, that’s a risk and we’ll talk about what the risk is but then

We also don’t expect it to be solved 100 % before you start using something. And sometimes it just makes sense for you to like.

build those controls while you do it. Because a lot of times, there are things that we get started on. We start building and then realize, you know, that doesn’t make sense. We have to change things out. And then there’s a lot of adjusting the levers to make sure it’s in the right path before you actually have it running. So a short answer, no. But if GRC wants to use build controls to make sure that they can audit it in that way,

Mukund Sarma (28:16.855)
then yeah, then it’s an engineering function. But if they are able to work with their counterparts in security or engineering to say, you have to build me something so that I can go do this this way, that’s fine too. Like I don’t think it’s one way or the other.

Raj Krishnamurthy (28:30.474)
Got it. So I think what you’re basically saying is that the function has to exist, or the engineering capital has to exist. Where it exists depends on which company you operate, on the context in which you operate in. Got it. I think that the last time we spoke, I think you alluded to this idea of practical controls, right? And what you made me think was that, OK, there is a gap between what controls are and what controls should be.

like almost like the Kubernetes reconciliation mechanism. what is your take on, I would love to sort of, our listeners to hear more. I mean, maybe can you describe your view of practical controls, maybe one or two specific examples so that we can tie this together.

Mukund Sarma (29:14.851)
Yeah, maybe I think what I was going to do with that is like, let’s be more pragmatic in what you’re asking for, right? If you were the engineer working on it and there was nothing that you could do to make sure that was addressed, whatever the requirement was or whatever the control that you’re asking them to build is, either by tooling or by policy or whatever mechanism you’re using, then…

What do you expect from them? Is that a residual dress that they accept? What are we trying to communicate? How are we trying to communicate that? What is the conversation you’re going to have with them? At that point, is that something that everyone even needs to know? Or is it that leadership function needs to know and they work through it?

There are always compensation controls. You can say, okay, we’re going to create a training. We’re going to create a best practices document. We hope that everyone will go read it. But again, there is a limitation to all of that. So I think what I was getting down to is what controls are you proposing for what situations? Are they pragmatic? Would you be able to do that if you were in their shoes? And is that timeline what you’re expecting them to be reasonable?

communicated this to them, like more often than not, it’s just like, I’ve had several times where I’ve been like, you know what, we did this review, here are the risks. I really don’t know what to do here because I don’t know how I would go solve for this either, but let’s talk through it. Do you have ideas? Can you think of some ways that we can walk on this together? And.

Sometimes they come back with better ideas than we even thought of. Actually, most times they come up with better ideas than we even thought of. And then sometimes they’re also like, you know, actually, I don’t know how to do this. There’s no examples of it. I spoke to my friends in other companies. I spoke to like other people doing this and,

Mukund Sarma (31:08.099)
or it’s coming up in three months from now because it’s in the roadmap or whatever. And then at the point it’s just like, okay, you know what? Let’s just like, that’s a risk. You should know it. You know it now. Let’s like, you are saying that you’re aware of it and you’re gonna acknowledge that and work on it. Then we’re gonna do that. So that is kind of what I meant by practical controls in many places.

I think a lot of when this whole Gen.AI boom with chat GPT release and everything in there, a lot of teams were just like, we are not going to use it at all because we have no way of…

governing it or we have no way of like securing it and even the other generic security vendors or whatever tools that came coming out where there was a lag, know, like there is between when the product is a technology is released to when it is actually being and there is a governance function to it. So in that case, I don’t think the practical control that is to say don’t use it for because you are also hitting the learning curve part of the problems. I think then you’re saying, okay, you can use it in these conditions and for these kind of

situations, yeah, we may not have tools to validate it, but that’s a policy control at that point. We are saying that if we see that you’re misusing it or we see that you have been saving and then we’re going to have a conversation or whatever, but at that point, you’re still letting the business go and try things out in a safe manner, like going and learning things and learning new technologies. That’s one example.

But yeah, there are things like…

Mukund Sarma (32:47.616)
Yeah, I think that was one example. But yeah, let me know if you any other thing else.

Raj Krishnamurthy (32:50.122)
So I think what you’re basically saying is that sometimes the outcomes are not very clear. And I think you made a very important point. If you put yourself in those engineer’s shoes, would you do this? I think this is an important way, which means that you’re basically saying, does that add value to what outcome that I want to accomplish? And towards that end, my question is you spoke very brilliantly about the paved path.

Mukund Sarma (32:57.472)
Hmm.

Mukund Sarma (33:08.514)
Correct.

Raj Krishnamurthy (33:16.148)
To what extent are the GRC teams involved in the paved path? To what extent do they provide feedback in the paved path? How much would you like them to do some of that?

Mukund Sarma (33:31.255)
Mukund Sarma (33:34.561)
I don’t know, don’t think so. I don’t think there’s an expectation that they are involved. I think my expectation is it’s clear, if we were to do this and it were to resolve these issues or it were to meet these criteria and here’s how you go audit it, does that meet your criteria from a…

compliance governance perspective. And if they say yes, then we’ll build towards that and give them the necessary tools and visibility to go govern themselves if they had to. If they said no, we need XYZ in addition to that, or we need to have a way to do this, then we’ll like, I think I would use them as a collaborator or as a stakeholder in building out the platform or the speed path in that case, or having them contribute to it. That’s kind of my approach.

Raj Krishnamurthy (34:22.142)
Now, because I’ll give you a very tangible example, and I’ll tell you where I’m coming from. Let’s say that, for example, tech-forward companies actually use this idea of immutable images, right? And you are basically, at that point in time, what you’ve basically done is you have shifted the concept of systems into GitHub. That’s what you have done.

Because all of these are declarative manifest that you’re sort of managing and you’re deploying through your Helm charts or whatever it is, right? And these are immutable images. So traditional GRC person’s view of patch management does not apply here because there is nothing to patch, right? I mean, yes, there is, but it is operating at a different layer.

Mukund Sarma (34:55.97)
Mm-hmm.

Raj Krishnamurthy (35:02.088)
So, and that’s where I was trying to tease out, right? So, you know, if they understand that your paved path is to create an immutable image, your paved path is to create circuit breakers, and so on and so forth, they may have a different view of how to manage these controls rather than ask sort of onerous questions.

Mukund Sarma (35:04.693)
Okay.

Mukund Sarma (35:20.596)
Yeah, 100 % agree. I think that is kind of where I was going to say that the security function needs to work with the GRC function to say that that’s not how we do things here. This is how we have approached it. Does this make sense for you? Does this meet our audit requirements? Does it meet our ability to like…

Conway, what we turn into Conway. Yeah, another really solid example, I think, was I was reading this somewhere. I don’t know which company it was. I’m forgetting the name. It was a open blog. It was a blog post on this, which is like they went down the route of, you know, how do we not have any other utilities in the image that we ship to the point where they could not even do like four and six snapshot or anything in that sense. And when they actually had an incident, they were not able to like, I mean,

the requirements of that incident because they built this in a way where they shot themselves in the foot, where they can’t even go back and put on a thing that can take a snapshot of an image or whatever it is because they went all in on the extreme side of hardening and it had consequences from a… So in that case, I would think…

Raj Krishnamurthy (36:29.939)
That’s a great point.

Mukund Sarma (36:33.91)
them having a discussion with their things to say, okay, we still have a way to do it. is kind of fun. Yeah.

Raj Krishnamurthy (36:35.773)
Totally. Totally. No, that’s a brilliant point, right? And you have to make sure some of those compliance requires, especially on the type of applications, right? And have to be made as well. So I want to ask you about the idea of shifting GRC left. If there can be a security harness, why is there no compliance harness?

Mukund Sarma (36:43.497)
Exactly. Yeah.

Raj Krishnamurthy (37:02.375)
Inertia CD pipeline.

Mukund Sarma (37:03.042)
I don’t know. think maybe it’s because a lot of times, lot of the laws and compliance comes way after a particular thing is released. Like, even today, we don’t have any actual laws or requirements from a compliance perspective for anything Gen.AI that I’m aware of, like at a state level or a federal level or any of that stuff. There could be aspects about verifying that it’s not being used for …

causing harm from a buyer’s perspective or you know, a safety perspective, but that’s those are like guidelines that most companies have and not really a way to go audit and make sure that it is there. So in this case, we already are working towards like a shift or a paid path for building GNI applications in companies. But what is the GNI compliance aspect there? Like it’s not even defined. So how do we, yeah.

Raj Krishnamurthy (37:59.082)
That’s a great question. Maybe I’ll flip the question slightly differently. Let me move from compliance to risk. So why is there not a security risk harness?

Mukund Sarma (38:02.275)
Yeah. Okay.

Mukund Sarma (38:12.009)
I think there is. I don’t think there is, it’s not. think what you’re trying to say when in your shift left, forget every of this, I just said with JNI, anything. Even what you’re trying to say with shift left is, okay, you are…

building code, right? You are writing something, you’re committing something to GitHub, you’re opening a draft pull request, your security team is running a bunch of checks in the shift left world, right? What is that trying to say is it’s calling out the risks for what the thing is there, right? So there could be abstract rules or security tools, but ultimately what they’re trying to do is call out the various risks and that is being introduced, right? Your IAC part of things is also similar, right?

Raj Krishnamurthy (38:39.291)
Exactly, exactly, exactly.

Mukund Sarma (38:54.403)
you could say that your requirement is that you don’t have anything that is publicly facing EC2 instance. That could be your requirement for the company. Yeah, sorry, my bad. Yeah. So, or you don’t have a public infrastructure, or you don’t have the most stupid example, the S3 bucket example always, like you don’t have a S3 bucket that is out there. But, like you could actually…

Raj Krishnamurthy (39:02.749)
ISC is infrastructure escort.

Mukund Sarma (39:20.821)
do that and call out the risk and have that conversation with the person there right at the shift left. So I think looking at it from what are these security tools doing and what is the ultimate goal of that is like to call out and prevent those risks from existing in your ecosystem. So I think it is that is just how you portrayed, how do you talk about it. That is important.

Raj Krishnamurthy (39:40.691)
Got it, got it. So to go back to your analogy, if I want to look at the mirror, what I’m saying is, can I keep looking at the mirror much more frequently, right, at the time of you releasing it, right? And you’re saying that exists, or that should exist, and if not, it has to be engineered into it. Okay, got it.

Mukund Sarma (39:48.811)
Yeah, exactly.

Mukund Sarma (39:55.616)
Yeah, exactly. Ultimately, when you’re like, for example, it’s saying someone don’t do this because of this vulnerability. What I want to say is that if someone were to exploit this vulnerability, here’s the risk. That’s what people want to hear. They don’t really want to know what your CVE number is. They don’t really care about that. What they’re trying to understand is what is the business risk of this not happening or what’s the technical risk of us not doing this? And how are you how well are you communicating that? Like you could throw in whatever CVE number, but does it make sense to them? Like you have to talk to them about what the risk is.

Raj Krishnamurthy (40:25.481)
So a lot of this GRC has two functions. There are systems that you basically data that you collect from security tools, your paved path tooling, your applications, your SaaS applications, cloud, Kubernetes, all these different sorts. And then there is people. You are still touching in many cases those engineers, the security teams to provide some feedback.

Whether it is your access control, do you have all the right people in your team have the right level of access, right? To avoid inside the threats or vulnerability management. You promised that you will close certain class of vulnerabilities within a time. Are you doing it? Are you remediating it? Things like this, which is the purpose of the GRC function. What is the effect of that as a toil on engineering teams, whether in security or in application engineering, product security or corporate security or application engineering? What is your take?

Mukund Sarma (41:24.071)
It’s initially heavy and

but it’s on how well you collaborate with the team that’s building the pay parts or could help you build these controls into the different frameworks and make sure that there’s not a thing that you have to go talk about or even worry about. I think when you first start up a program or when you first start working with people, there’s a lot of those that will have to just like, even like when I first started the program, I mean like talking about like, make sure you have someone that’s doing two code reviews or one code review.

That was a conversation we had to have, know, because that whole function didn’t necessarily exist. Now no one even thinks about it, talks about that, because, we have getting functions that do it, we have things in that sense. So it’s just like, part of the, it’s a security factor that is kind of already handled with. So it’s kind of a maturity thing, I would say. So initially, yeah, definitely you don’t have anything, you are working towards it, you’re going to have that be a lot more. But it’s on how well can you work with your

security counterpart to make sure like all of this is like You don’t have to think about it, you know Why did you even make it a problem? Like why don’t you just go make like why don’t you have preventive controls and not make it a problem there? Yeah, so

Raj Krishnamurthy (42:37.362)
Beautiful, beautiful.

So, got it. So I think your argument is that I think the GRC teams job is to question these things because as you were earlier saying, they are making sure that the promises are kept, the promises you make, the promises are kept. And in order to reduce the toil, I think they will have to work closely with the engineering, particularly the security teams. The closer they align with the paved path, the closer they design this as preventative controls and test of design controls, the better it is, is what I’m hearing. Okay, got it.

Mukund Sarma (43:06.113)
100%. 100%. Yeah.

Raj Krishnamurthy (43:08.298)
think this is fantastic. I wanted to maybe, what do you see as a security engineering leader, Mukund, the role of JNI today in security?

Mukund Sarma (43:21.505)
It’s a very loaded question. think it’s a very powerful productivity tool. It’s kind of the way I’m using it. There’s a lot of…

Like, how do you keep focusing on doing the main thing, keeping the main thing, the main thing is kind of the way I look at it. It’s like, I don’t think you ask anyone, they want to like, they get a lot of joy saying, this morning, I’m going to wake up and close five tickets on JIRA or whatever it is. Like, that’s not their goal. They’re like, so using all the various NIA tools, like make sure that that kind of admin operational work is like handled for them to keep, go back and continue to work on what the right thing is.

Also, I feel like it has kind of enabled a lot more people to just go and try things out for themselves for the first time, way more than previously. And this is true not just in the security side, it’s also true in the engineering and product side, I think.

We have lot of designers and product managers that are using a lot of these tools, like prototype, understand what it is, get a sense of how it feels even before they have engineering functions come and build it out. So I feel like it’s a really, from a person who’s consuming it, it’s really helpful. It’s a very good productivity tool. But you should also know the limitations of it. And you should also realize how, I think the more you use it, the more you’ll realize how people can also abuse it, because you’re wearing your security hat often.

like go and work towards building controls towards it. So I feel like my thing is like I want most people to use it because it actually, even if you don’t like it, even if you’re an ACA, even if you’re skeptical about it, the reality is that everyone else is using it. And for us to be able to secure what everyone else is doing, we need to know how it’s being used. So yeah, my take is that. think it’s like any other technology can be used for bad also. But yeah, that’s kind of fair.

Raj Krishnamurthy (45:17.392)
I think it’s a mixed bag always. But as a security professional, what gives you sleepless nights today given every single technological shift that is happening? What makes you wake up at night? What makes you think that we should do a better job?

Mukund Sarma (45:40.609)
I mean, that’s a pretty, very loaded question. I think…

I think there’s definitely like, are your controls working the way it should be working, even in this new realm of things? This is one of the biggest thing I would say. Like, do you have coverage? Are you able to make sure that it’s working the way it’s supposed For example, let’s take a simple example. A lot of folks keep asking me, are you worried about the code that is generated by all these various good GenAI tools and things like that? I’m like, as long as it’s still committed, as long as it’s still going through the same pipeline, yeah, the velocity has increased, the volume might be more, the lines are

of code might be more, but you know what, we already have tooling to handle all of that. And we might end up with a lot bigger AWS build because we are spending a lot more compute to validate all of this, but not really. I’m not worried about it. I think there are different classes of issues that we should be looking for that a traditional SAS tool, for example, will not be looking for. So we’ll have to work on building those controls out or detections out. But from the thing about, like, are you worried about 100x code?

100,000 Xcode, I’m not really worried about it. that’s the coverage part I was talking about. Same thing with, do you have visibility into how your applications get deployed? Now that all these web coding tools exist, what are people deploying that? Is it real member stuff? it just prototypes? What goes in there? So I think the coverage part is definitely one thing which I’m always worried about is how well are your controls working? And do you have visibility into when they’re not? That’s kind of the crux of it.

Raj Krishnamurthy (47:10.236)
Got it, got it, got it. I think one of the challenges, and this is nothing new, right? This happens with every technology influx, is that for example, when open source was sort of front and center, and has been there for a long time, couple of decades now, we had to deal with these transitive dependencies, right? There are libraries within libraries within libraries, and you can only control so much in terms of depth, right? I think the one question that I’m hearing as a constant argument, especially with wipe coding and

Mukund Sarma (47:14.824)
Yeah, exactly.

Mukund Sarma (47:25.248)
Mm-hmm.

Mukund Sarma (47:28.853)
Yeah.

Raj Krishnamurthy (47:40.17)
developing code in many cases is how much do people really understand code now?

Mukund Sarma (47:49.035)
How much do people really understand when they’re copying it from Stack Overflow?

Raj Krishnamurthy (47:51.974)
That is true.

Mukund Sarma (47:54.823)
It’s just like you’ve just made it easier to happen. I don’t think it’s the problem that’s new. I think the problem always existed. Like people are copying it from different Reddit or SAP Codeflow or whatever they’re getting from trying things out. You hope your code review process is working well. You hope your senior engineers are catching that out. You hope that stuff is being caught. Otherwise, you know what? It doesn’t matter. You still have… It’s not a single

Raj Krishnamurthy (47:57.735)
Yeah.

Mukund Sarma (48:24.706)
point of failure is it like you you you can you might miss it at code review you might find it at your pen test or your dynamic analysis or you might find it from a bug bounty or you might get back that later it’s just about how quickly are you able to identify that and how are you able to get to it so I don’t know I don’t necessarily think it’s like

Raj Krishnamurthy (48:43.577)
No, I actually, let me say I love this because I was actually trying to push you as a security guy and I was trying to see the pessimism and I’m super glad to see a very optimistic security guy on this. So thank you very much. I think this is needed, my honest opinion, so thank you very much. I want to ask you a slightly different question, which is you talked about GRC as a mirror, right? Which is that it is an audit function.

And as a result, as you audit, especially for inside the company operations, you are generating a ton of signals. Does everybody have even simple things like this? Should everybody be protected from an MAFA perspective, which is a test of design control for all the users? Do you have proper pull reviews to your point, so code reviews to your point on the pull requests, things like that. What do you think as a security guy who’s dealing with product security and app security?

What do you think of consuming these signals that are generated by GRC as part of your security admission control process? Does this data flow back into security at all? Is there any value in this data flowing back into security? When I say security, I’m talking about transactional security, right?

Mukund Sarma (49:55.137)
Yeah, definitely a lot of value. think the things like how do we make sure you have the MFA thing that you talked about, or how do you make sure people’s access controls are locked down and things in that sense. Once we understand the problem more from a traditional security perspective, and we also understand that it is important for not just

the risk and governance and compliance perspective from an audit perspective. It also takes up time for us to go give back our evidence and audit and all of that stuff. So let’s just fix this problem to say that, you know, the default method or the different way of doing it is all there’s always a feature to compliant MFA. There’s no exceptions to it. Or we only have a small exception list and that is treated by separately and there is real time audit logs and things that sense for people to consume it that way that the scope of the work is like.

reduced drastically. I think it’s a two-way thing. I think, yes, we won that thing, but we also are trying to see how do we reduce the…

Raj Krishnamurthy (51:01.965)
That’s a great point. So I think what I’m hearing, I love what you’re saying. I I asked a different question, you’re answering in a different way. You’re basically saying, let’s avoid as much as possible even generating the data in the first place so that they are incorporated as preventative controls. But in case we generate the data, let’s bring them back. I think that’s the argument that you’re making. That’s beautiful. Got it. No, that’s brilliant. That’s brilliant.

Mukund Sarma (51:19.87)
Yeah. Yeah, exactly.

Raj Krishnamurthy (51:25.315)
We are approaching the end of the segment Mukund. This has been a fascinating discussion. So I want to give you the next 60 seconds, a minute or so, to shout out anybody who’s helped you get where you are, Any colleagues, any friends, any mentors, books that you have read, podcasts that you listen to, anything that you want to do a shout out.

Mukund Sarma (51:45.374)
man, it’s going to take a whole 60 minutes and 60 seconds. think it’s going to be really hard. think a lot of what…

Raj Krishnamurthy (51:47.523)
Okay.

Mukund Sarma (51:55.328)
People say like, they’re self-made and all that kind of is, in my opinion, BS. I don’t think anyone is. It takes a whole village and a country to actually help you get to where you are. There’s so many people I wouldn’t. If I start naming, I’m sure I’ll miss someone, so I don’t want to start naming. I think.

It takes a lot and not just people in industry, your own personal family, everyone that is around you because they’re also trying to make it work for you for your career growth. I just think it’s, I don’t want to answer it with names because I’m sure I will miss someone, everyone, yeah, just a lot of people. I don’t think it’s easy to get to doing anything what you’re doing without a lot of help from the community and from your family.

Raj Krishnamurthy (52:33.787)
A lot of people,

Raj Krishnamurthy (52:43.217)
Got it. For somebody who’s trying to joint security, become the next Mukund, right? Become that security engineer at Credit Karma, become the CSO, right? Deputy CSO, CSO. What is your advice, right? And somebody who’s coming out of college fresh, what would be your advice? Where should they start? How should they pick up?

Mukund Sarma (53:06.623)
Stay curious, learn a lot. You’ll actually…

failed so many, many, many times, and that is also part of the learning. You may not understand it the first time you do it. There’s a lot that goes into trying it yourself that you learn more than just reading about it, talking to people about it. So I think a lot of people are hesitant to try things out. Like, go spend some time, try it out. You will not succeed in your first few times. That’s fine. You may succeed in a…

to a degree in the next few times, and that is also fine. And then you will also realize how hard it is to build anything that is something to build. But I think a lot of people just stop giving up to try going and trying new things and being adaptive to what’s happening. I think one thing I’ve always constantly heard people saying is like,

I’m just like all the time context switching and learning new technologies and doing things that sense. And I’m like, that’s unfortunately the reality of security and you got to like meet where there are people are and if your people are going and doing all those things, yes, you got to like go and learn all those aspects and work with and learn, like learn how to secure it. For example, I’ve gotten a lot of people telling me like, a data engineer only needs to learn the data engineering stack or a full stack engineer needs to only learn how to build.

an app, a back end, and talk to various APIs, we need to learn all of it together. And I’m like, yeah, you have to learn all of it together because you’re responsible for giving them that recommendation. So I talk to them and do the review. So it’s hard. It’s also.

Mukund Sarma (54:48.031)
Not expected that you 100 % know everything. You can always talk to people. Those people are willing to teach you. You don’t have to go back to reading the books and learning everything 100 % of time. Most of the time I just join most of the things and I’m like, I have no idea what you’re talking about. What does that do? try to map. As long as you have strong fundamentals, you can map it back to how you’re thinking. Back to the first principles part of things. So, yeah, just focus on the fundamentals. Be curious. Learn a lot is kind of what would say. That’s all.

Raj Krishnamurthy (55:14.095)
Love it, love it. I think that’s great advice. With that, Mukund, it was fascinating having you on the show. Thank you very much for joining us.

Mukund Sarma (55:21.203)
Yeah, thanks for having me.