 Hey everyone and welcome to this session on the trends and DevSecOps and cloud development. You've got a few too, who would I like to say developers, myself or wise, a developer and security practitioner in background and now founder and CEO at Urban IO and with me one of my favorite people is Philip or Dev Advocate. Philip, you want to add a few words about yourself? Yeah, sure. So I mean, I'm a developer advocate, but I do have a background in engineering. I used to lead a team at Cisco, the front end efforts especially at Cisco. Cisco is a networking company and it involves a lot of security. So I'm sure I'll be able to have some input as well, some interesting input when we come and talk about DevSecOps and cloud development this year and maybe the possible trends of next year. Awesome. Yeah, I'm kind of excited for this. It's always good to kind of sum up a year and trying to take a glimpse in what's coming forward and I think through this year we've seen a lot of interesting things both with just our own work and the work we do with our customers and you especially were really at the front line engaging with people, helping them build things. So I'm really excited to hear what how you summed it up and so maybe that's a good place to start. Just what are the highlights that you've seen working this year in both the DevSecOps space and in general in cloud development? Yeah, I think a lot of people, I mean, actually software is becoming very prominent in everyone's lives, not even just the companies that are tech related, but also just normal people that need to use tech these days. And there is a big trend and a big prominence on actually having security be part of those trends and be part of those ever-growing companies that are involved in tech. Just to kind of take a few steps back, I think it's an interesting contrast how a few years ago we didn't treat security as like a very, very big priority, at least not as high of a priority as it is right now. And what we noticed is, for example, take it back like 10 years, nobody really cared about authentication, even more so about authorization. I don't think that was a concept much back then or at least a talking point. And everyone built their homebrew solution. Everyone did everything on their own. And then move forward the few years until today, authentication is almost becoming a standard with every company. No developer wants to work on it because there's companies that do it better. And same thing with kind of authorization, I think it's becoming almost a thing that is a requirement. Security is growing ever higher. And people just don't want to do the hard work and they're moving and trying to find solutions that they can incorporate in a simple way to save them time and to add value to the company. So I think that's kind of a big thing that we saw this year and it's going to grow even more into next year. I definitely agree. I think software is eating the world. It's kind of a common understanding now everyone's realizing it. But we see it like also with shift left, really more and more elements are moving to the developer side, more and more elements of both security operations. Everyone wants to start them as early as possible. People are starting to realize that if you try to add that later, it doesn't really work well. And then it's also a question I think that's what you kind of touched on the question of what are the baseline and what are the fundamentals you're building on? How much are you trying to invent yourself and how much you're adopting as an existing best practice or tool that you can use? And I think maybe another very interesting angle on that is that this is affecting a lot more people. So it's not just developers. We're seeing product managers, we're seeing sales, we're seeing professional services, we're seeing the security people also from the other angle. Everyone's kind of honing in on the DevSecOps angle. Everyone wants to be able to chime in and how you do security on the development cycle itself, how you bake in security into the product in the earliest stages. And it's more funny to see like with product managers that not necessarily the most technical people, but they have to be now. They have to understand what it's like to be a developer, and they have to understand how security works, because they have to have those baselines as part of a product. You can go without authentication today. And as you said, as opposed to 10 years ago, no one wants to build it from scratch. Authentication is a proven thing now. Just like it used to be like 10 years ago, we added our understanding of think with encryption already. You don't want to roll your own. No understanding has already kind of taken another step forward with authentication. You don't want to roll your own. And I think we're starting to see that authorization as well. In general, maybe everything that isn't a core part of your product and especially if it's not a core part and it has a ability to affect the stability or security of your product, it's better off to use at least an open source solution or at least the best practices that the market has come up with instead of trying to do it on your own. And I think it's interesting to see, especially with the type of customers that we're seeing. So one of the things that really surprised me this year is the amount of healthcare companies, either companies that are actual healthcare providers or ones providing services to healthcare providers or around healthcare or Medicare. So I was surprised to see how many of those are moving the fastest with adopting the new best practices with adopting policies code, adopting authorization as a service or permission service. So as someone who's really at the front lines, can you maybe share, how did you engage with those customers? What are the things that they're asking? I mean, I think just taking one step back as well, just to highlight the point on, having people like product managers have to be part of software now. I think what we're seeing is that in general, security is very difficult. It's a very difficult concept that requires a lot of knowledge to grasp, especially for developers. It requires a huge amount of knowledge to implement. And it's hard to implement security within an app. There's too many things that you need to make sure that are working and no developer wants to be put in a situation where they write a piece of code and it doesn't work or it doesn't work the way it should. And then there's some security flaws in the system. That's probably a developer's worst nightmare. So I think what we're seeing now is a big chef shift to software that's very easy to use, very abstract. And that's where we talk about no code UI. And now going back to client meetings, I think a lot of the companies that we spoke to, companies that are in healthcare, in security, they have this whole team of developers that are willing to build this. But they don't want to build it themselves. They want to use something that's already out there. And that's not just to make it easier for the developers, but it's also to allow other team members to be able to use the product and have an understanding of the product. So this is kind of what we're seeing with our clients. More clients are actually coming to us and they're asking us about the solution that might be offered. And they're very interested in seeing how they can do it in an abstract way where they can engage the rest of the team. Right. So it's not just about the developers getting the security tools. It's about the developers enabling all the other folks to work on those tools as well. I think that actually puts us in a very interesting junction between two trends. So one trend that is very apparent and kind of talked about is the shift left and kind of security becoming ingrained and everyone becoming a developer to some degree, everyone working on on security, becoming something that is unavoidable for basically all the personas, all the stakeholders within a company. And another trend is the growth of code and specifically policy is code to manage all of these complexities. And there's, there's some, some of the attention there. So as a developer, you want to manage things as code, especially complex things like policy is code, infrastructure is code, configuration is code. Everything is code is basically the hottest trend right now. But code is not accessible yet to everyone. Product managers might be a little tech savvy, but they're not full blown developers. The security people themselves that need to work with this, they're not full blown developers, at least not most of them, but they need to work on this. So on one hand, we want to manage things as code. On the other hand, we want to enable everyone to work on this. And these seem to be apparently in conflict. I have some ideas on where this is going to be. The thing one thing that you mentioned is through kind of low code. So interfaces that make it easier for not full blown developers to work on these problems and maybe even generate code for them. So no code interfaces that generate code I think are a swell thing that in the end of the day, you get that baseline and best practice of policy is code or configurations code. You manage it in a Git repository. You can do code reviews on it. You can do tests. You can do benchmarks. But you can have people at the top line generate that code without necessarily fully understanding it. In general, the low code, no code space is going very quickly. No code aspects are becoming a key part of almost every product. So just having that additional code generation thing I think would really become very valuable there. And I think that also touches on the number trend that we're seeing really exploding in these recent days. And that's generative AI. So machine learning component that you feed with some kind of low code interface. Maybe text prompts, maybe a form that you feel maybe another kind of interface. But at the end of the day, dead AI can generate text, code, interfaces, documentation for you. So having low code interfaces that are then funneled into an AI that generates code, that sets in a Git repository, that the developers can then collaborate with that AI on, I think that's a very exciting space. And I don't really believe in AI is going to take over everything and all the developers be out of jobs or anything like that. The jobs will just change, be collaboration with that AI. Using that AI to generate for ourselves, enable other people to generate code. And then still think that lower level of code as code is still a good thing that we have a lot of best practices on and how to manage complexity on. So you have a single source that makes it easier. What do you think of that? Or what are our other trends that you were saying? I mean, I think it's nice to see the retrospective of what has been happening before. And I think the first site where we saw a no-code UI come into place was with website creation. And it started off with people and having to hire developers to build that. And then obviously, there came the whole kind of group of companies that designed this no-code UI for not just people with little technical skill. It was even designed for people with no technical skill to be able to produce that website for themselves and maintain it. And that was done to kind of reach a really big market and reach a really big audience. And I think most companies now, especially in developer security, because it's a really hard concept to grasp, not just for developers, but also they want to include the people that may not have a technical background into the whole space because of a bigger market, they're designing all these kind of tools. I think everything that we see in software now very much revolves around automation. It's anything that's complex and anything that can be automated and abstracted is done or ways are found to be done. Because it just kind of really gives a faster workflow for companies. It really makes it much more of an easier process. So I think, especially with like we saw for ourselves, we saw a lot of companies in healthcare and compliance. And I still wonder why there is such a big interest there. But I think it's because they have all these other compliance issues on top of them that they have to deal with. So because then at that point, it gets so difficult that they're looking for solutions to just ease the whole process. And that's kind of my opinion, maybe why we might be seeing this kind of trend with healthcare. But yeah. I think it's double-fold. I think one, the complexity itself makes more people want compliance. Because when a system is very complex, especially if you're a security practitioner who is not highly technical, you're looking at another vendor and it's essentially another attack service. It's another risk that you are taking on if you're starting to work with them. But on the other hand, you don't want to do it yourself. You need that vendor, need that other player to take some of the burden off of you. But then you need that vendor to work for you in a way that you can trust. And the best way that we have so far, which I don't think is that good, but it's better than nothing, kind of like democracy. It's the best option of all the rest that we've tried, is compliance. So having the vendor meet the specific standard that you know is audited, that you know is standardized, that you know can be verified, can really help you as you engage in growing what you need to do when you're a product or in your company. And as more companies look at compliance as a way to standardize, engage with other vendors, also these vendors need to find a way to be compliant. And I think the spaces that have the most compliance pressure are healthcare, fintech, the security space itself, the government space. So that pressure on just we need to manage all of this complexity so we need compliance, forces a lot of companies to start with compliance that they want. And so they need to themselves adopt solutions to make the compliance easier. It's kind of a, I don't want to say vicious cycle, but it is a cycle. Like you need compliance, so you need better tools for the compliance, so you need better compliance for the tools, which need better tools and rinse and repeat. But I think in the end of the day, it's kind of a tide that floats all boats. The entire, the level of compliance that the standard that we think of, of what is the minimum compliance that a company should have is rising across the market. So I guess another, you can still start to be businesses today and you don't have to have certification that they want. But I think like in three years from now, five years from now, that will basically be nonexistent. And talking about better tools, how do you kind of see authorization as a service in that space? Because, you know, we see a huge amount of interest coming in from different companies in different genres of tech. So, you know, how do we see that kind of going forward? So I think with that, it's really, in the end of the day, if you look at compliance standards like SOC2, ISO, even the GDPR and CCPA, definitely things like HIPAA. In the end of the day, when you break it down, it's about 70 to 90% about access control. It's about how you decide within your processes or within the products you're building, who can do what and which scenarios. So a lot of times you can make the work of just having processes in place, having human readable policies that the humans in your organization have to follow. But it's a lot easier to make sure that people follow things if they're automatic guardrails. There are automatic checks that are more or better yet, automatic gates that control who can do what. And that applies both for what you're building internally and how your organization works, but also what you provide to your end customers. If you're building a product, in order for you to be compliant, you need to bake in access control and permissions into that product, both in how you operate it and how people use it. And your customers will have to have access controls. Everyone kind of thinks about RBAC as kind of the baseline. RBAC is kind of the role-based access control is the bread and butter of basically of compliance or permissions in any product that you build. So everyone today, engaging in products, knows to ask for RBAC. But I think that's just the beginning. The complexity is continuing to rise. The amount of people that need to be compliant is increasing because of that cycle that I mentioned before. And so I think it's getting to a point where having authentication, having identity management, having permissions as a baseline to start with anything you're building is kind of the easiest way to go. It removes a lot of friction from down the road because if you try to add it later, it will be more painful. And I think more and more people are realizing it just because of the basic demands that they're getting. If the demands are forwarded, just give me a product that works. Now it's give me a product that works and meet all of my standards, especially my security and compliance standards. But I think in this case, there is a lot of companies that are going to have the dilemma. And it's like, do I use this now or do I use this later? And I think many small startups, I think it's either a good thing or a bad thing if they use it later because there already might be for the process. And obviously the most difficult part, especially when it comes to authorization is, like, can I implement this now? Have I not started too late? Is it possible for me to move everything? And for startups, that's still, I think, manageable. But then think about all the really big companies. And we're talking like big fintech companies or big healthcare, they've got their own homebrew solution. It's very hard to scale. They're getting more people. It takes up so much time for the developers to be able to manage this solution. And here the decision comes, like, do they move? Do they stick with what they have? Is it worth it? Is it worth the time? Like, do you have an opinion about that? Do you think do you have a best practice of maybe what people should adhere to, like a top two tips or something like that? Yeah, that's a very good question. And I would say that even like within permit, that's something that, for example, with Asaf, my co-founder and our CTO, I discuss these kind of dilemmas on at least a monthly basis, I'd say. There's always this tension between having higher quality and having a higher velocity. You always have to choose. You can't have both. So it's about finding the right equilibrium point for you with each movement in time. And as every product, every company, every problem space is a snowflake. I don't think there's a silver bullet answer, like a panacea, that this is the right balance point for everyone. But I think recognizing that there is a balance point and kind of enabling you to move on that spectrum is really the way to go. And I definitely don't think, like I'd want to say as a vendor, everyone has to have a authorization as a service that they want. I'd like to say that, but I don't actually believe in that. I think what you want to have is the amount of access control that you need at each point. And you should invest in the minimum that you have. But be aware that it's going to change. Be aware of the more requirements around compliance or on security of both features. Access control, for example, is really about how people use the product. So that really translates into features that customers ask for. Give me invites, give me impersonation, give me approval flows, a lot of things like that. So those things are coming, if you like it or not. So it's about finding your equilibrium point, but planning to be able to transition into more things. And there I think best practices can really be helpful. Things like policy is code. To use policy as code doesn't cost you that much. It's just another way to define your access control. It doesn't add a lot of overhead. De-coupling your policy from your code. So having a separate microservice for authorization, even if it's just like a Lambda function that initially just returns through. It checks if it's your email, it returns true. If not, it returns false. Even that is better than having that same line of code embedded within the product itself. Because then if you want to upgrade, now the box ready, you can just pour more capabilities into it and upgrade it gradually. And in general, that's one of the best practices and trends that already saw its fruition and fruitation and growth in the cloud computing space. Microservices are, I don't think you have to break everything into a microservice, but using microservices to a certain degree, having some granularity, having to decouple your services is really a very smart best practice. If you plan to scale your software, and if you're building a business, you are planning to scale your software, microservices, at least to some degree, having a few microservices is the must. And then when you have that, you can try and identify the areas that are separate, that are not part of your core product. So classic things are like authentication, billing, analytics, permissions, databases. You can start with something that you ruin your own or start with an open source or start with a service in the cloud, but you want it separate. You don't want it locked in and coupled with your own code. So when new demands come in, you can switch in place and go. I think that's about it. So summarize microservices, decoupling your code, finding the right balance point for you at each point in time, and gradually adapting more services and tools so you can meet the standards, instead of constantly having to refact for your own code, which is very expensive. And I think with this situation, it kind of applies to any kind of developer tool product for a company to use is actually finding the problem within your own system and seeing if it can be improved. And I think quite often, it's hard to realize if that problem exists, or maybe it's hard to realize to take the first steps to actually do that. Now, of course, at permit, we would love for everyone to use authorization and to implement it as a full stack solution. But there are sometimes situations where, of course, you know, someone might find a homebrew solution more beneficial. Maybe there are some cases where, you know, it might be maybe not necessarily easier, but maybe more compliant or maybe something like that. Do you have any opinions about that? Like the mental load that you need is easier. Like, I know that if I'm writing the code, I can trust it because I trust myself. I don't know. I don't know. You seem like a nice guy, but I don't know. Can I trust you? That doesn't always work though. So it's, at least in the mental capacity, it's easier to start with smaller things that you do in your own. But it's important to remember that you probably don't want to stick with them throughout time. It's good for a while. There's a limit of how much you can build every little thing. In the end of the day, as a developer, as a product owner, there is your own specific unique product that you want to build into a shape with your energy on building other products that already exist. It's essentially reinventing the wheel. It is. Yeah, it is. And I mean, I think in general, when there is a solution, any solution for any company that can be, that a company can save time on, I think that's really beneficial in general. I think every time that you notice that there is a problem and you notice that you struggle with the problem and that there is no simple solution that you can find for it, that's usually the time when you should start thinking about outsourcing it to other companies who have spent and dedicated a whole team to making sure that the problem is understood, that the problem is solved, and that the problem is solved very well. So then later on, when the company grows and it scales, you don't have that issue coming up. Now, moving on, I'd like to just touch on and get your opinion about what do you think about just authorization growing in 2023? And so next year, what kind of things can we see pop up that maybe people are not expecting? And what would the generic kind of trends be? Is there any kind of differences that will be noticeable that we'll be able to see and maybe kind of jump on the wagon and use to make it better for any kind of company? Yeah, so maybe it's worth to kind of glance back at the short history of modern authorization. So this is a nascent space. It basically started to grow around 2020, maybe 2019, if you're really optimistic. Policy's code, this kind of grew solutions like open policy agent started to become more popular, especially with the growth of Kubernetes, and the infrastructure as code space or in general the infrastructure in the cloud space really pushed the growth of this space. And now it's starting to come into the application development itself. Up till now, I'd say most people, when you ask them how you go about building authorization, they'd say, what do you mean? I build it on your own. I just take in a few if conditions into my code, and that's it. I take a JSON web token, the more sophisticated ones. I take a JSON web token that I get from my authentication, and I push a lot of claims into that. And then I write code that parses all the claims in the JSON web token. And according to that, I'll have authorization within my product. And I think people are, as this space is growing and more people are becoming aware there's an alternative to building on your own, it will gradually become a standard. I think it's already at the cost of that point. And with that is also the maturity of the products themselves. Open Policy Agent is just one example, but more policy engines are out there. I think the most prominent new one that I want to mention is Cedar from AWS. So there's a policy engine that will soon be embedded into your AWS cloud service. And so this will really become the building blocks, policies, code, engines to parse them, services to have APIs for them, those within the next couple of months even I think would proliferate the space and become very commonplace. Then this question moves to how do people adopt this? And how do they maintain this and how do they work with this long-term? And there what I think we'll see is that people don't want to maintain this graph. People don't want to write policies as code. People don't want to build interfaces on top of them. They just want to be able to check off this thing so they can actually focus on building the products. I know personally, I found myself in my previous company at Brookup. They found myself rebuilding access control five times when the company wasn't even three years old. And I definitely didn't like that. I wanted to focus on that. Of course. And also the fact that I always thought, okay, this time I've built it. It's going to be perfect. Yeah. I don't want to talk about this graph again. And suddenly you get the use case that just froze you off completely because you just didn't think of it. And it's very hard to come up with all the points to make sure that you've covered everything, especially in security. So yeah. Yeah. So for example, we worked actually with Cisco as a vendor. And they came in and said, we want our own vendor, sorry, as a co-seller. And they said, we want our own back office. And I was like, I didn't think of going to the back office. And I had to go back to the drawing point. So having those, so mentioning the back office, in the end of the day, access control is about experiences. It's about interfaces that people can use. User management with the ability to assign roles, API key management, secrets management, audit logs. So the ability for you as a vendor to see what all of your customers did, all of the tenants did. And the ability for each of your tenants, each of your customers to see what they did on their own. The ability to ask permissions from another user, the ability to have an action that you're performing approved by another user. This list just goes on and on. And it's really classic things. And I think these things should be ready made. I think they should be interfaces that you can just bake into your software, just like you bake in and log in screen. Just like you bake in a checkout cart, just like you bake in dashboards. This should be ready to bake in into your back office and to bake in into your product facing customers. So people won't have to deal with this. They don't have to think about reinventing this. They don't have to think about how to make this secure, how to make this work. So we're seeing a point where the infrastructure is getting really standardized. Policy is both getting more polyglot, but it's also getting standards and best practices that people can adopt. We're seeing APIs for this becoming very commonplace. I think the next thing is really the experiences, the interfaces. It was also becoming standardized. So when you come to an AI model or you come into a product, you will already know the interface that you're getting because it's the standard one. It has been customized for you, but it's a standard interface that allows you to work with complex policies and permissions, but the developer that built it didn't need to reinvent it and you as a user don't have to relearn it. That's really I think the next step in the permissions or authorization space. Yeah. I see a common trend and I think a lot of people when we're talking about security and when we're talking about authorization, they understand or at least the first people that even learn about authorization. They usually just understand it on the concept of admin and non-admin. But I don't think they have a concept of understanding how complex it gets. And you've mentioned so many things just now about API key management, just making sure that all of these examples are actually implemented and work, and then providing the experience for the user. And I've been a front-end developer, that's kind of what I really enjoy. And that's kind of what I like doing in my free time. And I know how important user experience is, especially when it comes to dealing with complex subjects. So I think we're an artist at heart. And I'm a creative artist at heart. I guess that's kind of true. And I can just see not only how much simpler it's going to make it, but how much the people are actually going to appreciate it. Because at the end of the day, it's about making things easy. You don't want to over complicate things. Nobody likes learning about complex stuff and then trying to apply it. Well, actually maybe some do, but that's... I think the difference is between working on learning and working on complex stuff that are at the core of what you want to do and having to deal with complex stuff that are just stopping you from actually building what you want. The stack is constantly becoming more bigger, wider, more scalable. So we need to specialize. You can't do everything all of the time. And then the focus shifts on what is your core? I think that's something that every developer, every company should ask themselves. What is our core? What do we do when we focus on and is unique to us that no other company is doing? And that question, I think, can really divide the space, the things that you should spend your time on and the things that you should just swipe off your table. So you can focus on the things you should focus on. Exactly. Okay, cool. So I think I'd want to add a little bit from myself, just in general, what I think might happen with DevSecOps coming the next year. And I think, especially maybe focusing on the subject of our authorization, I think we're definitely going to see authorization evolve a lot. Like we've mentioned, we're definitely going to see kind of experiences come into place, experiences as part of DevSecOps, which I think is really interesting, because usually it was just very core stuff that hardcore developers were focusing on. But now we're actually getting to the stage where that abstraction, that no code UI will come into place, that management of all these really important topics will evolve and will become something that essentially becomes almost plug and play, which I think is great value to the whole developer community. I think there is going to be a whole increase in the kind of maybe other players in the market that do offer this kind of solution. But of course, I think it's quite an interesting thing that we see a lot of other companies do infrastructure level authorization, but very, very little do application level authorization. And it seems like infrastructure is very important, but also managing those permissions application level is very, very important too. So I'm curious to see if that focus kind of turns away or if it stays and how that's going to evolve later on. Yeah, for sure. So I think we've covered some good topics here. I think we had some recurring themes, both with low code, no code, both of shift left, kind of speeding up and bringing all the other stakeholders, not just developers into the mix. We touched on how compliance is speeding up through kind of a not a vicious cycle, but some kind of cycle. We touched on how low code, no code interfaces are going to power a lot of this, especially in the intersection with complex systems and machine learning models. We touched on how there's this tension between what you want to build and using policy as code for it, but enabling other people that are not necessarily code savvy to use policy as code and having code generating low code interfaces come into that way. We talked about what we see for our customers, specifically in companies in general in the space, we're seeing fintech and healthcare companies and security companies kind of lead the charge both with dealing with compliance and adopting these new solutions for better security baked into the products that they're working on. And we covered a lot of things, but I think these are like the main themes we touched on. So I had a blast talking to you as always. Absolutely. Everyone watching us also enjoyed this and maybe gained a few tips or insights or at least interesting trends to think about for looking back at the year that we had and looking at the upcoming year that we have. And I hope we all have a good compliance, secure and filled with great software year ahead of us. Absolutely. And I think in general, it's important to mention that we are very kind of open. We love chatting with others, especially about developer security. We're very easygoing. So we'd always recommend that you jump on and join our Slack and ask us anything about security. And we've got a whole team here that's really eager and passionate about the subject. So I would be most interested in engaging in the conversation and seeing what we can discuss and kind of the interesting topics we can cover. Yeah. People watching us, if you enjoy this conversation between Filipina and you'd like to have a similar conversation, just brainstorming ideas, talking about what you're building and getting our input on it or just brainstorming around security and cloud development. We love to do that. It's fun for us. The reason we do what we do is because we love engaging our developers and our security practitioners. If you can literally go on permit.io, there's a button to schedule a currently session with us to just pick a date and we show up. Yeah, that's exactly it. You don't even have to talk to us about permit, the product or about the open source project that can just talk to us about technology in general. We always enjoy that. So yeah, Filip, thank you very much. Thanks so much. Thanks for everyone watching and have a great year. Bye everyone.