 Hi, this is your host, Aptin Bhartya. And today we have with us our vice CEO and co-founder of permit.io. Or it's great to have you back on the show. It's great to be here. Thanks for having me. This month's focus is on security, dev sec ops. I mean, when we look at security, it's so big, it's fear that we cannot just pin point at one thing. So depending on who I'm talking to, the whole discussion changes. That what you mean by security, compliance could be an issue. Permissions can be issue. Bucks can be issue. API, zombie APIs can be issue. Application never use can be issue. Anyway, so it's a big topic there. If I ask you that, if you just look at the multicloud, hybrid cloud word, how security landscape has evolved from traditional IT, where it was an afterthought, it was someone else's job. I think it's changed dramatically, especially, but it depends how back you have to go. But if you go five years back, 10 years back, it's a completely different ball game. I think we've seen both the complexity of the space itself drive the need for innovation in security. But we also think saw how companies trying to tackle these challenges are adopting more and more solutions to have better results with what's going on in their cloud. That being said, I think we haven't moved forward enough. I feel like we have a lot more security solutions, but the challenges have kind of ran forward much faster than the solutions that we've provided. And if we look at things like the OWASP top 10, a lot of the problems that we listed 10 years ago are still on that list. And some of them might have moved higher, some of them might have consolidated, but most of them are still with us. So we definitely haven't solved security. We definitely haven't become more safe by moving to the cloud, but we have definitely been investing a lot of energy in it. That's clear when I'm talking to customers and when I'm working with people that are tackling these challenges. I do remember that just let's look at CubeCon Kubernetes ecosystem a couple of years ago. They started talking a lot about security. They're like now dedicated days for security. So a lot of things are changing in the cloud, centric cloud, and you work with also the shift led movement. But reality could be different from what we see, what we hear when we go to these conventions. We get folks who are expert, but customers can be doing something totally different. So can you talk a bit about when you deal with your customers? You actually did touch upon that briefly there. What are you seeing in reality that how further are they in improving your security posture or they're still like, you know what? Yeah, we will deal with security when it's needed. When I talk to our vendors, our leaders in the space, everyone's talking about new solutions and new practices to get better security, like S-bombs, software bill of materials, like embedding security into your Kubernetes with solutions like Falco or with permission enforcement or authorization in general with things like open policy agents. So those have become prominent solutions as part of the CNCF ecosystem and everyone's talking about them. But when push comes to shove, you see that people are still implementing most of the things on their own manually. They're still struggling to adopt these projects and they are still, maybe the worst thing is most companies are still applying these as an afterthought. They are not applying this, even though they're doing shift left, they're giving their developers a lot more responsibility with security. That responsibility is coming at the end of the chain after they've built something. Instead of, okay, we're going to build something, let's think about how we apply security by design, how we bake insecurity as part of our fundamentals. Part of that is also because we're carrying a lot of technical debt. Most companies are not starting from scratch, they have existing solutions that they need to patch or apply security to. And that obviously adds a lot of friction, but I think people also use that as an excuse to not bake insecurity from the start where they can. Can you talk about what are some of the major security concerns that are still there? If we can look at some breaches, luckily we have not seen anything recently, but any major breaches where you're like, hey, this is a problem that should have been solved, or this is an area we should be focusing on. I mean, a lot of things that FMA thing happened or other thing, they're more about not updating a package. That's the kind of beyond that, but anything else that you see is a concern to you? So I think the areas of vulnerabilities are in pieces of software or solutions or architectures or even platforms, those will always be with us. It's an arms race and there will always be another vulnerability, it will never end. We might get a better equilibrium there, but it's not gonna end. I think the area that is now experiencing the most friction and causing most of the both hacks and leaks is the area around how we build solutions on top of the platforms and how we bake in controls on top of them, specifically and obviously aligned with this lot, but it's also the top item on the OWASP top 10, application level access control. That's something that most companies are still struggling to address. And the other part which also kind of relies to this is how we allow access to data. Data has become probably the most desired resource that companies engage with and the most sensitive, especially if you have PII's or PHI's and a lot of the leaks that we see, like there was one recently with Twitter and with Uber and a lot of those incidents are about stealing the details of the users that are on the platform and then selling them on the black market or using their financial details to sell them as credit cards on the black market, et cetera, et cetera. So data access and in general access to application level, I think where we see the most friction and the most incidents come from, at this point in time. And I think it's sadly, I think it's only gonna get worse because we're seeing in parallel as we're trying to solve these areas of friction, we're seeing these areas also grow dramatically, especially due to the growth with the machine learning components that we're baking into software. So machine learning components means two things. One, we're generating more data because we're having more user interactions with the systems themselves that become more complex. So we have more datasets and also the data itself becomes more valuable because more companies needed to train their own models. So there's essentially another race condition here between the growth of complexity around data access and application access and the tools that we have to organize, control and protect that access to the data. And currently we're not only lagging behind, we're not even accelerating enough to keep pace. Since you brought this up, I am also kind of curious to know if there are any new vectors, thread vectors that are there which should be concerned for organizations? Something that is new, but it's probably too early to tell but it's definitely, it's starting to kind of realize as a new area of friction is attacking generative AI agents. So everyone's talking now about chat GPT and everyone's basically thinking about how they're gonna embed similar agents into their software. And we're already seeing hackers and attackers manipulate these types of agents. So you see a lot of interactions with the agents where it tells you, no, I'm not supposed to give you an answer on that. I'm not supposed to share that information. I'm not supposed to do this kind of behavior. But then you can see that the agent can still be manipulated by telling it to pretend to be another character, by telling it to answer from a different perspective or context. So suddenly the system that used to be very deterministic in how we protect it, now has the attack surface itself has become much bigger and much harder to cover because it's fuzzier because of the machine learning agent acting there. So for now, these agents are mainly spewing out data. Sometimes that data can be sensitive or sometimes just the fact that they reacted in some way can be detrimental to the company. For example, think about the Bing open AI demo where the agent turned out to be somewhat racist, somewhat misbehaving and also pretending to be sentient, which also kind of troubled people. And that affected the price point for the Microsoft stock for that day. So even that is impactful and has friction today and can be an attack vector on companies that attackers can leverage now. But it's even, I wouldn't say scarier, but it definitely brings cause to think more about it. You can think of what happens when these agents not only share data with us or communicate things that they already know, what happens when they start performing actions for us. So for example, if you have an AI agent that is responsible on who's supposed to access your database and you trust it to only perform specific queries. And suddenly because someone attacked the way the agent behaves, you are seeing irrelevant data or sensitive data or actions, maybe even it can cause it to delete the database, for example. So these are things that are just around the corner and we haven't covered the basics yet. So I think we need to invest a lot more in how we build controls for the data sources that we have for the applications we have. And we need to find a way to not only make them good deterministically, we need to bring them quickly up to speed with the complexity that is waiting for us just around the corner. How much adoption are you seeing of these kind of approaches in the market where we can conclude that, hey, things are moving in the positive direction? I think that's another kind of ironic situation. I think companies have been putting zero trust as their top line for at least two years now and they've been looking to buy, especially the CISO suite. They've been looking to buy products for zero trust or that have zero trust as part of their offering for quite a while, but I think they've neglected to think how they apply it as a method to the way they're organizing their security posture and the software that they're building. Zero trust is not just a VPN, zero trust. And if you just apply it as a bandage, as a VPN, you're missing on a lot of potential A and B, you're probably missing on vulnerabilities that you're not protecting of just having a VPN or a monitoring service that has zero trust capabilities. Zero trust is a mindset that you build into your software. I can give us an example of our open source project that we've created as part of PERMIT. Opal, we had to solve the problem of how we communicate policies and data in real time into decision engines. And the naive approach would have been, let's have this bus and just load the data to the server, the management server and all of the clients will download the data from there. And on the surface, that's an okay solution. And we could have tried and apply zero trust elements to it later, but that honestly wouldn't have worked and that would have missed out on one of the greatest opportunities with the project. What we ended up doing is decoupling the control plane from the data plane. The server, instead of being exposed to all the data, sends instructions on where to get the data to each of the clients. So each of the clients, only if they are approved to, only if they subscribe to, and only if they have the right access, goes directly to the data source and fetches it themselves. That means that you get out of the box zero trust architecture. The server touches no data and there's no concentration of all the sensitive data in one spot. And each of the clients get only the data they need when they need it. And it would have been basically impossible to implement this as an afterthought. And this is a core infrastructure component that affects policy authorization, for example, in our case. And this, but this is just an example. There are thousands of other architecture solutions that developers are creating on a daily basis and they're not necessarily taking this mindset into account and they're missing out. What kind of cultural changes you're seeing that are happening there? So honestly not seeing a lot of changes. It's in that era, it's kind of like same old, same old. And it's somewhat frustrating. I feel like, in general, I like the DevSecOps movement, but I feel like similar to the DevOps movement, it's kind of missing on the point. With DevOps, the point wasn't to add more people that will do DevOps. The main, the core offering was, let's have the developers do ops. The same thing as with DevSecOps, you're not supposed to add security people alongside your developers or after their developers work to apply security. That misses the point. You want the developers themselves to be immersed in security. You want them to use security by design when they're building things. So now obviously you can't have everyone be a security expert, but you can invest in training people. You can invest in giving people tools, examples, methodologies that they can adapt and work with and be aware that they need to do so, have that as part of the expectation. You can rank your, well, not rank, but you can motivate and help your engineers work on security as part of their job and not just check it as an afterthought or when you have to do your compliance. In the end of the day, while it seems counter-intuitive, it will actually save you a lot of money and a lot of pain and friction later. So what I'd suggest for companies that don't have the DNA built in for security is hire, look to add per team one engineer that has some security background, but don't have them as the head of security or the responsible for security. Have them work with the other engineers to teach them. Have them turn your other engineers into security aware engineers. That's at least my two cents on the matter. Now let's talk about permit that I, of course, we cover you folks on a regular basis to our audience. Totally know about what you folks do, but just in the context of this discussion is that what role is permit.io playing to once again, help companies improve their security posture? I'll highlight two things. One is something that we kind of touched on. Access control is a critical aspect that you need in every bit of software that you're building. And it's really hard to build on your own. It's just like with encryption, just like with authentication, it's really hard to get this right unless you really are an expert in this. So you can build this on your own, but you really shouldn't. You can adopt this at day one and save you a lot of friction down the road. And I think even if you're not buying our product, you should at least review it and learn from the best practices and from the open source projects that we've created. So you won't end up repeating mistakes that we've done and learned from already, for example. And I think the second part is about commoditizing access. So what permit does, it's not only an infrastructure and API solution to add permissions and access control, it's a system to manage it. We provide end-to-end experiences that every application needs, like user management with the ability to assign roles, API key management, audit logs for yourself, audit logs for your customers, approval flows, invites, all of these interfaces that most applications need. So instead of building these on your own, you can have them ready-made. And through them, you can enable the rest of your organization. This is not just about the developers. So it's about empowering developers but allowing them to delegate to other people so the developers don't become your bottleneck for this. And as the tensions rise and as more and more security challenges surface at the table, so for example, around data access, as we mentioned before, you want everyone to be able to chime in on the conversation. You want everyone to be able to take effect on how you set your policies and how people and systems connect to what you're building. What advice do you have for companies so that they can work towards improving their security posture? So I think the best tip there is to apply security by design. Don't apply this as an afterthought. Don't wait for the product to be ready. Apply it at day one and to do so, you need to both adopt the mindset for it and adopt the DNA that you need for this. When touching on dev ops and dev sec ops, key point there is that you're supposed to enable your developers to be able to do ops and to be able to do security. It's not about separating this to a separate person. So what you should do or what I recommend people do is hire security aware engineers and have them not become your security person, but have them empower your other engineers, teach them the right mindset, give them examples on how to build things with security as a first leading principle and again, not as an afterthought. All right, thank you so much for taking time out today and talk about this topic. And as usual, I would love to have you back on the show. Thank you. Thank you very much. It was a pleasure.