London 2020
Dev-First Security: Learning from the Pioneers
Digital Transformation, and notably Cloud and DevOps, have radically changed how we run our business and build software, and yet security practices in most companies remain largely unchanged, and so are left behind.
This talk shares practices and learnings from companies with forward thinking security teams, who have transformed their security practices as well. It offers practical tips and tricks from these leaders, and a broader view on a different approach to security - dev-first security.
This session presented by Snyk.
GP
Guy Podjarny
Co-founder and President, Snyk
Transcript
Hello everyone. Um, uh, I'm and I'm here to talk to you today about debt for security, sort of a different view of how do we serve approach security, uh, that tries to sort of focus more on the sort of modern development surrounding. Um, I'm going to share my perspective, a little bit of a laptop market stance, as well as, you know, what is that for security? Uh, but maybe more importantly, I'll share a lot of specific practices from smart people that I've had the, uh, the opportunity to talk to about how they tackle security inside their organization. So we can learn from that and we can share, so a little bit about me, uh, um, did Capricornia or die pod on the, sort of the twist hers, uh, and the likes, uh, I'm the co-founder and president here at snake. Uh, and before that I was the CTO at Akamai.
After, after they acquired a company, I founded called blaze during that stretch, I worked on what performance are much going to be another aspect of some of the world of DevOps. And then prior to that, I spent about a decade in AppSec. Uh, you could say before, it was cool, not sure if it's cool today. Uh, but, uh, definitely, you know, kind of in its early days, building self first, uh, security products. Um, I also, you know, do a decent amount of this sort of type of, uh, public contractions. You know, I host a podcast and they're all referred to a decent amount here, uh, talking to some smart people, uh, and trying to give them a platform to share their security practices. And I've written a bunch of books with a Riley, including two that, you know, there's links about you getting a, that you can get a free copy to them, uh, on the right around securing open source libraries and serverless security.
So with that, let's dig into the, the, the talk itself. And I'm gonna start with a word that not everybody likes, which is digital transformation, uh, and that's, you know, it's a buzz word and buzzwords can contain complexity, but it's also a very real thing. It's a, it's a change, it's a big kind of wave, uh, of, uh, of, you know, evolution revolution in how businesses approach the world of digital and how we build software, how we run them and, and how we just operate our businesses. There's a lot of ways to slice and dice digital transformation. And I'm going to use this split. Um, I'd say the digital digital transformation, you know, in, at a very high level, uh, is composed of three big buckets. One is more software. The second is cloud technologies, a different sort of foundation of technology on which applications run, uh, which interact very closely with a different set of methodologies, which I'll refer to as DevOps.
Methodology's fully appreciated that again, this is a, there's a lot of ways to sort of look at digital transformation. So what I'm going to do is I'm going to dig into each one of these three in the context of security and, and see how they affect it. And so more software, uh, simply put equals more software risk. Uh, and I'm not going to belabor this point too much, but really as businesses get digital is more of your, you know, of your, of your business, of your revenue, of your operation, you know, goes online and goes digital. Then, then really more your risks, more of your data, more of your revenue risks, all of those become digital as well. Uh, this is a quote from James Kaplan who heads the cybersecurity practice for McKinsey, and you had, you know, he was on the podcast, uh, and he has this great blog post as well about how security is the, uh, the linchpin cybersecurity is the linchpin of digital transformation, but specifically points out quite simply.
It's safe for many companies. Cyber security is increasingly a critical business issue, not just a technology issue, uh, and even points out to know this reference to a CSO, uh, conversation that he had, that hedge funds didn't really use the care about cybersecurity, for instance. And now they're obsessed with it just as one example of many. So not going to belabor this point too much, definitely not a, a technical point. Uh, but, uh, but just to say, you know, for many businesses, if you live in the technology world, this might be obvious that, you know, sort of tech is at the center, but for many businesses, it's this shift of, you know, what is the chief security officer focused on from maybe more physical security or, or, or fraud or other aspects to more and more being related to software risk, getting a bit more technical.
Um, the, the second kind of aspect of, uh, cybersecurity is cloud, uh, and cloud. There was a lot that you can say about the security of cloud. Um, you know, you can talk about all this new technology and every new technology, uh, introduces some risks. You can talk about how it's less mature and it's been embraced a bit more quickly, maybe, uh, then it's security kind of aspects have been researched, or just about the sort of the network perimeter change going from data center to something that is hosted online. But what I think is more interesting is that cloud changes the scope of the application. You know, let's dig into what I mean by that. So in the pre-cloud era, again, using a little bit of black and white terms and the pre-cloud era, you have this sort of heavy it stack on which applications are built.
You know, there's some hardware management, maybe some kudos on data center at some VM. So vSphere running, um, you've got some Cisco routers managing these, um, kind of network access and what pores open some VMs, an Oracle database sort of thing on site. And then you have some code in some libraries. And if the app teams want to engage with this sort of, you know, central it stack, then you know, the open tickets that, you know, you asked for some provisioning of some components and you interact, and it's owned by teams that are relatively central and they manage those components in the cloud surrounding the layers remain mostly the same. You still need to control network access. You still need to manage dos. You still need the database, but suddenly those might be, you know, a VPC on AWS. They might be a container that manages that AWS, that M O S a and needs to be patched.
Uh, it might be, you know, a cloud database service that you're using, or maybe some Mongo DB that you've sort of pulled in. And so the components are, are there. The functionality is still there, but the way that these things are pulled is very different. You know, now, instead of being managed by decentralized team, they're a part of the application they get deployed and they are packaged up in the same, in the same area, in the same repository, through the same build pipeline as the code and the libraries of the application itself. And that's very significant because it means where are the decision where the decisions are made that impact these securities and where the solutions need to be placed to help tackle security concerns with each of these layers is different. It needs to go from it security to application security. And, and just to say that this trend will continue like this, this motion of going into the app is more and more, and it's breaking some DevOps.
We'll talk about that in a sec, but you know, you can see data, you can see CDM, I've sort of seen a lot in Akamai. Um, you know, the API gateways or the use of third-party services, whether in the cloud or otherwise, all these are becoming a part of the app. They're packaged up into one unit, one self-sufficient, uh, package that controls a lot of these different aspects and helps them in a running in this sort of uniform, you know, synchronization. And so for security, that's very important. We need to think about it, security solutions and the it person who central, uh, it person needing to, to tackle them to more apps oriented solutions, you know, and that need to be addressed as part of the developer workflow. And then lastly, the very much not least is dev ops and, you know, dev ops is, uh, um, you know, it's, uh, it's a, it's a big thing.
Again, you can define it in many ways, but it predicates a lot on these two core principles that are very related. One is continuous processes, continuous integration, continuous delivery, no, no slow down, no manual delay, no stop for a manual process. And then the second is these empowered self-sufficient teams that can do all of that, that, you know, they own that journey end to end, which, you know, very much relates to what I talked about with the cloud scope. So they also control the scaling of their system, the network access of the assessment, the data of their systems, et cetera. So they can tighten that loop, no from writing a line of codes to getting it to the market, you know, to provide value to learning from it and back again, you know, adapting to the market needs. And so with all of these changes, security, for the most part, hasn't kind of moved with the times it's left behind security traditionally, and still very much today is done in this type of elements, even if it's as a circle and not an infinity loop is done in a way that is about gating.
It's about stopping stop here. I will do a security review. I will audit those are done by teams that are outside. And it's very, very much counter to the way all of these other activities are being done to the motion, to the change that we're applying. And it creates a bunch of problems. First security teams are in the critical path. So they're slowing things down. They're not continuous. Um, and that implies they're going against the business motion, right? They are slowing things down, uh, which, which just naturally conflicts with what everybody else is trying to do second and related is that the security teams are siloed. They're outside of where the core decisions are being made. So they always need to be chasing decisions that have been made. They don't have the right information they're being worked around or not pulled in when they should be.
And that results in just poor security, just insecure applications being shipped, and to make all of these things worse. Security is understaffed and it, and it's understaffed, not just because organizations are under investing in it, but rather because there's this big talent shortage, you know, 50% of jobs remain on field. And so even if you were to sort of splurge and once hire a very big security team, you can't, they're just not enough people for you to hire. And so there's, this, it's a challenge, security, security practices haven't changed nearly as much as you know, these other aspects of our technology stack. So what I would propose and again, show some examples of leaders and how they've applied. It is a different mindset to it. Think about security from a developer first perspective. And what does this mean when you say developer first in the world of security, most people immediately say shift left.
They think about shift left and she flipped is this notion that comes from the waterfall mindset, right? It comes from the fact that there's a start and an end to the development process and shifting left is earlier in the timeline. And it's a good thing. You know, like shift left is a good thing. You want to find issues earlier and address them before they become bigger. It's cheaper. Uh, it is more secure, but when you develop in a continuous fashion and this sort of infinity loop type model where he's left, you know, it's not really left. It's about continuous it's about that sort of constant attraction. You know, you can say that developers have expanded to the right. So at the very least it's expand left versus shift left. Um, but really if you're going to choose the direction in, uh, in my mind that change is top to bottom.
It's about changing ownership, uh, from being this sort of controlling entity, that's more dictatorial and kind of tells everybody what to do to more of a bottom up approach with the relevant governance capabilities. And this requires changes on both sides. On the development side, it requires some empowerment by the organization of developers to, uh, to, to have the ownership, to tackle some of these security responsibility and to equip that those teams with, uh, with the tooling, right, with the ability to actually tackle it as well. Uh, and of course, development, the development teams need to step up and own this responsibility on the security side, you need to shift that mindset and go from more of a controlling entity to more of a supportive entity whose job isn't to find the problems, understand the problems, but rather to allow or help them find the problems and understand the problems and act on the problems and that their focus is more that governance and that tooling providers.
So what we'll do now is we'll dig into each of these sort of empower developers and supportive security teams. And talk a little bit about some examples. It's not a comprehensive list of how can you achieve this? How can you help empower developers and how can you help transform security to be more of a supportive security team? Let's start with empower developers. And I'll try to weave in some examples from, from, from those specific leaders. So the first step to empower developers is to remember that you need to be building tools that look like the tools that they use, you know, that are, that are designed that feel to them like developer tools, not like security tools that have been sort of shoved down their throats. And very much like a very big component of that is to allow self-serve usage, uh, that is successful.
Uh, and it's, there are very few security companies. You stopped to think about it, very, very few security companies that offer self-serve solutions, let them self-serve solutions for developers. And they, they assume a lot of knowledge, and they're just not designed for that. Security is a governance competency. It's oftentimes sort of something that's fairly broad across the organization. And so it's not where companies have invested, but for developers, that's very, very significant. They want to be able to start with something, try it out, see it work within their surroundings. And some security companies do this very well. You know, HashiCorp vault is a great example, has great onboarding, great self-serve capabilities, uh, offer zero, which is very security. Affiliated also does a great job with sort of great documentation that allows self-serve. You have to think whether you're building the steps of tooling, uh, whether you're a vendor providing these types of solutions to others, or whether you're building these tools for your internal consumption, you have to think about how do you enable developers within the org or within the ecosystem to self-serve try that out. And it's really a predicate. It's hard to think of many successful developer tools that permeated the ecosystem that do not have a self-serve usage model.
The second, you know, that aspect that might feel obvious is to think about the problem from a developer's eyes and understand how a vulnerability made it in. When you, when you look at security, generally solutions have been built for security auditors. So their view is that when you think about the big picture view, you think about consolidating the same security risk across many applications for a developer. That's not the big picture view. The big picture view is my application in all its different facets. So I know that I pulled in these libraries. I know that I have these performance aspects. I know that it has this functionality aspects, and I want to know are security aspects within the context of my application, within the context of the actions that I've made that have all these implications, you know, security being one of them. And so this how you do this depends on the vulnerability itself or the security threat you're tackling and the world of dependencies.
You know, one thing we found to be very helpful is this notion of the dependency tree. So in this example, I could say you use five libraries and these two are vulnerable, but it's much more productive for a developer. If I say, well, you use two libraries, EJS locals and air handler. And they pulled in these other libraries that are vulnerable. It makes it much easier to understand how does this relate to my app? Similar example is in code. And I think this is maybe one of the ones that has been done a little bit better in their world of security, which is to show you in this line of code, this is the problem. This is a simple one, but oftentimes you also want to explain what is the sequence of data flow, uh, steps that you've seen that allow a malicious inputs together, some vulnerable Singh.
And you want to show that vulnerability within the context of your code here, your code had this flaw over here. And when you think about the broader scope of the app, as we talked about for the cloud, the same concept applies to your code in the context of say, containers and containers. You can, you should separate, for instance, for developers, it's a very big deal to separate the base image from what is inside the Docker file. It's very different. If a vulnerability is in the base image, you want to address it very differently, you would swap the base image. You wouldn't fix the point problem that has been, uh, outlined versus if it's in the Docker file, you know, that that's kind of your code, you know, that's the code that's written for your application. And then you want to be able to just like in that line of code to point to that line of code and say, well, here's the run command inside your Docker file that introduced this problem.
So think about problems from an application context, from a developer point of view. Um, another, like a great practice that I've really loved, uh, in the same vein, you know, comes from, uh, from segments. So segments, you know, they have a lot of really, really smart kind of AppSec practices. Uh, one of the things they do is they have this training, uh, where, you know, they have a two-part training for every new developer. One of them is this thinking like an attacker. And in that practice, every example they use is one of the vulnerabilities that was actually previously in segment reported for a bug bounty or otherwise found. And what they found, you know, as I highlight here is that it's a lot easier to get developers to care, right? To relate to this vulnerability when it's a feature that you're familiar with, right. When it's a world where it's, it's your context, it's your code.
So I love this practice. It requires a bit more work of course, but, you know, it's, you just turn it these vulnerabilities and debate education tools. And I highly recommended a third example, but sort of for examples in this sort of a and power development side is to remember the developers don't have the same level of security expertise as, as the security person. So you want to provide not just the answers, but also security questions. You know, you want to guide the developer to say, this is what's important from a security perspective for you to even probe, you know, for you to ask that question and I'll give a couple of examples here. One is PagerDuty. So PagerDuty can be use for incident response as a whole, and specifically for security incidents as well. It has a good capabilities and they did this great job writing down.
What is a security incident and what are the steps that you should do. And clearly this is the template and it can and should be customized for different organizations. But I love the handholding is to say, this is what is a security incidents. These are the questions that you need to do. This is the sequence of steps that you should do. You should cut the attack factor, you know, cut off the attack factor. That's the most important thing you can expect. Developer. You can expect developers to take responsibility to note it, to act on it, but you can't expect them to become security experts. The tooling has to embody that type of expertise, um, in, in our world, in the world of snake, see this a lot around properties of vulnerabilities. There are a lot of them are abilities. You know, unfortunately, you know, use a lot of open source and these, these are pieces of software.
They have bugs, including security, bugs, known as vulnerabilities. And so when you have too many of them, how do you help developers deal with that faster? And examples of that are sort of saying, for instance, is there an exploration in the wild and what should you ask about that exploit? Is it binary? Well, no, there's a maturity elements. So we say, okay, there is an exploration of the wild for this vulnerability and it is mature. So you should ask them to more urgency. Or when you talk about a component, help understand where is the vulnerability above and beyond? What is the vulnerability, which all tools do. It's like, this is across that scripting. This is an SQL injection. Tell me where in the functionality of this component is the vulnerability. And that makes it much easier to understand it, to relate it to my application.
So all of those are just think about the security expertise you want to embed. Um, and then the last bit I have, as an example here is, is remediation. And a simple statement is a developer's job. Isn't to find issues. It's the fix them and arguably an auditor's job while they should care about fixing is define the issues. And then they pass it on to development to fix it. They can fix it themselves. And so as a developer, you have, like, if you, as a, if you're trying to get security solutions that developers will embrace, you have to think about their full journey. You have to think about how do you get them all the way to remediation. Uh, and there are a lot of examples for it. I think in think we're fairly well known around this sort of open fixed BR, and they'll try to kind of help.
Um, I told you about a problem and also packaged it up into a pull request and tell you, you can fix it. And now a bunch of other tools are, are mimicking this functionality. We try to, can help, help simplify this. You see that sort of merge advice around telling you whether it's likely that this would break it or not. That's all about making this upgrade would break your application or not. You know, it's all about making it easy for you to upgrade. Uh, another cool example I've seen recently, sometimes you can't auto fix it, but still help support to that fixed examples. This is an example from a tool called zip code, which is not actually security focused. Uh, but when they talk about problem, they show examples of how, how it's been fixed in other repositories. So that's pretty cool as well. It's all about helping your remediation journey.
And this is a great example internally, when you think about that remediation, which is, you know, Twilio has like many organizations, they maintain centrally these internal golden images, golden base images for containers, but they've seen that developers, you know, they need help knowing when to pull them in and pulling in the new versions of those calls and images when they get released. And so what they've done is they've created an automated tools that creates pull requests to update those from statements in the Docker. And they've seen that despite the fact that I haven't done any internal promotions, because this was quite recent and the COVID-19, um, uh, change drew attention around two thirds of these PRS have been acted on. And so, you know, I love, uh, Yasha cause Roger, like he had this product security over there and I loved his comments, says you make the task as simple as possible. They do the right thing. You know, you really simplified that remediation.
So this is one side of the fence, right? It's about empowering developers. There's much more you can do around it, but just think like a developer thinking about what you would want on the other side was security team. When do you think about how do we need to adapt the security practices? And so the first and big change is aligning the organization to it. Security organizations have generally being aligned to it org for the most part, because that was the group that was addressing security. So you want to think about how do you want to adapt it to the development and the DevOps organizations have this sort of simple diagram here where you have dev Debbie's aligned to dev ops on one side into obstacle on the other side, and then you have cloud security. Where does that fit? You know, some of it is aligned to dev ops.
Some of it is aligned to AppSec in, in its nature of this activity. Some is its own thing. So you want to think about this a little bit more. I would say that this type of change comes in in three core levels. There's an organizational change, literally, who does the CSO report to, how do people align? How do we attract across the business? There's a skillset change, you know, what do you need? What are the competencies that you need in members of the security team, dealing with this problem, um, and, and mindset change. That's again, that sort of controlling entity into a supportive entity. That's a big deal. Let me show three examples from different companies on these three items. So organizational change, a great example is what in division does. So envision, uh, and this was from a conversation with Sarah Donna, who is an outside person over there, um, is that, you know, they have an AppSec person that is aligned to a preset list of the development teams.
And I think at this point, their ratio is about one to 10. I'm not entirely sure, but what, what that allows them to do is that it gives the AppSec person an ability to learn the domain of those specific applications to participate in the stand-ups, to, uh, to create that bond. And it gives the dev teams a very clear person to talk to, to build that relationship and to go to when they have a security question or a security need. So I love that pairing, it's basically mimicking what finance and HR have been doing for a good while.
So, so that's a good example. And by the way, like for each of these examples, there's a whole bunch of other companies that I've spoken to that repeats these practices. And I'm just sort of showing you one example, one anecdote. The second thing is about skillset. And actually before I talk about Justin's comment here, even, you know, Yasha that I've just mentioned before from, from Twilio talks about how he likes within his team, everybody, to at least be able to empathize to development. Uh, and so it needs to be able to code a little bit, you know, so that was one example, pretty much every security leader today, hiring highlights that importance and Justin Selenia, who a very experienced chief security officer, across many companies, he expects this to be big shift in the skillset within the world of security says, I would say security team staff will rotate about a third, maybe half for more of a process management mindset that is being done today, generally into developers.
And it points out that, you know, what does that do to the security workforce? That's a big rocking, you know, into a, do you need to lay off people and hire different people? A role include Tia who, a CSO of Tik TOK today. He was at ADP. When I spoke to him at ADP, he did this big training exercise. He invested, he put a plan in place to re-skill or up-level in the relevant skills, his security organization, and has done a very good job kind of retaining and growing that talent. Uh, but you should know, you know, as Justin says that this is a big thing, this is a big impact that will take years to, to shift and evolve into. So you have to think about the skills that you need in that team. And then, uh, last but not least, you know, the mindset change.
And, you know, I love Kelly Shortridge is just brilliant. You know, she's a security analyst and she's she the, a VP of product and strategy at capital eight. Uh, and she, she talks a lot about dev ops and security. And, you know, one of her comments is that the way they, like she likes to refer to the relationship between dev ops and security today is that they're frenemies. And I love that term, but really that inevitably these two groups are going to need to partner together. And ideally this isn't an antagonistic relationship. So it's a mindset change that goes from, I'm telling you what to do to I'm collaborating with you to get that done.
So those were big changes that are at the core to core practices, one paved road. So making security easy using the paved road is, is a concept that I think came from Netflix. These are two presentations explaining what is the Pedro, which is not just a security concept coming from, uh, from our diamond. Marcia's a presentation from Netflix. And, you know, I'll just kind of quote her because I think she defines this pretty well. So this is first, the paved road is a concept formalizing the set of expectations and commitments between the centralized teams and our engineering customers. You know, when we talk about security, what does it mean to be secure? What are the practices that you actually should be doing to get security done? Right? And the second is technology that makes that specific set of activities easy in a specific surrounding. So it's a one integrated support machinery to enable engineers, to focus on delivering the core business value that, to socialize the centralized team support.
So basically it's a specific path where there's, uh, a platform that already does a bunch of the things that you need to do very easily, you know, very well for you. So it makes it easy for you to stay on that route. Uh, and so this approach is good for a lot of other sort of dev ops technologies, and it wasn't created for security, but I had a chance to talk to Jason Chan, who who's the VP InfoSec there at Netflix. And, you know, they use that same concept for security as well, right? So it says, we call that a paved road and I loved his terms as you certainly, you can certainly bushwhack and make your way through the woods. Uh, but if you have this sort of nice, smooth paved road that gets you to the destination, you're likely to opt-in there. So it's about making it easy to make the right decision, and they do have that freedom of responsibility. And so if an individual decides, you know, if a team decides to go bushwhacking on and kind of go off road, then they become responsible for the concepts that are a part of that paper out of what does it mean to be secure? So pave road, I think is a very powerful way to empower teams, but still try to coalesce them towards the right path.
And then last than very much last, not least, uh, as a concrete practice that I'll mention is this celebrating security success. And it's amazing how often it comes out in these successful security leaders. I'll use this example for Zack powers at one medical. And he says he, he refers to his experience at Salesforce as well. And I'll just kind of read it out a little bit. So I think that's great at Salesforce. We definitely tried a range of positive incentives at which he's carried on to one medical. It says someone is a simple as high-fiving somebody for doing the right thing a little bit hard in the sort of Corona surrounding, but, um, still like this notion of just acknowledging that somebody did something well already goes a long way. Uh, and part of it is just like small incentives for bragging rights. Uh, and you know, we had this whole conversation about how everybody loves swag and around, uh, you know, who did driven security and, you know, they actually invest the verbatim at keeping it, keeping it fresh around those.
But what he points out is that if you empower software engineers, um, then, and you kind of ask them to and expect them to sort of make decisions, then recognizing them for their good decisions. And good work is a very, very important and produces great results far more than the steep approach. This came up in a lot of different, uh, conversations that I've had on the podcast. But, you know, one that really kind of, uh, I grew especially fond of is from a duo. That's now a part of Cisco and Mike Henley was the head of security there, uh, talked about how they actually built the automated a little recognition bots. So they have this friendly neighborhood security bot I'll have that term, uh, that goes off and reaches out to people and just sort of thanks them for making good security decisions. So it could be that they updated their phone to the latest release and done that, you know, as one of the first few people and they just acknowledge it.
It could be just a thank you. It could be spot bonuses to people, uh, and split bonuses to people, you know, just raising their hand and saying, Hey, there's a security issue here. So when people do the right thing, just investing in international building it, um, just for the absence of doubt, you know, I called a lot of smart people here. I do provide value as well when we're in those podcasts. You know, for instance, in this conversation with Mike, you went on to talk about how, um, you know, even little things, uh, get rewarded and that they have a set of these, uh, stickers, you know, special kind of addition of sticker that says that they were the first to report a phishing attack or something that they give. And I contributed a lot of value saying, that's awesome. I think any good rewarding system should definitely fall stickers. So it's a lot of wisdom in those words.
So to wrap up, you know, digital transformation is happening, right. And whether you like the buzzword or not, the change is very real and security practices haven't evolved anywhere near as fast. So we need to do something about that. And what I would propose here is that we need to transform security to be dead first, you know, to think about how that development teams needs to be making decisions. You know, we expect them to make decisions and to be autonomous and that everything should revolve around that. It should start from that point. And then we figure out how do we achieve it? And I'd like to leave you with one more quote from a very smart person, you know, that I had a chance to have on the podcast. And that's Adrian Ludwig, who's the Atlantean CSO. Uh, and he has this very, uh, broad kind of big picture, any I'll read out his quote, which I liked.
He said that, you know, when we worked at Google, you know, he got the call from them and they talked about Android is coming up strong and they need to figure out security. And that, that was a seminal moment for him because it was clear that mobile was an opportunity to rethink reset how we go about security. And when you think about how good mobile security is compared to desktop security, the windows ecosystem and the likes it's night and day, it's much, much, much better. And he points out that the shift to cloud is a similar fundamental shift for companies. So it's a chance for us to rethink what is possible. So I love that, you know, it's an opportunity for us to, to think about something that is different. And again, I would pause it that a start for that is this dev for security approach focused on empowered developers and a supportive security team that aligns the sort of digital transformation landscape that's for, for me. Thank you.