Securing Software Supply Chains with DevSecOps – Ramanathan Srikumar, Mphasis,

This is Textron tv. Hey guys, thanks for the throw. We're here with Ramathan Shri Kumar, who is Chief Solutions Officers for Emphasis, and we're talking about SecOps and the challenges that go with that.

And for that matter, why you should even bother doing it because, well, it does have some downstream benefits. Your customers care a lot about. Sri, welcome to show.

Thank you, Mike. Happy to be here. We have heard about SecOps now for several years, and everybody kind of nods their head and says, you know, yes, this sounds like something we should do, but there's a big gulf between the nodding of the heads and the actual doing.

So you guys have been down the path. What were some of the challenges that you encountered and how did you overcome 'em? So, Mike, we, uh, just to give you an introduction, uh, I am Chief Solutions Officer at s So Emphasis is the company which provides, uh, IT services to enterprise customers.

So we work with a number of customers, uh, many of them in the banking, uh, financial services, uh, and also healthcare and TRA travel and transport and high tech and so on. Uh, and you're right there, there, SecOps and DevOps has been talk, talked about a lot. I think when people talked about DevOps, they were basically focusing on the fact of just releasing the software, right?

Uh, what we think about it when we talk about DevOps, or we call it value stream optimization, which is thinking about the whole spectrum of, uh, conceiving an idea to ultimate execution because to the business, that's really what matters, right? At the end of the day, how fast can you get your ideas across and into, into your product? Um, so yes, uh, SecOps is very much a part of that, um, automation process.

And the challenges that we've encountered is the, the confusing, confusing array of tool sets that are available. Uh, especially when you're working with multiple customers. Uh, each of them have their own preferences of tools that they've selected.

And, um, and therefore, uh, from a, from a service provider perspective, it's important for our teams to be on top of all the various different kinds of tools that are available. The second thing is that, um, it, it is not just a technology solution. It is a, it is a change in the way you do things.

And, and it involves people, it involves process. And, uh, that's, that's the second challenge that we face. Even though you may get all the technology right, how do you streamline the process so that, uh, people are, uh, you know, using them to their benefit?

And it really shows in the metrics that you are measuring. That is what I said, which is consuming an idea to actually getting it into production. Now, there's a lot of, um, debate about this whole subject in terms of how far left you might want to shift SecOps.

And some people say, you know, it needs to go all the way out to the developers. And others say, well, the developers aren't that interested, and they want somebody else to take care of it for 'em. So I think maybe the answer to that question might be both, but what's your take on what's going on out there and just how far left are we shifting?

No, I think it is important to shift left because a lot of the security, um, things that you think about has to be thought of, right? The, at the development stage, because it's not something that you add on at the end of the end of the day. Uh, but what we have seen is a lot of, uh, uh, the security, uh, dos and don'ts can be set up in the, in the environment so that it becomes standard.

Any program, any developer is, uh, is actually inheriting some of those good habits from the, uh, from the environment rather than thinking about it himself. So yes, I would say shift shifting left is important, uh, important for developers to be aware and made, uh, things made available to them so that they can adopt it easily, uh, at the development stage itself. Uh, but I think one of the constraints that we, uh, that we have seen in organization is, uh, the whole QA process.

You know, at the end of the, uh, development there is, there is the testing process, which, which really, um, kind of slows the, slows this whole value stream down. So that's another initiative that we think, uh, you know, shifting from the thought process of QA to actually quality engineering that is shifting left in the sense of quality as well, uh, helps in speeding up, uh, your, your, uh, conception to execution value stream. Do you think that at the end of the day, security becomes part of the quality assurance process then?

Or is it always gonna be kind of its own separate motion? It is going to be very integrated. It's not gonna be separate.

Uh, it is not possible to separate security away from development, because a lot of what we do today is, you know, you, you, and with all the new things that are coming up with the generative AI and you know, the need to go out of your environment to do some of these things, security becomes highly important. And it is not just part, part of qa. A QA is just a final checklist to make sure that all things are followed, but it needs to be incorporated right at the time of design and architecture.

What will be the role of the cybersecurity teams in all of this? Cuz we are shifting more things left, but, um, where do they fit in this process? No, I think if you think about cybersecurity, um, there is the peripheral, the, the, the defense, uh, security that you have to do.

There is a lot of, uh, monitoring and, uh, environmental stuff that you have to do. But cybersecurity needs to give the right tools to the developers and the right, uh, uh, you know, framework to the developers so that it is integral to what you do as a software developer and not just an afterthought. Will this get more automated as we go along?

I mean, you mentioned generative ai, but it seems to me like there's all kinds of AI that we could throw at this process, but is that feasible or is it still wishful thinking? It is very much feasible and it, uh, as you can, as we see more developments coming in, in, we even in the last, uh, six months to a year, we have seen a whole lot of changes, right? Uh, if you think about, uh, how you can, um, you can use copilot or, or code or, uh, whisper from Amazon or whatever it is, uh, they are able to provide you with libraries and, and, uh, structures that developers can use, right?

So it becomes almost easier for cyber cybersecurity teams to, uh, make sure that developers follow these because you use these artificial intelligence tools to actually give you that framework, you know, in, into which you do your special thing to make the, make the software. Where does, uh, an integrator fit in that equation? I mean, are people coming to you and building these applications for them?

Or are they coming to you and say, help us figure out how to make our own software supply chain more secure? Both, uh, Mike, if you ask, uh, if you see the way we do have a value stream optimization, uh, tribe within our, uh, solutions teams, which looks at all the things that are happening in the value stream in terms of both DevOps, SecOps, et cetera, and bringing them in into the and, and the QA to QE process that I mentioned to you. Uh, these are things that we do with our customers.

We, we give them the services to say, okay, we'll come and help you streamline your value stream. We'll help you set up the DevOps, uh, chain, uh, will help you configure the tools. That's one thing that we do.

We also do application development for them and transformation for them. And in that process we also bring in some of these best practices into the customer's environment and including our own, uh, teams using it. What's that one thing you see organizations doing over and over again that kind of say, you know, makes you shake your head a little bit and just say, I think we could be better at this than we currently are?

I think, uh, the main thing, as I mentioned is the process. Thinking about it as a, as a process problem and not just as a technology problem. I think a lot of them, when when the moment you think about DevOps, you think about tools, you think about how do I, uh, do CI/CD?

Yes, that's important, but a lot more thought has to go to, to the whole overall process. Uh, and, and the training of the people. Uh, I think that's, that's something that we always miss.

Uh, it seems to be history repeating itself multiple times when, uh, when you go to a organization and you see, okay, they've done C, s, D, but you know, the, it's like the watermelon. Everything is green, but when you cut it, it's all red, right? So I'm not really getting, I'm not getting what I wanted, uh, by implementing this.

And then it becomes a process and people problem rather than just a technology problem. And some of this has to do with how deeply they may have, um, embraced DevOps as it is, right? Not every organization is as far down the path.

Some are very, uh, CI centered and very few are CD centered. So is this security conversation gonna force a general maturation of DevOps processes across the board? Because people are gonna have to figure this out on a more end-to-end basis?

Yes. I, I think you're right. Uh, it, it is giving thought to everyone.

They, they do want to make it more end-to-end. Uh, but I, I'm not sure it's just the security. It is, it is the, uh, you know, the, the whole reliability, the scalability, all of those is making them think end to end, right?

Uh, and it's not just the DORA metrics or the what, what we call the velocity and stability metrics that you typically measure, but it's also lead indicators. You know, the amount of tech debt that you have in your environment, uh, the, uh, test coverage, uh, levels that you have, um, the length of the queues that you have, the wait times that you have. So all of those come into picture to look at it holistically.

Mm-hmm. Um, as you kind of look at that holistically, who else is kind of getting involved in this conversation? Cuz you mentioned value stream and it seems to me like there's a whole group of folks that are stakeholders outside of the DevOps process that are trying to gain some more visibility.

So what are you seeing there? So, um, we, we, we've all been talking about agile and how to develop software faster for a very, very long time. And I, I've been in this industry to see multiple cycles of it coming.

Um, it in it, if you ask me, it involves all the stakeholders right from the business onto, uh, the final deployment teams, right? Because, uh, if, if just an agile process at it is not gonna help, it needs to have involvement from business. And if, if business doesn't understand that, and if it doesn't, um, appreciate the changes that they have to make for themselves in terms of how they work with, uh, the, the Scrum teams to actually bring the storylines and how do they, uh, you know, prioritize it for them.

Um, so, so I would say the stakeholders has expanded quite, quite a bit, uh, from, uh, from what we used to think of previously. Alright. On the security front, if we're just kind of getting to the realization now that we need to improve those workflows to right, higher quality, secure software faster, what does that say for all the software we have deployed?

I mean, do we have a bunch of security technical debt out there that we're kind of ignoring and we gotta go revisit? Or what's your sense of just how big is this problem? I I do think there is, uh, there are issues, especially as you more and more go towards the cloud and you, you are, you know, earlier it was very easy for you to just fence it off.

So your security problem was just periphery, and as long as you've got the periphery, you are fine. But that has become extremely porous. So yes, if you look at some of the, uh, you know, old code that exists in the organizations, it requires a revisit.

It requires some more, uh, you know, uh, re-architecting, in fact some, in some cases to, uh, to fix this. Uh, so TechNet is, is a, is a serious concern, but it is not something you can solve by, um, just, you know, throwing all the code out and changing it, right? So we, we, uh, we have a methodology called front to back, which we say, look at it from what KPI you want to influence for your stakeholder, and then work backwards to see what you need to fix, right?

Um, so, so that gives a little bit of, uh, a methodology for you to go and reduce your, uh, technology debt and steps rather than trying to do everything at once, because that's just, I mean, we have seen too many projects which, uh, went about, uh, you know, went into a lot of ex extended timelines and extended budgets when you think about it that way. So this methodology of looking at what is the change I want to make and therefore work backwards to see what do I need to fix in the environment, of course, with the overall picture of what my future target architecture is gonna look like, uh, is the best way in, in my opinion. We also see a lot of folks are starting to build so-called cloud native applications using microservices, containers, serverless frameworks, and all kinds of new and interesting stuff.

Are those applications in your mind more secure than legacy applications? Or are they just insecure in a different kind of way? I do think they're more secure only because you, uh, able to put a lot more, um, uh, I would say guidelines and frameworks built into the process.

So you, so every time somebody's coding, they're already inheriting a lot of the security that you're built in. So, uh, so in that sense it's a lot more, uh, secure than before. And also when you, when you are doing, um, uh, cloud native applications, you are using a lot of the stuff that the cloud providers are providing, and the cloud providers, uh, have always thought about security bottom up right from the beginning to say, if I don't do that, I'm gonna be exposed.

So I think, uh, adopting some of those is definitely more secure. Are we gonna see a new era of application security as a result of all this? I mean, I would say it's kind of been the redheaded stepchild of security all these years because the developers thought the security people were working on and the security people thought the developers were working on it, so then nobody was working on anything.

Um, but, you know, are we gonna have a, a new appreciation for application security? I think the new appreciation is, is not new. It's been around for a long time.

We've had so many, uh, you know, uh, public cases of failures, security failures that have come. So I think every cio, every board in fact is asking questions in terms of security. The more we move, uh, more we move to, uh, open up our applications to, to our customers, our customers customers.

In fact, uh, the more they are worried about security. So security is something that is in top of mind for most, uh, CIOs and even CEOs and uh, and uh, and the board self. So I think there is a lot more emphasis on, on, uh, security as we go, uh, as we are maturing in this, in this field.

There are of course a lot of system integrators out there. So in your mind, what differentiates one from another? What should people be looking for when they consider who they're gonna partner with?

I think, uh, you know, the role of the system integrator has also changed, uh, dramatically because if you think about, uh, maybe 10 years or even 15 years ago, it was more of, I give you this, you go build it for me and bring it to me, or this is my scope of the project, come and do it right? Today it is a lot more collaborative, it's a lot more, uh, uh, uh, joint teams of, uh, service providers and, uh, and, uh, um, our own, I mean our customers own people working together to, to, uh, make things happen. So I would say that pick, uh, when you look for system integrators, you wanna look for people who are culturally fit into your organization, uh, who are responsive and who are able to collaborate with, uh, other vendors because it's always a multi-vendor environment that exists today.

Alright. As you kind of think about it, what is your best advice to folks then, as you kinda look at this whole SecOps landscape, and it seems like there's more complexity and there's more things that can change and it's a little overwhelming. So how should people think about wrapping their arms around it?

Um, call me is one answer, but I think, uh, the, on a more serious note, uh, I, I think while the, while the environment is getting more difficult, there is also a lot more, uh, you know, things which have matured, uh, and therefore making it easier for you to manage some of these. So I would say, uh, the main thing, focus on the overall process. Uh, just don't, just don't focus on tool selection or tool.

Tool is just a means of getting it. You want to look at the end-to-end process and see, uh, how you wanna change it, uh, rather than just, you know, buying technology for the sake of buying technology. All right.

Hey Rin, thanks for being on the show. Thank you man. Good talking to you.

And back to you guys in the studio.