Autonomous Identity Governance With Paul Querna

Speaker A: I'm purposely being provocative. I thought multi factor authentication was supposed to solve all this. Isn't that supposed to solve authentication, authorization?

Speaker B: I mean, there's a thing here, and you kind of said the right words. Is authentication, uh, proving that you are, and then authorization. Right. And what's tricky is, you know, more and more authentication itself is getting pretty good if you, like, care about it and you might make the right investments. Right. So passkeys on the consumer side, kind of web outlaying, yubikeys, hardware tokens more on the more enterprise side. And even like TLS 1, 2, like the encryption layers are better than they were. The authentication tokens are more secure than they ever were. Um, so authentication itself is becoming like, both commoditized and relatively speaking, solved. Ish, if you're willing to make certain investments. But that leads you to the. Well, if you're an attacker, what do you do now? Like, oh, I can't steal someone's password in an enterprise context like you could 10 years ago or 15 years ago.

Speaker C: You are listening to the Secure Developer, where we speak to industry leads and experts about the past, present and future of DevSecOps and AI security. We aim to help you bring developers and security together to build secure applications while moving fast and having fun. This podcast is brought to you by Snyk. Snyk's developer security platform helps developers build secure applications without slowing down. Snyk makes it easy to find and fix vulnerabilities in code, open source dependencies, containers and infrastructure as code, all while providing actionable security insights and administration capabilities. To learn more, visit Snyk IO tsd.

Speaker A: Hello and welcome to another edition of the Secure Developer. I am your host, Danny Allen and I am super excited to be here today with Paul Cuerna from Conductor One. Now, Paul has been in the identity space for a long time, the security space. I think he has some background at Okta. But Paul, maybe you want to introduce yourself for the audience.

Speaker B: Sure. Thanks, Danny. Uh, yeah, Paul Korna, cto, uh, at Conductor One, one of the co founders and you know I started out, I'll call like in like infrastructure development and things underneath the cloud and building cloud services and then saw a lot of data breaches that uh, were, uh, not awesome, saw a lot of security issues that were not awesome and eventually um, founded a, uh, cybersecurity company in Zero trust space that was later acquired by Okta and then started uh, Conductor One a couple years ago. Now, uh, as kind of my second at bat at building a security company,

Speaker A: would you recommend starting a company. This is your second one. I'm just curious what your recommendation is for the audience.

Speaker B: Not everyone should do it, but I think it's one of the best jobs in the world. Like if you're excited by it and if you gain, you have to gain energy from the ambiguity, the chaos, the learning. But I love it, you know, and every day is different. You're always learning something new and if that energizes you.

Speaker A: Yeah.

Speaker B: Think about it, you know, explore what it would take.

Speaker A: Yeah, it's uh, it's a lot of work and I've never done it actually. Interestingly, I've been in similar role but never a founder and I know how much energy goes into that. What led you to identity and I'm going to group identity and access management together. I know authentication and authorization are different, but what led you to this industry? Were you always interested in it or just fell into it?

Speaker B: I mean I was always interested in I think like security just from a. I want to make secure products and software. You know, like I was, I was always into infrastructure and kind of things underneath systems and security is an element there. But it was never like my job per se originally. Um, but it was seeing these security incidents and like um, it actually led to identity very quickly. It's like I grew up in an era of like firewalls. Like we're going to use source IP address as the mechanism of trust a network. And uh, you're like well what if someone comes from the same, you know, from your work. Uh, you know, if you have an office and people log in, plug into an ethernet port, should they have access to production now? Right. Like it was wild that, that was like our threat model that like this physical world where if you plug into a port you have access to production data. Right. Like so that's where I started. My starting point was like oh wow, these firewalls are wild and we buy more of them and they don't work. And then we uh. Everyone has VPNs now and you can log in from anywhere in the world. Like that's that who network layer is like just broken to me from a security perspective. And so that's kind of got me into well what's the better solution? It is like identity who you are, what device you have is the like right way to build attestation to make authorization decisions versus the network based authorization decision. So quickly that, that kind of, you know, 2015 era. I started a company in that space, Zero Trust Space because that was the inspiration Was like, these network firewalls are the wrong way. You need a test of someone's identity to make authorization decisions. So I kind of got into identity via trying to solve security problems.

Speaker A: Yeah. And I very familiar with those issues. I remember back in the 90s I used to do pen testing and literally you go plug into the Banyan Vines network and uh, there was no authentication. You were already on the network, you had access to everything. I thought I'm purposely being provocative. I thought multi factor authentication was supposed to solve all this. Isn't that supposed to solve authentication authorization?

Speaker B: I mean there's a thing here and you kind of said the right words. Is authentication, uh, proving what you are and then authorization. Right. And what's tricky is, you know, more and more authentication itself is getting pretty good if you like care about it and you make the right investments. Right. So pass keys on the consumer side kind of web application yubikeys, hardware tokens, more on the more enterprise side and even like TLS 1, 2, like the encryption layers are better than they were. The authentication tokens are more secure than they ever were. Um, so authentication itself is becoming like both commoditized and relatively speaking solved. Ish. If you're willing to make certain investments. But that leads you to the, well, if you're an attacker, what do you do now? Like, oh, I can't steal someone's password in an enterprise context. Like you could 10 years ago or 15 years ago. So then you try to go move to, well, I'm going to steal their session, I'm going to let them log in with their hardware mfa, and then I'm going to steal their Chrome session and go do use some app, um, uh, as if I was that person. And so that leads you very quickly to kind of authorization, which is, you know, what are you allowed to do given your identity? And I think one of the underplayed things, if you look back to the original like zero trust movement and what people are trying to do there, one of the pillars was, was actually like least privilege. Like you should have the lowest privilege. You need to do your job today and not more. And that, you know, that kind of, I think is lost out generationally. Like we fix a lot of the authentication stuff, but the authorization stuff is still like you get hired, you get access to everything in the company. On day one or you know, week one, you get access to all kinds of stuff. And the reality is most time your job isn't doing all those things. You know, that standing privilege, uh, is also what attackers go after now. So, you know, there's Verizon data breach report, all kinds of, you know, industry evidence you could point to that says you really like, you steal someone's identity, basically you log in as them, they look like an insider threat, like, which is a whole different, you know, I think, um, a lot of B2B sasses and kind of enterprise companies don't think about insider threat that much. It's more thought of the financial systems problem, like, oh, we don't want someone to fraud us and steal some money. But, like, that's changed a lot now. I think it'll continue to change the next decade where insider threat is not just a model of someone trying to commit fraud and steal from the company, it's also how the attackers are going to appear to you more and more.

Speaker A: Yeah. One of the interesting things is, uh, if you track, for example, you mentioned the Verizon data breach investigations report, there may be fewer internal breaches, but they're far more damaging because of the authorization that the individual has within the organization. And that becomes even more true in the age of AI where everything's pooled into central repositories. And they can get access to this.

Speaker B: Yeah, yeah. I mean, it's wild to think about. We're using coding agents or agents that help you write emails. And you think about it, in an enterprise, you know, I log in to my idp, I might have hundreds of internal applications, right? Like everything from a Salesforce to a GitHub to my internal support portal to, you know, your, uh, spell spelling correction app, like everything in between, from, like highly sensitive apps to less sensitive apps. And when I log in with sso, I have access to all those. And so if I'm writing an email, should my agent have access to all my data as me? You think about like these personal productivity agents, it's scary. They shouldn't necessarily have access to all your data, right? Like the proverbial, um, Coca Cola secret recipe locked away in a deep vault of a database or something. I might need that for part of my job that I need an AI agent to help me with. But when I'm logged in writing emails at 10am on a Monday morning, I probably don't need all that data. I probably need a subset of who I am. And I think this is one of the challenges of the AI space. We don't even have the terminology to describe sub users or shards of my own identity, where an AI that lives for an hour or five minutes help me draft email, what should it have access to you know, at the same time I don't want a productivity barrier. Right. Like if I am writing an email about my secret Coca Cola uh, uh, recipe, like I may want it to cite data from that. Right. And, and we don't even have the terminology to describe like the ephemerality of, of that kind of authorization.

Speaker A: Uh, and even before we get to AI and let's talk about that ephemerality of authorization. Is it possible, is it practical to do just in time authorization for the majority of actions that an individual takes, like for what you would do on a daily basis.

Speaker B: I think there's a like crawl walk run here. We think about like from a corporate security or production security perspective. You know, I think you know, a decade ago people said hey, I'm going to at least build a role based access control ecosystem in my company. And it's going to say look, if you have uh, this job code or you work for this manager or you have these certain attributes, we're going to provision access to all these things. When you get hired or if you work on a specific project, it's very like carte blanche frankly and tends to be more like birthright access. And you know, you could move to a more dynamic access control mechanism which uh, I think kind of like stage two of a company is like oh well I don't need access to everything all the time. So you think about even a uh, developer OR uh, SRE DevOps. You know, you don't actually need like God mode in AWS all the time. Like I mean like be realistic. Most of the time you know you're gonna log in and look at a cloudwatch graph or you know, or maybe click a button during an incident. But like that's few and far between. Partly because on the, you know there's so much terraform and infrastructure's code and like a lot of the world's evolved around that. So. But in an incident you do might need to be able to press a button very quickly, right?

Speaker A: Yep.

Speaker B: So there's a thing here where we see people doing things like when you're on call you get elevated privileges, but when you're not on call you don't. Or if there's an incident, there's a super easy way to escalate privileges and then they go away at the end of the incident and that's kind of a dynamic access control which I think you know, you think about access, you know, the things you have access to in a lot of companies turns into like a uh, up into the right Graph where like the things you have access to only grows. There's a guy he's working with named Jay. He'd been in the company for like 10 years. He started in support, uh, moved to be like an SRE DevOps for a while. Later moved to be a full software engineer. Uh, he had access to everything over a decade because he worked in different teams, different projects. So his roles kept accumulating. So he had a upward and the right graph of privileges in the company. And like I think the mental model for kind of a stage two, you know, uh, maturity curve here is like you need to move to more of a camel where like you have some baseline privileges. Everyone gets email. You know, like email is an essential service for your business. But like privilege things are up and down. You have them for a use case and then they go away. And that kind of, you know, leads you to, you know, standing privilege is actually risk. If you talk about like time your cso, the more things you have access to is like risk under a curve. And you know, from a CSO perspective you want to minimize risk. So kind of you think about what is least privilege actually getting you. It's lower standing risk. So if any given uh, identity is compromising your business, they can do less. Which I think gets to a little bit. You mentioned the Verizon data breach report is like some of these impact, these breaches are really impactful. It's like the crown of jewels. It's everything. Um, so I think that's like the mental model you start moving to is like, well, how do I move to more dynamic access control?

Speaker A: So are you expecting that AI would control that authorization? And if the answer to that is yes? Because I don't know what you're going to say. If the answer to that is yes, are we ready for that model where AI is able to make that governance decision? Like culturally, are we ready? Technically I presume we are. But culturally are we ready for it?

Speaker B: Well, uh, that's a great question. I mean I think the, like, it's necessary. Maybe it's the first statement when you think about, you can use this email example. But like, you know, I'm writing an email. If everyone remembers the old school, like Windows user access control pop ups, like, do you want to let this thing access your thing? Like the model dialogue, it drove me crazy. The model dialogue that prompted for permissions. It's like, I think we've proven that as a bad user experience.

Speaker C: Right? And we'll not.

Speaker B: But I do think, you know, an AI model that can evaluate, hey, this, you're writing an email. The two line is only internal people. I'm going to allow access to internal Salesforce data because you're writing, emailing, trying to pull stats on, you know, some customer or something. Right. Like that kind of in context. Access management I think is kind of inevitable. And so, and it's going to be driven by user experience as well.

Speaker C: Right.

Speaker B: Like you can't have things that break the user experience where it takes you know, two weeks to approve an AI identity agent to have ephemeral access to a piece of data. So I think out of necessity, from a user experience point of view and a speed of business point of view, you will have AI making AI decisions. Now culturally, are we ready for that? Like not at all. It's like going to be a major challenge I think in the next couple years. Um, but I think the reality is it's kind of like the self driving cars as an analogy. You know, they have at this point lower crash rates than human drivers. And I think for access control you can pretty quickly show very similar outcomes where the AI doesn't really make mistakes, just like a uh, for the most part, you know, autonomous drivers don't make the big mistakes. And if there's a case where they can't handle it, the flow is you eject out, you're like hey, I need your help. And you think about the concept of access control, it's like 99.99% of the time we can understand the context of what's going on. Understand should you have access to something and make a very quick decision. And if we don't, we escape out like hey, we need users help or we need your manager approved, whatever the kind of exception policy might be. So I think that's a good mental model of the trust building over time. But it's still going to be gradual. Especially if you think about like the compliance side of this, the uh, auditor side of this. I think you'll have a lot of like dual mode things where the AI makes recommendations but you have to kind of wait for the auditors to catch up. Like oh yeah, they're right all the time. But that's just like trust.

Speaker A: Yeah. And where does the accountability lie in that? Because I can see kind of one of three things pushing this. You could push it through regulation like pci, DSS pushed security standards into the payment card industry. Right. You could have insurance regulation saying if you want to get insurance then you got to do this. Or you could have just experience pushing this.

Speaker B: Yeah.

Speaker A: Regardless of the model. Where does the accountability lie? Is it whoever implemented the AI or is it the algorithm?

Speaker B: And that's the other thing and it is risky here. Like authorization is generally I would call like a binary decision. It's a true or false at the end of the day. Like do you, did you get the thing you wanted access to which is different than you know, summarizing an email? Like did you forget a good period at the end of sentence? Like that's a, that's a spectrum of outcomes. You can kind of grade them. So yes, there's a thing here where like the outcome is a yes, no and then who takes responsibility for that yes, no. You know, I think there will be, there are already more and more regulations in compliance side of this, encouraging least privilege. And then I think that's going to drive, well we need a least privilege, uh, compliance mechanism, but we need to do that in a way that doesn't drive all our users nuts. And that I think is going to be the driver. Like oh well look, we can prove this AI considered factual things and was policy driven and maybe use some of the AI for orchestration and all these other things. But at the end of the day you're for maybe your highest risk entitlements. They might be much more policy controlled versus maybe some other things that are a little more loosey goosey AI. So I think both it's a um, like least privilege is the driver at the end of the day and then it's well how to make a good user experience. And then it's like I still think you have a layer of, you know, not all entitlements or grants in our kind of identity parlance are the same. They're just, you know, there's some that are your crown, truly your crown jewels and others that are really productivity enablers and insider risk mitigation enablers. And so I think along that spectrum you also even have different choices of how much automation you have.

Speaker A: Yeah, I expect it, it will be heavily policy influenced originally, but over time obviously go probably more towards AI.

Speaker B: Ah, that's actually one of the interesting things I think we think about identity in a business. It's um, a multi party concern. Right. So this is one of the challenges that I think this industry has faced historically. You have everything from like, you know, hr, uh, people management, uh, issues of job titles and job codes and roles. All those things you have it concerns around kind of like help desk and getting people access to things they need and productivity. You have um, you know, kind of engineering and security concerns of like minimizing access and who should have what and also productivity. Even from the engineering side, like VP of engineering wants their team to be able to ship stuff, you know, so you can't lock it down so hard. It can't do anything. And I think what's interesting about AI is you can actually encode more and more of those Personas almost as different AI agents. You think about a business, whereas previously it was really hard because it was like, well, I could buy a it, uh, oriented access management solution, but it kind of ignored all the other people. And now I think with AI, you can start encoding those different peoples and Personas and their concerns and their goals into independent agents that can all act on a request and work together to make a decision. You think about some of the, um, AI agent like architectures. It's like you have a planning agent and then like sub agents. I think you'll see this where you know, each of your sub agents are your different business concerns. Uh, and then you have an overarch architecture of making a decision.

Speaker A: Where do you see those agents living? Like, I can envision a world where they're inside the code of the software, the application. I can envision another world where they're operating over on the runtime on the network side, like.

Speaker B: Yeah.

Speaker A: And the answer of course in the long term will be all of them talking to one another. But is there an easier or better place to start?

Speaker B: I mean, look, this is like those, uh, it's predicting the future of like a Nissan world. Yeah, I mean, I think it really is going to be a little bit D all the above eventually. I think pragmatically there's a lot of you have to look at like where protocols exist, I think to understand where decisions can be, uh, more easily injected. Right. So, you know, I think a lot about like the SSO layer, at that layer, it's pretty easy to inject. Hey, let's do some extra work here and figure something out right now. But when you think about row level access to a database, a postgres database, you know, there are products out there that can kind of like sit in the middle and read what you're doing. But like it, you know, they become more invasive. And so I think you'll see it start in the easier places to implement. And then there will be some companies that build kind of, you know, the proxy that has an AI in the middle of making decisions. And I think those will work too, but they're just harder to adopt generally. So I think you'll see a spectrum of deployment architectures and kind of like goals and outcomes.

Speaker A: In an AI world, like you prompt something and say I want to know something. That particular AI thing that you're talking to, how does it delegate down your authorization into the massive set of data that it probably has access to in the vector databases or in the model itself?

Speaker B: Yeah.

Speaker A: How do you propagate that across agents?

Speaker B: Yeah, so this is an area I think of. There are actually like multiple draft RFCs driving this question because the, the idea. Maybe just back up for a second for terminology. In my mind there's kind of like a uh, couple different agent types in the world. There's kind of like company agents. You can almost think of them as another employee and they'll have inputs and requests to. And you know, do they take on my identity when I ask it a question or does that agent inherently have its own roles and permissions and everything else? I think you'll see both answers there. I think there's also kind of like personal productivity agents which are again helping me write an email, helping me write code. They're, they're really like my agents and they're, they get a subset of what I want at any given time. And so I think if you split there and they say like, well, the subset question I think is a little easier. Right. It's a, it's really an identity propagation question, a, you know, an oauth. Uh, we're going to have extra claims on the access tokens and the ID tokens that say oh, this is an agent acting on my behalf treated as if Paul was querying the database. Right?

Speaker A: Yeah.

Speaker B: And I think that'll be the pattern for personal productivity. I think for like more you think about an agent almost like as a service account or an employee at a company. Um, you'll see a mixture of both where sometimes that agent is kind of impersonating me and other times it, it's more, it has its own roles and permissions and things. And I think it will depend on use case. Right. So like broad database access. I think you want more of an impersonation mechanism. Especially if you think about you have like very like role row oriented uh, permissions it will seem more like impersonation. Um, but I think when you think of, you know, where you want like a lot of summarization or other, other attributes, it's going to feel more like, well that's a. More of almost a service account that you manage m permissions to all the downstream data.

Speaker A: Well, I see this world getting super complex. Because I can imagine a customer Calling up conductor 1, say they want support and there's probably general documentation that the LLM has access to all of it. Then there's probably a subset of support data that you want them to get access to, but it's not their cases. So it needs to be anonymized in some way because there's relevant information in there, but it's not their data. And then of course they might be asking about something specific related to a case that they opened three years ago and you want them to have that specific. And so there's this, this weird dynamic of there's public, there's pseudo public but anonymized and then there's a delegated access gets complex.

Speaker B: It's gonna be super complex. But I think it's also, I mean the developer side of me this and like the, the products you can build side of this is like exciting at the end of the day.

Speaker A: Yes.

Speaker B: Like that is. Imagine that idea that I can understand previous tickets, understand anonymized data mesh in public reference documentation for the deep link to. Like here's how you configure X, Y or Z. Like that's pretty cool. You know like two years ago I would have said that's wild, there's no way. So you know, as much as yes, there's hard work to be done. And I think you'll see this, like I said, like the OAuth side extra claims. Like some of this stuff is happening in real time. Like even you know, the model context protocol and how it works and the authentication authorization of it, it's changing, you know, every month and that'll slow down eventually. And then I think it'll get to the kind of the hard work of like well, cool. MCP makes more sense. Now I can understand how to impersonate a user using OAuth claims. Now what you. Now I have to figure out how to anonymize my uh, previous tickets. Right. So I do think it's moving really fast. In fact I would say it's moving faster than like standardization can keep up. Like it's not far off. You know, it's not going to be a five year thing. I think, you know, even today you can get pretty far. Uh, but I think yeah, you just got to figure out the core principles. Is it, are you impersonating or am I a service account? Kind of. And then, then from there you can kind of build your architecture and figure out how to manage the authorization.

Speaker A: Yeah, I've seen some of the Proposals on the, on the uh, or not the RFCs on the. Anyway, the proposals to extend OAuth to MCP. And I am encouraged by what I see. Two questions because I know we're running out of time here. What worries you the most? So you're in this world of autonomous identity management and my next question, I'm going to end on optimistic, but what worries you the most in what you're seeing within the customer base of the market today?

Speaker B: Look, identity was already hard. So if you think about, you know, the explosion of SaaS and cloud, all these things, they already had like really hard problems. Like I, I work at a company, my company has several hundred SaaS apps, each one of those apps might, may or may not have customer data or other sensitive data in it. Uh, those SaaS apps might have local accounts and API keys and service accounts and, and non SSO users and all kinds of other concerns. And that was already a hard problem statement. Like honestly when we started connector one, that was the problem statement. Like that's enough, like that there's enough complexity there to deal with it. I think the general like infosec world, even the developer world does not understand the volume and the ephemerality change that's going to happen. Right? Like it's 100x, you know, like especially thinking about femoral agents that have limited scope for limited time periods. It is exactly like going from like physical machines that you bought from Dell to an AWS Lambda that existed for eight seconds while it serviced like four requests. And the thing is that transition that took, you know, kind of the cloud world, you know, 15 or 20 years to go from understanding physical servers to products that are optimized for, you know, ephemerality. Right? And this is going to happen in like a very, very small number of years. So I think that's the hardest part is like the complexity, the femorality, the all the things about agents is going to make this identity world even harder. And I just don't think most businesses are, they're still catching up with the cloud growth. And this is also very fast and it's not optional. That's the other thing is like there, you know, if you talk to the leaders of companies, there is a board level mandate to use AI, you know, how aggressive that mandate varies by industry and by board and different things. But like it is inevitable that every, you know, successful business will be leveraging AI, uh, in many, many use cases. And so that means like the security side, it's like it's happening like you have to deal with it. And I just think we're not like generally not prepared. Like it's just, it's going to happen really fast. We're not going to have the amount of time we had with Cloud and, and the uh, pain points are really big.

Speaker A: It's AI or die. I mean you're not going to survive in this industry unless you're using AI in a meaningful way. What makes you most excited? So you're obviously on the cutting edge of this non human identity and ephemeral, you know, identity. What makes you most excited?

Speaker B: I mean I think there's a real actually in our world, an opportunity to remove a lot of human toil. You know, like the things you had humans in the loop doing on access management were kind of ridiculous. Right? Like I'm going to submit a ticket to IT help desk. IT help desk is going to go look at a spreadsheet to look up who my manager is to find out am I allowed to get like Office365 or something ridiculous. Like that is 100% of it is solved at this point even with just using AI. So I think there's a lot of automation that's coming and already being built. And I think part two of that is you're going to move to a world of the like exception handling is what humans do and the everyday of it is going to be very automation, AI policy driven. And that to me is really cool because that means like the humans, especially in like the identity world, you know, we have kind of identity administrators and a whole cast of characters in this world. There's like projects you just couldn't do before because you were toiling down with all this day to day, uh, hey, we hired 50 people on Monday, like fix their stuff or we're doing M M and A. Our identity world just tripled and we don't know how to deal with it. These projects now become your focus instead of the toil of just everyday access management. And so that's where I think the world's going and it's generally a positive thing.

Speaker A: Yeah. So if I'm reading you correctly, you don't believe that autonomous identity governance is going to displace IAM teams. It's simply going to empower them to do the things that they really should be and could be focused on.

Speaker B: I think overall, I mean you could say the same thing about you know, software developers, like is cursor and all these things, like zeroing out the field, like no, no, no, no. In fact, yeah, uh, you know, I talk with my engineers about this. Like your job is evolving. Like your job now needs to involve more product vision, more understanding of what customers want. Like the hardest thing is knowing what to build, not necessarily the act of coding it. It's getting faster and easier and I think it' in kind of identity space is like your the important skills are what to build, why to build it, what creates business outcomes for your company, how to make your company materially more secure, how to reduce the standing risk of your company. That's what you need to focus on, not the toil of, you know, help desk tickets and servicenow tickets. Right. Like, it's just different goals. And so I think they're, you know, similar to software developers, which I work with every day. This identity world's also evolving.

Speaker A: Yeah, I completely agree and I tell that same story internally. Like we're developers are not going away in any way, but we should embrace it. Like we should use this technology. We can't ignore it. In fact, we should look at it as a superpower for us. Well, Paul, it was great to have you on, uh, the podcast with us on the Secure Developer. I love the perspective on autonomous identity governance. And for everyone who is watching this or listening, thank you for joining us again on another episode of the Secure Developer.

Speaker C: Thanks for tuning in to the Secure Developer brought to you by Snyk. We hope this episode gave you new insights and strategies to help you champion security in your organization. If you like these conversations, please leave us a review on itunes, Spotify or wherever you get your podcasts and share the episode with fellow security leaders who might benefit from our discussions. We'd love to hear your recommendations for future guests topics or any feedback you might have to help us get better. Please contact us by connecting with us on LinkedIn under our SNYK account or by emailing US at the SecureDevnek IO. That's it for now. I hope you join us for the next one.