Podcast Interview with Sam Satyanathan

Pratik Roychowdhury: Welcome back to ProdSec Decoded, the podcast where we deep dive into the world of product security and AI with the leaders who are shaping its future. I’m Pratik Roychowdhury.

Chiradeep Vittal: And I am Chiradeep Vittal. Today we have an absolutely incredible guest joining us, someone who’s been at the forefront of cybersecurity and product security for over two decades, and has a unique perspective that spans both financial services and the SaaS universe. Our guest today is Sam Satyanathan. Today, he’s head of product security at UKG, where he leads product, platform, data and AI security initiatives. But what makes Sam’s story particularly fascinating is his journey through some of the world’s most security conscious organizations.

Pratik Roychowdhury: Yes, we are talking about leadership roles in Capital One, the Federal Reserve, freddie Mac and major enterprises like Experian, and Toyota. Sam has literally been there, done that from building mobile banking security solutions to leading global DevSecOps operations. So, whether you are a security practitioner, a product leader wondering how to embed security into your product DNA, or just someone curious about where product security is heading, this conversation is for you.

Let’s jump in

Sam, welcome to ProdSec Decoded. You and I have somewhat common I would say career journeys, if you will. You started as a developer, so did I. We both have MBAs in finance and we both have been in the financial services industry, but also in the cybersecurity industry. But you obviously have had lot more experience in the cybersecurity space.

Sam Satyanathan: I don’t know about that.

Pratik Roychowdhury: You have been in an operational role. I’ve been on the vendor side a little bit, so absolutely thrilled to have you on the show, Sam.

Sam Satyanathan: Oh, thank you very much. Great to be here. Great to talk to you guys.

Pratik Roychowdhury: So speaking of journey, Sam your career journey has been quite fascinating. You’ve worked in financial institutions, Capital One, the Federal Reserve, and now you’re leading product security in UKG. I would love to start off with, what was that, call it pivotal moment or thing, that made you realize that cybersecurity is where you want to be, focus your expertise in? And obviously financial services is unique in that perspective because there are lots of things in cybersecurity that need to be taken care of in that industry. So how has that shaped your approach, the experience that you’ve had there, shaped your approach? Would love to hear that from you.

Sam Satyanathan: Like you said, background’s been software development. I just went right into that after finishing my grad school doing computer science. It was with a small software development company that was based out of the Bay Area. It was interesting because we did a lot of work with some of the financial companies that are out there. One of them was with an investment fund of funds type of company. It was very interesting work and that kind of got me more interested in finance. So even though it was not a financial type of software development company, that’s what kind of got me into it. Made wanna go back to school, get an MBA finance, which I did, and. thing I realized through my internship and subsequently was that I don’t really wanna be in finance. Technology is still more interesting. So I kind of stuck with that. I worked with, like you said, a few large financial companies out there - Bank of America that time Countrywide, Geico, Citi, Federal Reserve among others. When I landed at Capital One, I started on their financial services side of the house, but eventually got into what they called digital security. At that time that was more of identity and access management. That was their primary focus. Those were like the early days of AppSec. And I’m still connected to a few of my friends from those days. Some of whom have moved on to take on larger roles in other organizations. They were just starting out an AppSec program over there, starting to scan code and all of that. This is it’s around 2010-2011 timeframe. So that’s kind of what got me really interested in security. Interestingly enough, I had a sidetrack, I got into mobile payments, mobile wallet. So think about Google Wallet before the days of Apple Pay. So I worked in that space for about four years or so and got back into AppSec and, truly more focused on product security with Experian after that time.

I think one of the questions you asked was, , how does working in financial services, change your perspective on security in general. The thing about financial services for good or bad early on they had regulations around it. You hear about the PCI-DSS of the world. When you look at other industries which should be regulated, they’re not there yet. Healthcare is a good example of that. Coming from a technology, especially like a software type of background, a lot of times, one area that we don’t necessarily focus a whole lot on is GRC. So working in financial services, that was probably one of the greatest benefits in my opinion, because you get to work directly or indirectly with risk compliance. It can be a little bit of a pain, but you also get to understand their perspective a lot better.

Chiradeep Vittal: Yeah. And now we’ve heard many definitions of product security. Everyone seems to have their own interpretation but given that your current title is Head of Product Security, I think you’re the perfect person to tell us what it is and how would you define it. And walk us through what your day-to-day job looks like.

Sam Satyanathan: I think it depends on the type of industry you are in. How that particular business or organization works. I know a lot of companies where product security is seen as the same as AppSec, application security, or vice versa. In my mind it’s really all about the product itself.

And I think it changes from organization to organization. If you are a software company like mine where our product is really software as a service or the product is software itself, then you have to look at it in its entirety - not just the application code, but the platform that it runs on.

The infrastructure could be cloud, on-prem, hybrid, whatever the case might be, you have to look at it in its totality. For other companies, who might be in manufacturing or others, when you talk about product security, you’re not just looking at the software that might run on the hardware devices, but also the devices themselves.

You probably have to make sure that you are securing them through testing that you do on them from a security perspective. In practice though, I would say that it’s a continuous engagement with your engineering development teams, product teams.

So for us being in product security, it’s really about making sure that you can work closely with the product team itself - the product managers, product owners who actually have control over what get prioritized through their regular sprint process, where they might be having custom customer requests that are coming in as features that might take precedence over something that might be a security related concern.

So we have to work closely with them. But on the technical side, we also have to work closely with the engineering or development teams. In my role, I have security architecture, so most of the changes that might have any kind of security impact on the organization go through a security review process.

So it could be anything that comes from the product or engineering side or the corporate IT side, or even the customer facing technology organizations, ‘cause there are some work that’s done by those teams also in terms of technology change. So we get visibility across the board and we can also help them because we as a team are in the middle of defining a lot of the security policies.

My team does that. So, they have a better understanding of what they might need to do in the future if they don’t already. We can also enforce some of the policies that need to be in place. This is at a high level, but of course on top of that you have the standard, security testing, vulnerability management process. So on top of all of this, maybe one other thing that, and I’m assuming a lot of organizations have this too, when you are focussed on product security, you also get pulled into a lot of the customer related interactions. It could be your current customers or potential customers who may have specific security related questions. In our case UKG has had some breaches in the past, and this is public information. When we or the customer facing teams go and try to sell to some of these customers, they may have very specific questions about, “Hey, what have you done to improve your security posture since this happened 4 years ago”. So this is an opportunity for us to talk about all the work we’ve done to secure the product over time; work we are continuing to do to even improve that in the future. A lot of times it’s really great because you also get to talk to the security practitioners on their side, and it’s not just the people that our salespeople might be selling to. And so when their security people understand that better, it makes a big difference. We’ve seen that in multiple occasions. And similarly, we have changes we are making to the product where maybe we have issues that we want the customer to go prioritize and address, and then they might have clarifications with us.

So yeah, broadly this is day to day what it looks like.

Pratik Roychowdhury: Well, that actually covers the entire aspect of product security in a very comprehensive manner. And obviously because it is so broad, as you said, it starts from your product and goes to working with different people in the organizations, working with customers, especially if you’re a SaaS product.

So obviously it is very broad. And one of the things I’ve always kind of believed in is that when you have any project, in this case, a product security project, you have to be able to measure it in terms of metrics and KPIs. So in that context, let’s talk a bit about metrics. How do you actually measure the effectiveness and success of a product security program?

Talk about some of the metrics and KPIs that indicate whether a product security program is successful versus it’s just checking some boxes, so to speak.

Sam Satyanathan: Yeah, I don’t think this is very different from other organizations. Starting out with, if you think about security testing coverage, are you a hundred percent covered on your security testing of not just code, it could be infrastructure as code, or scanning your broader infrastructure, could be your on-prem environment or cloud. How much visibility do you have? So you complete that, then you are looking more closely at, the standard, , vulnerability management metrics ‘mean time to remediation’, ‘mean time to detect’ - things like that. How quickly are you identifying there is an issue. Let’s take the example of a zero day that comes out. How quickly are you able to detect that there is an impact to your organization? And then once you do, how quickly can you go about remediating that? But beyond that thinking about number of or percentage of critical, high vulnerabilities that get remediated within SLA.

This is a change in mindset, too, with your product teams or your engineering teams to make sure that they are actually prioritizing that work. You could also look at other metrics, like number of vulnerabilities per lines of code. And this might again, change in future because we are looking at more AI generated code and things like that, so this may not be written by a developer or an engineer. So there could be changes that we may have to take into account as we go about that in the future. One of the things that we have been focusing a lot on is secure development practices. We’ve been building out the security champions program and we’re trying to get to a certain point where we have certain ‘number of security champions per number of developers or engineers’. And making sure that we have threat model or architecture review for products, but new features that are coming out too, how consistent are we with that? And this is not always perfect. We have to make sure that we kind of stay on top of it.

And even something like security champions program, I think that is sometimes the biggest challenge because we have to work with the product engineering teams to help them understand why this is something that really helps them, is something that is a competence that they can build up within their organizations, and how they can be in charge of their own security related concerns without having to approach the product security team all the time. It’s an ongoing effort and a lot of times people don’t understand the level of effort that has to go into it because everybody talks about security champions program and I’ve built that at multiple organizations.

The challenge that I’ve almost always seen is that if you have key people who are actually owning it and really passionate about it and driving it, and they leave or they take a different role, it just falls flat. And so you have to put a lot of focus on that to make sure that it is successful and continues to be successful. One more thing I wanted to talk about was, look at compliance in terms of security frameworks. In the past I’ve looked at things like ASVS. It’s not necessarily very objective, but at least subjectively we can see where you are in, in terms of how you are performing as a product security organization.

Chiradeep Vittal: Yeah, I think you dropped the word AI there. And so that’s probably keeping up a lot of security leaders. But there’s so much hype around it and so much noise around it. Are we over-hyping AI security risks while ignoring that humans - like you said, security champions go away and suddenly the program falls flat - are they still the biggest security vulnerability? What is the actual scariest thing about AI security that nobody’s talking about?

Sam Satyanathan: I think you can’t turn left or right without hearing about AI and of course AI security these days. You asked about, , are we ignoring humans? I also wonder, are we ignoring AI itself as a potential security vulnerability in the future? It was not too long ago we heard about how Claude Opus 4 was trying to prevent it being replaced or shut down for self preservation. So you have to wonder, how AI maybe got a lot of the same challenges that we have with humans. So, too early to tell. But the point you are making, at this point, I don’t think we are there yet. And humans are still the biggest risk because I don’t think bulk of the issues in terms of breaches that you see would happen without humans being in the middle. It could be social engineering that we hear about. The other thing you were asked about scariest thing. One thing I’ve been telling my team and my colleagues is AI is being used to develop software or the products, in general. We are also becoming more dependent from the cybersecurity side of the house where we are creating AI based solutions to actually prevent some of the issues that we have been seeing, from happening. But on top of all of that, the bad actors also have access to AI. So that means we are having to work even harder. To me, I feel like we have more dimensions that we need to address. So our jobs are getting a little bit more complex, but how these would all shake out, it’s something that still to be seen. I don’t like to make predictions about these things because a lot of times that’s all they are. How the reality plays out is very different.

Chiradeep Vittal: Yeah, I mean, we have been in this space for about a year and every two months we have to revise our strategy, expectations, everything. So it’s just been nuts.

Sam Satyanathan: I know you talk to a lot of different people. What other interesting use cases, have you seen where AI could potentially be a bigger challenge or less of a challenge.

Chiradeep Vittal: I think one thing which is underappreciated is how quickly the bad guys are using agentic AI to increase the scale and the speed of attacks that they’re doing. And the second thing is the bad guys don’t have to be experts anymore. The AI can develop new hacks on the fly for them. And then I think vendors have to start scrambling to rethink some of the assumptions about how fast these things can move. Yeah.

Pratik Roychowdhury: I think the other thing that we’ve also heard is about vibe coding. When you do a lot of vibe coding, you introduce a lot of, issues within the code and the rate at which issues are being introduced in the code is so fast that how do you ensure that on the security side you can identify those at the same rate?

So that is definitely a scary thing. It’s good as well as bad. Yeah.

Sam Satyanathan: No, absolutely. I totally agree. I was recently reading something that mentioned the difference between vibe coding and AI- assisted engineering and I thought it was great. I can’t remember the author of that and I want to give that person credit for that because, , vibe coding is really good for your typical Replit type of solutions.

You can, quickly create some type of a prototype that you can see and how it works. But at the same time, if you wanna build something that is production ready, you probably need to depend more on AI assisted engineering or development as opposed to vibe coding. Great arguments from that person. This is something that I would like to emphasize with my organization too, because a lot of times, the vibe coding type of solutions come from the non-technical folks. So they start something out and then the maintenance of that then falls on someone else, which becomes a challenge for us too, from the security side of the house. So that’s a great topic.

Chiradeep Vittal: So here’s the controversial prediction we have been hearing around this. Some argue that the traditional security team might become obsolete within about, take a pick 5-10 years as AI takes over the security operations and decision making. What’s your take on that?

Sam Satyanathan: How can we do that without eliminating humans at every other level. Because security is not just security operations or one specific team within the organization. What we see now is there’s a lot of focus on AI-based solutions for security operations talk. But if you take that as a use case, that is only one small piece of what we do in cybersecurity for any organization. And it’s not just that. When I look at leaders in cybersecurity, they have to a lot of work interacting with other leaders within an organization helping them understand the true risk of something that’s coming up or the reasons for why we may need to invest in an area. So the day-to-day job, I can’t foresee in totality that being taken over by AI, at least not yet. Maybe, 20, 30 years from now or a 100 years from now, , we would all just be sitting at home and enjoying the work of AI all around us.

But I don’t see that happening anytime soon. If anything, I really feel like AI could help improve the way we do our work. Some of the maybe manual work that we do, very process heavy work could be taken by them. Not to say that it’s just typical automation work, but also things where checks are necessary. You probably have a set of things you need to check for every time. And as humans, , we may fail to do that, but like an AI could do that more effectively, freeing people up to do other things really improve that process itself over time. So I don’t believe that yet it’s gonna happen anytime soon. But hey, don’t quote me on that if that changes 10 years from now, and we are all resting on the beach.

Chiradeep Vittal: All of us could be at risk, so not just security.

Pratik Roychowdhury: But I think I’m with you on that, Sam. I think this argument, not just cybersecurity, I’ve heard it in multiple areas that AI is gonna replace humans. I’m sure Chiradeep is also in agreement. We feel that it’s a force multiplier. It’s just gonna help you do your job better, move on to less mundane things and on to more intelligent aspects of it.

So completely in agreement.

Sam Satyanathan: I will maybe pose another question there. Are humans willing to give up control to that extent yet or will they be in the future? Because I can’t foresee that, that will actually happen that way, where we give up all control and say, “Hey, yeah, take over and do all these things and we trust you”. But I think regulatory compliance could be one thing that prevents that from happening. Because even today we see that with some of the AI-specific violations that we are seeing and the repercussions of that. So it’ll be interesting to see how it evolves for sure.

Pratik Roychowdhury: Absolutely. And I think talking about organizational structures, one of the other things that we have been seeing is this evolution of the product security engineer. And so in that context, obviously you are head of product security, but there are some of the other roles that I’ve seen where there is a Chief Product Security Officer, if you will. So from that perspective how do you see the product security role evolving into a C-level role, so to speak, where for example, a chief product security officer could be a peer to a chief information security officer, or they could be maybe working very closely with each other, and they could be complementing each other.

What is your take on it? Do you see this evolution where there is a chief product security officer, which is absolutely needed?

Sam Satyanathan: I don’t know if it needs to be called Chief Product Security Officer or it could be something else. So right now I report to someone who is the Chief Security Officer at UKG. So his role is Chief Security Officer, not Chief Information Security Officer. And historically, I think the reason is also because for a lot of these roles, it was not just about the corporate security, but also physical security and things like that. But I can foresee that being a unified role for products, especially an organization like ours, where we have a software product and that the product engineering team, without doubt, makes the larger piece of our organization as a whole. I’ve seen other companies where they have a Chief Information Security Officer as well as a Chief Product Security Officer. I won’t name names - at least a handful of ‘em that I know. And I know people who have been the Chief Product Security Officer role. So for me, I kind of feel like you probably need someone with a unique skillset in that role, especially the level of involvement you have with the development, engineering side of the house or the product side of the house. For example, I’ve done hands-on development, architecture, software development lifecycle using waterfall, agile you name it. So when I talk to people on that side of the house, I can understand them well and I don’t need to relearn those things or go back and think about those. It comes to me automatically and that’s really an advantage. Lot of times people who come into application security or product security who don’t have that background sometimes have a little bit of that challenge.

I’ve seen people who come from GRC background, and they do have a little bit of a challenge in working with them just as closely as people who come from this background. So, back to the point of leadership role. Sometimes you also need to be the voice of security to the customers as we were talking about earlier. And I know that a lot of companies have something like a Field CISO type of role these days. So this is where I feel like there is definitely a value in having a role like that. So I can definitely see that as a possibility in the future, as there’s more and more focus on product and product security.

Chiradeep Vittal: Yeah, I think the people part of the business is always fascinating. But let’s talk about what’s happening on the ground. After all your years in the space what’s the biggest mistake or mistakes that you see companies keep making in product security? Those things like, “how are we still doing this in 2025”?

Sam Satyanathan: You mean in product security specifically?

Chiradeep Vittal: Yeah in product security. Yeah.

Sam Satyanathan: I feel many organizations still look at product security as just AppSec or, just vulnerability management and basically just organize around that, while some of the other critical pieces of that are kind of fragmented across multiple teams. I’m not saying that something like product security operations necessarily have to be part of security. Because you may be at an organization where, you may have a cyber fusion center or something that brings all of that information together. So there’s definitely value in keeping that together and you, you get all that telemetry that you can get through there.

But just thinking about product security as one piece or the other, makes it hard when you are trying to address that together, to somebody on the outside. And I’ve seen that happen, not just here in some of my past organizations too. So you have to go to different groups within your cybersecurity function to get the answers you need.

Whereas if you have it all as part of the same organization, it’s a little bit easier. It also depends on how well leaders within the cyber security organization work together. And if it is not a cooperative - collaborative relationship, it could get challenging too.

Pratik Roychowdhury: Speaking about mistakes one of the things that I’ve seen a lot of people make, not just in cybersecurity, in probably every role is not getting the right talent, not getting the right folks in the right roles. So in that context, you have obviously built large teams. How do you spot the right talent when it comes to product security? What are some of the obvious or even non-obvious things that makes you go, “Hey, this person is right for product security”, because I’m sure it’s not just pedigree or certifications. It’s a lot more than that.

So how do you spot talent?

Sam Satyanathan: There are a bunch of things that I think about, and I think my team’s on the same page on this too. And we try to hire people, and this is in no particular order.

One of them is going to be true deep hands-on technical knowledge. You have to be technically knowledgeable in this role to talk to the people that they might be working with on a regular basis. So it’s not enough that they can come and give us definitions of the OWASP top 10, but if you are in a real situation dealing with that how would they actually address that? They have to talk about it from their actual experience.

Another thing would be ability to work with the development engineering teams. This is going to be critical. Because day-to-day that’s probably going to be the bulk of their work. So it’s not just about working with them, but also being patient, to listen to them, understand the challenges, be curious, ask questions, really dig deep. And so making sure that it’s not just about telling people you can do something one way or the other, but also working with them to figure out how things can get done. And I think a lot of times this is a thing that is sorely lacking when you look around and talk to people. And it’s also hard to figure out in a 30 minute interview. So, generally, I prefer having multiple rounds of interviews, so we can also not just make sure that they are able to do all those things, but ascertain that everybody else who spoke to them also agrees on that. Broadly this is what we would look for.

Pratik Roychowdhury: I think that is really valuable for anyone who is either looking to join a product security team or to build a team. Alright, Sam, so now we have an exciting, rapid fire round coming up for you. But before we jump into that, I know you would not like to make predictions, but I would still ask you to make just one prediction on product security or even cybersecurity in general. A bold call that will make you look like a complete genius or completely wrong in five years.

Sam Satyanathan: I don’t know. Do you think AI could make real time updates to threat model a reality? I don’t know.

Pratik Roychowdhury: We, we’ll take that.

Sam Satyanathan: It could possibly do that. But one thing I think is organizations that will actually figure out how to use AI to their advantage could definitely leapfrog over others in improving the security posture. What you see today is a lot of companies rolling out a lot of agents or just they have an agent marketplace or something like that. It’s gonna be really about figuring out how AI can help truly reduce potential risks and threats. It’d be good to see how that evolves too.

Pratik Roychowdhury: Absolutely. It’s hard to predict anything in today’s world, but yeah, we’ll take that as a prediction.

Chiradeep Vittal: All right, let’s jump into the exciting rapid fire round. So just gut reactions, quick takes, no overthinking. Ready to go.

Sam Satyanathan: let’s go.

Chiradeep Vittal: Okay. First up, CISOs reporting to engineering instead of the CEO. Revolutionary or ridiculous?

Sam Satyanathan: To engineering rather than the CEO?

Chiradeep Vittal: Yeah.

Sam Satyanathan: No, I don’t think that’s a good idea. I think CEO is better if it is a choice between the two because it definitely helps resolve the conflict of interest. If you are reporting to the engineering leader, as a CISO, and they are prioritizing what may or may not happen where they probably have a bigger stake on the engineering side, that could be a problem.

Chiradeep Vittal: Right. Here’s the juicy one. If security leaders cut their security tools budget by 50%. Nobody would notice.

Sam Satyanathan: I think it is true in most organizations because most companies I’ve been at, I think that the problem is you have way too many tools and vendors, and you’re in most cases not even using 50% of the capabilities that the tools provide.

Chiradeep Vittal: Okay, that’s a good one. Compliance framework, SOC 2, ISO 27001, they’re making products less secure by creating a checkbox mentality.

Sam Satyanathan: I don’t necessarily agree. I would say for many of the process heavy organizations say financial companies, which is my background, this is still a good thing, because without them, I feel they may not necessarily be as good at getting those things done. Here at least it’ll get prioritized. For the rest of us, we could always still try to do the right thing and do better than the bare minimum. The good thing with these frameworks is that they also give you a checklist, in case you miss something. So if you are doing it without that, then there’s a good possibility you could miss something and somebody has thought about these things and has a comprehensive list of things that you should be looking at.

Chiradeep Vittal: Yeah, that makes sense. The Chief Product Security Officer role will be mandatory by 2030. Yes or no.

Sam Satyanathan: I would say yes, but I would like to see that happen because I think that’ll make a big difference for organizations that have a lot of focus on products.

Chiradeep Vittal: Okay. And last one, what is a must have go-to resource for a security leader or maybe any leader could be a book, blog, podcast. What do you recommend?

Sam Satyanathan: So for me personally, I’m part of some of these Slack groups ISLF is one of them. Really great forum, where you get to discuss security related topics and people also update on new things that they’re seeing out there. There are a few podcasts that I listen to. Application Security Weekly is a good one that I’ve listened to for a while. There’s another one that I come across. CISO Tradecraft is a good one. There are some WhatsApp groups that I’m a part of too where they share a lot of great information. We sometimes have offline zoom meetings to talk about topics.

I think there’s a lot of content out there. It’s really being able to weed out what you don’t need to read, and then making sure that you stay up to date on other things. But as a security leader, a lot of times you got to do both. If there’s a new vulnerability that came up, you need to know about the impact of that to industry at large, or your organization.

But at the same time, also stay on top of things, especially with AI and AI related stuff. How do you secure MCP server - t opics like that - you got to make sure that you are keeping yourself updated. And you have to actually have natural curiosity to learn and stay on top of things too, not because your job expects you to.

Chiradeep Vittal: Excellent recommendations. We’ll add these to the show notes. Sam, this has been an incredible conversation.

Sam Satyanathan: Thank you guys. Really appreciate it.

Pratik Roychowdhury: Yeah. Thank you, Sam, for joining us on Project Decoded. Lots of key takeaways and insights that our listeners will love to listen to.

And to our listeners, thank you for tuning into ProdSec Decoded. If you enjoyed this episode, make sure to subscribe and leave us a review. We’ll be back with another deep dive into the world of product security and AI.

Until then, keep shipping products and stay secure.