Mackenzie Jackson: Hi everyone. Welcome to another episode of The Secure Disclosure podcast. Edouard, thanks so much for coming on and joining me here today.
Edouard Viot: Thank you for having me, Mike.
Mackenzie Jackson: And you're the one of the founders of we just went through the name, Symbiotic. Symbiotic, there we are.
Edouard Viot: [laughter]
Mackenzie Jackson: One thing I'm always curious about, we'll get into kind of what you do in the about. What I'm curious about is why did you found this company? What was the challenge that was missing or what was it that made you see this is the edge and I need to kind of work in this space?
Edouard Viot: So, we created it 2 years ago and we spoke with a lot of design partners, prospects and so on. And the main thing that we have seen in code security is there are plenty of tools to detect vulnerabilities that you can put in your CI, for example. It will make a lot of highlights and so on. But then in big corporation, people will be a little bit lost with the results. What should I do? Is it some There are plenty of false positives. What should I do to triage them and so on? And we were feeling that a lot of companies were working on this subject, but on the SCA part. So, on the open source libraries that you integrate into your software. A little bit less on your own source code, on the result of the SAST scanner. And so, we chose to focus on it in order to have, yeah, both a better remediation, better detection, better triage on top of these code security problems.
Mackenzie Jackson: I'm really fascinated in this because code building code now has changed so much over the last few years. Where do you feel we're going with AI code security? I think maybe we can start kind of where we are now. There's a huge amount of AI bias and I have it myself. When my AI, when Cloud Code spits out something, I kind of empirically trust it. Should we be trusting this code? How secure is it? And then I kind of want to go into a direction of, do you think it will ever create perfect code?
Edouard Viot: Well, no, for sure. But it's getting better every year from the model. But you should not trust it. But it's the same thing with humans. We do merge requests or pull requests in order to make sure the developer made some right codes. It's at least the same thing with the AI. You should have a human in the loop. You should detect the problem the earliest possible because like for humans, if you spot them really after the fact, you will have a lot of trouble to refactor the code, spot the problem and so on. So, it's the same thing. The shift left stay really important with AI.
Mackenzie Jackson: So, that kind of sounds quite important what you said. So, how we've typically done code scanning is we write the code, it goes into a CI/CD pipeline where that triggers a scan and all that. And when writing and kind of taking what you just said, being that that's already quite late stage to be able to detect it now.
Edouard Viot: Yeah, especially for architectural vulnerabilities or logic vulnerabilities. For example, with an implementation vulnerability, like I do an explicit mistake into one function. If you spot it a little bit after, for example, into the merge request, it's okay. You can if the modification that you need to do is inside the function, it's all right. But if you need to re-architecture a little bit your application, you need to refactor part of the code, it will be a nightmare. So, the more you have guidelines in order to tell you or to do it the right way by design, the less painful it will be before after.
Mackenzie Jackson: And where in this current development process that we're in, so the AI development process, where should security actually start enacting this? Because as I just said, the traditional way is kind of even in the shift left way is still quite late compared to what we're doing now. Should this happen, I guess, even before the AI agent starts writing the code on his screen? Where does it actually implement?
Edouard Viot: Yeah. When you use an AI, for example, Cloud Code, coding agents, it should be directly before and after the LLM is generating the code. Like a pre-hook and a post-hook in a way. You need to give the good recommendation to the LLM in order to do it by design. And you need to have a verification layer just after to make sure there is no remaining mistake and so on. And if you spot them, you correct them directly in an agentic way. But when you give the end to the developer or to the human again, the code should be secure. Because like you said, in a PR, it's really late. Even before AI, it was a little bit too late from a developer perspective. Okay, you develop some codes on Monday, you take some time on Tuesday, you do a PR on Wednesday morning, you review it and it tells you, "Okay, John, you made a mistake on Monday. You have to figure out to refactor this part and so on." It was already something complicated. So, but it's even with AI, it's even easier to spot it directly. And correct it in an agentic way.
Mackenzie Jackson: Let's talk about spotting the vulnerabilities now because you mentioned the spotting of vulnerabilities with AI. I think a lot of people now are using the AI agent to write code and the AI agent to kind of check to make sure that AI code is secure. Previously, we kind of did it in a more deterministic way with rules and errors. Is traditional deterministic SAST dead? Is, you know, is there any needs for that now as these models get bigger? And we've seen all the headlines about how many tools are going to destroy the world and everything else, right? Where are we going with kind of these rules and scanning rules inside our code?
Edouard Viot: Yeah, it's a good question for me. You need both approach and it's not the same. For example, deterministic, so we often see SAST products could be good for explicit vulnerabilities, like, "Okay, for example, I did not check a user input. I'm storing something into a SQL database." This stay pretty interesting to spot this kind of mistake and you could use AI on top of it in order to see if it's false positive or not in a case like this. But for, yeah, architectural logical vulnerabilities, for me the AI aspect is better. So, yeah, having both approaches at the same time could be really powerful for me, not for the same vulnerabilities and not for the same way. And also, for example, AI as a judge for SAST vulnerabilities could lead to removing a lot of false positives, for example.
Mackenzie Jackson: So, it's kind of like both become important. Is it I mean, SAST has always been notoriously noisy, right? The rule-based SAST and it's because, you know, you can't really figure a function could end in what potentially could be a vulnerable sink, but there's no untrusted data in there. So, how does the tool be able to figure that out unless it can
Edouard Viot: Yeah.
Mackenzie Jackson: work backwards and with AI, I guess now it can. So, I like the concept of using both, but, you know, what are when you mentioned they're not the same vulnerabilities. What are the vulnerabilities that the AI typically finds that the SAST is blind to?
Edouard Viot: Yeah, so it's a good question. Some, yeah, if we speak about the limitation of SAST outside of the false positive, maybe taint analysis multi-file. Maybe I will explain what taint analysis is. So, let's take an
Mackenzie Jackson: Please for the audience. I know, yeah.
Edouard Viot: [laughter] But yes, so let's take a precise example. I'm developing in a Python. I will put a system function. So, system will execute a shell command into the server that is hosting the application. And so, into this function, I will inject a variable, for example. All SAST product was saying, "Okay, there is a mistake here." But maybe yes, maybe no. It depends on the life of the variable before. And most SAST engines have been created to do taint analysis. So, we look at the variable, we look at the life, and we ask many two questions. Is there any user input in it? In the part of this variable, and did we try to sanitize the user input? Which is the right way to know. And if there is no user input, it's not a vulnerability. You can remove it, for example, you know. And AI could help you on this, but you could also make another kind of engine. In fact, SAST engine has been created years ago when the PR or the MR was the good checkpoint to test it. And today, we are using a lot of different scanners. Let's say, "Okay, we'll use Open Grab for our some vulnerabilities." But, I don't know, maybe also Trivy, maybe another tool and some. And they once you modify only a line in your project, you have to rescan the whole code base. Because it's the way that SAST products are done. So, sometimes AI could be really good to just scan a small diff of code in order to have a first view, and then you will use a SAST into the MR, for example, or you could completely rethink the deterministic way in order to have another way to do scan so that you could scan only small diff really, really quick.
Mackenzie Jackson: So, so in a way, you kind of AI can can have a first pass to and and act as an orchestrator to like whether or not you decide to do a full scan and
Edouard Viot: Yeah, it could be one strategy. You have plenty of different strategies, but for me, yeah, AI is not really that important. You can't rely on AI for spotting all the vulnerabilities. You need to have some guardrails deterministic to make sure a set of rules have been checked with a deterministic way.
Mackenzie Jackson: Something that we kind of talked about offline here too is the idea about the harness we're talking about. And this is kind of a lot in security conversations and talked about now. So, I guess, you know, for the audience,
Edouard Viot: [laughter]
Mackenzie Jackson: how does the harness in this situation work? What is kind of an AI harness and how does that fit in the security scanning landscape?
Edouard Viot: Yeah. So, yeah, in fact, if you look when an AI is producing some code, it's a model and an LLM, an agent and a harness, so for example, Cloud Code, that will be orchestrating everything. And in years ago, only the LLM was available. You were sending a user prompt and a system prompt to the AI. It was answering some code, and that's it. Right now, since we are really agentic, harness and the system prompt it is using is making a large part of the work, in fact. So, 2 years ago, we asked ourselves, "Okay, how should we approach the security?" We made some experiments by doing a post-training on some open weight model, for example. We continue to do this kind of research. But, as a developer, you like a lot of models. You want to rely on Anthropic model, for example. In the last two years, this developer were willing to use Opus, for example. So, post-training some model was interesting, but not really for us. So, for us, it was the right place. Being able to have the full control of what is going on on the generation of code with the right open interoperability, not only being a skill or a plugin, but having the full control of all the prompts and interacting with the LLM was the right angle for us to be able to make security on the code that is being produced, but also on the agency itself.
Mackenzie Jackson: One thing I'm curious about with harnesses is how important are the harnesses in relation to the model itself, right? We see all the models getting better and better, and, you know, OpenAI has had the incident with Hugging Face, and then Anthropic said, "Oh, yeah, our models also do that." You know, like they're just competing about felonies.
Edouard Viot: [laughter]
Mackenzie Jackson: But, you know, does the does the harness change the results in a way more or less than kind of how the models interact? Like
Edouard Viot: A lot. In fact, in the harness, you can do plenty of things, like a knowledge graph of your code base. You can give a lot of things to the LLM to do a better job. And just saying to the LLM, "We have a vulnerability, please solve it." I think you are kind of GPT wrapper if you do this. So, you need to be able to provide some tools. A harness will use some tools. Some of them are really basic. It's read some file, grep some file to find some patterns in it, and so on. And you can develop your own tools when you are the Harness giving some information about the security of the vulnerabilities, and so on. So, being able to do better remediation with the Harness with all this information, and so on. And also, the guardrails are really important. For us, a guardrail is a way to do a feedback loop between a remediation and the future development. Let's take an example. We both have worked into the secret detection part in the past. Let's say, "Okay, I put an hard-coded secret into the source code of my code." I use Port it, for example, and my remediation will tell you, "Okay, it's Python code. Let's grep the .env file, for example, and I will put the secret in it." And then, maybe the developer will tell me, "Okay, but last week we decided to buy a vault like HashiCorp. It's a new rule into the company to use it. You have to remember it because as a developer, if you tell it one time, it's okay, but if you have to remember five times a week that we bought HashiCorp, it's a silly product at the end." So, our job is also to remember from the remediation from the good remediation, and put it into some guardrails in order to tell the LLM, "Okay, next time you have a secret, let's use the HashiCorp vault."
Mackenzie Jackson: Yeah. And because there's nothing worse than when you're like when you're studying your session with your model and it's just lost all the all of its memory, and then you have to explain, you know, or it has to waste a huge amount of tokens going back through your code base to figure out what the heck you're building. You know, like, so that that makes a lot of that makes a lot of sense. Another interesting thing that I'm always curious about too is the prompts themselves to generate the code.
Edouard Viot: Yeah.
Mackenzie Jackson: We did a silly experiment. This is, I think, a year and a half ago. So, 400 years in AI time. Where we we kind of live-coded lots of mini-apps and we did it twice. With a single prompt and the second time we did it, we asked it to make sure that it was secure. And it improved the vulnerabilities. Is this something that you're seeing or interested in and, I guess, the official word, prompt engineering, when we're generating code how important is the prompt to make it secure and what can we do to improve that?
Mackenzie Jackson: I'm going to briefly interrupt this episode to thank our sponsor of the podcast, Aikido Security. Aikido Security is your complete code to cloud security solution. It secures everything from the first line of code that you write all the way through your supply chain, your dependencies, and of course, Aikido is also a leader in AI pen testing and AI code auditing. So, make sure you check them out today. You can start for free at aikido.dev. All right, enough about that. Let's get back to the episode.
Edouard Viot: What you are saying is really good because the AI is making a lot of security mistakes, but if you ask the same AI to check from its mistake, it will find a part of them. Yeah. It's like a bad student that has the knowledge, but don't want to is too lazy to in a way. But yeah, the prompt is really important. Especially for me to the LLM general knowledge about vulnerabilities. They know what is an XSS vulnerability, what is a SQL vulnerability, and so on. What the harness should bring is the link between what is specific in your project. I use this framework, this library, and so on and this general knowledge. And the link in the harness is really important. Because, for example, you don't remediate or you don't create some varieties the same way in two companies. Because you have some coding different coding convention and so on. So, it's really important to be able to make this link between, yeah, what is our way to do software at this company and what is the generic knowledge. And you need to inject it the right way into the prompt so that the code is already secure in a way.
Mackenzie Jackson: And how I want to kind of just double tap on that. You said you need to be able to inject it into the right way into the prompt. What does that kind of mean? Because my idea is like, I mean, the prompt is the prompt. So, what does that mean by like way you put it into the prompt or
Edouard Viot: Yeah. So, you can have, for example, some knowledge base that you pick insights. You say, "Okay, we are in this project. This project we have this, this, this to remember and so on." And we you catch your system prompt. And what the user will write is the user prompt. So, you have the you can append everything that you want into the system prompt, which is really important. So, a good harness will have himself a knowledge base that will create this prompt and it will not be the same depending on the repositories that you use, for example.
Mackenzie Jackson: And like how what variants do you kind of see in and how our how code is generated with correct prompts versus incorrect prompts? I mean, it's an impossible question because I'm asking something, but what I'm trying to try and figure out is how much should developers be thinking about the prompts that they're going into because myself, you know, I just write stuff and say, "Go," you know? And I love the idea of having this system prompt, you know, that with the knowledge base and everything, but, you know, how much how much effort should be put into how we craft craft our prompts.
Edouard Viot: Yeah, that's a good question. You have different answers for me. The good products will not ask so much to the developer, to be honest, because it's in big corporation, you know, you have plenty of new employees coming.
Mackenzie Jackson: Right.
Edouard Viot: You have plenty of external guys and so on. And your job in a way is to to do the same kind of security no matter what the developer is. So, we are more asking, for example, when we enter into a new client, we scan the code base, we we generate some some rules which are not the SAST rules, which are some architecture rules, some, "Okay, for example, on this project I have one microservice being able to to speak to the database. It's secure. I'm sure we tested everything is secure." But a new guy not knowing the architecture will directly connect to Supabase and do some stuff. How do you prevent this? It's a kind of a behavior that you should detect, violation of a policy that you should detect and turn to the developer, "No, you should do like this." So, for me, the right way in a way is to be educational. It's to have something into your system prompt saying, "Okay, he's trying to make something in his behavior, but it's not really aligned with the philosophy of the project. I should tell him, I should have a proposal in order to do the right stuff."
Mackenzie Jackson: Yeah, my brain didn't really That makes so much more sense now that you've explained that as as like the system prompt is an organizational
Edouard Viot: Yeah.
Mackenzie Jackson: wide thing because I'm always thinking about file coding for me because it is like it's always such a personal thing because that's what I'm working on. But now I'm thinking about it as like, "Yeah, of course you want a standardized system prompt for your organization
Edouard Viot: Yeah.
Mackenzie Jackson: to get everything." Because, yeah, that that makes that I I guess ultimately my question was fundamentally flawed because I asked how much should developers think about their system prompts and the answer is kind of zero because it should be there for them and they just need to think about it.
Edouard Viot: Especially for especially for big corporation in fact. If you have a company with two friends, you don't care to have some huge architecture or maybe you should, but
Mackenzie Jackson: [laughter]
Edouard Viot: but you don't care at the end. But in big corporation, how do you make sure you have some rules that are lying. And today a lot of people are using agent.md file.
Mackenzie Jackson: Yeah.
Edouard Viot: For me, it's not the right format. It's not the, it's English that you write. You hope that it will be taken into account by the LLM. If it's too big, you are not sure that every recommendation will be into account and so on. And here you should put a little bit more of deterministic approach for me.
Mackenzie Jackson: Yeah.
Edouard Viot: To make sure every you you generate these rules with AI. You validate it with human, but you use also deterministic to make sure they are applying to the code.
Mackenzie Jackson: Right. So, yeah, and that kind of comes back full circle even on this layer is that, you know, the deterministic scans that we do are not are not dead. They're still very relevant and they're
Edouard Viot: But they need to change a little bit. They, yeah. Today they have been created 10 years ago or 5 years ago for the PR or the MR, they need to be recent a little bit.
Mackenzie Jackson: Yeah.
Edouard Viot: And, yeah, they need to to to be written in two different format for me. Like more working to kind of AI memory of the code so that you don't have to re-parse the codes each time you do a modification and so on. Yeah.
Mackenzie Jackson: Well, that's kind of I want to go into a slightly different direction now. Something I've been asking a few people and something I'm curious about. It's kind of what what is like most terrifying for you about kind of code and AI generation? And what's most exciting about it? But let's start with kind of what are the biggest concerns that you have in the space seeing this AI generated code everywhere? And knowing that we can't put the cat back in the bag. Like almost no one's going to go back to writing code character by character, no matter what happens.
Edouard Viot: For me, if you look, senior developers are more skeptical with AI. They use it, but they they use it not everywhere and so on.
Mackenzie Jackson: Mhm.
Edouard Viot: And at the same time, they have the knowledge. They they learned to code without the AI. They they are skeptical, but they they have also ways to make sure the code generated by AI is secure. If you look and it's not Edward Snowden, this. There are plenty of studies and so on. But if you look, junior developers are embracing AI, which is really cool, but they may not have yet the everything to
Mackenzie Jackson: the foundations.
Edouard Viot: Yeah. Yeah.
Mackenzie Jackson: And they're probably not, I mean, I don't I shouldn't make general statements, but like it will be harder to build the foundations. It's the GPS situation, right? No one knows how to find their way back home anymore because they rely on GPS. So, your phone dies, you're, you know, you're screwed. It's very similar with the coding
Edouard Viot: I guess there is a new meme like the 'used to could affect' so the less you know about something
Mackenzie Jackson: Yeah.
Edouard Viot: you know, and for me we are printing to this this problem with with junior developers. And then, yeah, it's why for me we need to be educational way.
Mackenzie Jackson: The thing that scares me most about AI generated code is that every time I ask it to do something that involves any authentication and authorization, it writes it itself.
Edouard Viot: Yeah.
Mackenzie Jackson: And I'm just kind of like, "What?" Like this
Edouard Viot: [laughter]
Mackenzie Jackson: Like, "Please don't." Like, and then you have to go in and tell it like, which is fine. I mean, we should be telling, but but this is kind of what scares me is that the default is to build your own, like, the most important part of application security access control is still number one in our OWASP Top 10.
Edouard Viot: Yeah.
Mackenzie Jackson: You know, broken access control all that and then we're writing our own authorization which even if it gets it perfect, it's such a complex thing for the application that it it it's a very difficult challenge for anyone to get right.
Edouard Viot: Yeah. What most excites you?
Mackenzie Jackson: Well, AI generated code.
Edouard Viot: To be honest, it's it's always the same thing, but this bit, for example, like
Mackenzie Jackson: Yeah.
Edouard Viot: We we have a big US customer, a big bank that made all their backend into a Scala programming language. A Scala is a formal programming language. And if you look at the security, for example, most of the state of the art is on a Scala security, it's quite nothing to be
Mackenzie Jackson: Right, yeah.
Edouard Viot: And and if you look at all the SAST product and so on, they were nothing. But they were we have a PR in the OpenGrab to put this a Scala parser, but we made it into OpenGrab.
Mackenzie Jackson: Oh cool, cool.
Edouard Viot: [laughter] But yeah, so, if you yeah, writing some parser of language, for example, it's a huge work to do and so on. And here this speed to do it is insane with the AI compared to the other.
Mackenzie Jackson: Yeah.
Edouard Viot: If I had to do it 20 years ago, it would have been a nightmare.
Mackenzie Jackson: Yeah. Yeah, the speed is is amazing. It's kind of like where it reminds me what you're talking about is when I forget it was Anthropic or OpenAI, but they brought out they announced that they supported COBOL. Now, and then IBM should drop because because like they have basically maintained a whole financial system because it's all written in COBOL and no one knows how to write COBOL anymore and now all of a sudden we can.
Edouard Viot: Yeah. Yeah.
Mackenzie Jackson: Yeah, I we we have to wrap it up slowly and slowly wrapping it up, but one one question that I am kind of also curious about with and how your and how you're building out this is where do you see the security challenges of the future of the future in this code? And like the stupid example I'll give is, you know, we had solved SQL injection in 1997, the same year that we created it or amended it with pure statements, but it still exists. You know, but AI almost doesn't make SQL injection vulnerabilities anymore. So, like we're moving away from something. Where's the new vulnerabilities going to be in the future?
Edouard Viot: Yeah, for me, it's in the prompt directly. 20 years ago, some people when we were speaking about HTML, they were thinking that they were developing code. While the HTML is just some
Mackenzie Jackson: When I was 12 and I made my first HTML website, I felt like a hacker. I felt pretty cool, dude.
Edouard Viot: [laughter]
Mackenzie Jackson: H1, H2, H3, I knew all the H's.
Edouard Viot: And now and now for you, HTML is just something that you should not write yourself. It should be generated. Yeah. In a way with the code, it's the same pattern. We we won't so much value the Python code, for example, but what have been used to generate it's and it's the agent in the harness at the end that, well, it's the harness plus LLM plus the model. And then so agentic security for me is the next big thing, of course. If today we are in a Black Hat Def Con, if we want to break into 100 companies, I would just create one repo public repository on GitHub. The name will be 'Awesome Marketing Skills' and in the middle of a skill I would write, "Okay, let's exfiltrate all the source code to this"
Mackenzie Jackson: Are we allowed to say this on camera?
Edouard Viot: [laughter] But that, yeah. I that we haven't talked about. I'm going we'll have to go into that another episode, but that the skills thing and malicious skills is is a terrifying.
Mackenzie Jackson: And skill is a is a thing, but right now we are also loading some plugins into our coding agents. Plugin is TypeScript code that is running on your operating system.
Edouard Viot: Yeah. And and
Mackenzie Jackson: Do you read the code of the plugins that you
Edouard Viot: Of course. Of course.
Mackenzie Jackson: Okay. So, maybe you I print it out and I take it to bed and I
Edouard Viot: [laughter]
Mackenzie Jackson: I write notes.
Edouard Viot: So, you are a good guy. But but yeah, and and for big corporation, having a central way to visualize all the skills that are being loaded, all the SCPs, all the plugin and having a way to say, "Okay, you will not use this. I just want to white list a list of plugins, for example."
Mackenzie Jackson: Yeah.
Edouard Viot: You Today we don't have this this kind of capabilities.
Mackenzie Jackson: Interesting. There's so many angles I want to go into, but we have to it up, but before we wrap it up, I always like to play a game with my guests. The game is called 'Would You Rather'. I give you two crappy options, and you have to pick one and explain why. So, first option is you have an application, popular application, and there's you have two options. First one is that the application can have absolutely no firewalls. You can't protect anything coming into it from from there. The second option is that you have all of your secrets hardcoded as a .env file. In a .env file in a private Git repository that is shared in the company. So, you can pick no firewalls, so all traffic coming in, no way to list it, or nothing public, but we know.
Edouard Viot: [laughter]
Mackenzie Jackson: Have risk of of secrets, so
Edouard Viot: We both come from GitGuardian, so I can't answer the second one.
Mackenzie Jackson: [laughter]
Edouard Viot: No, it's to be honest, the secret is a big issue. We have seen plenty of stories like your repository is private, you push it in public by mistake, and then you have a 3K secret to remediate in a few hours. So, no, I I prefer without firewall and so on. For me, yeah, firewalls are protecting from the outside.
Mackenzie Jackson: Yeah.
Edouard Viot: The application should be secure from the inside.
Mackenzie Jackson: Yeah.
Edouard Viot: And secret is a mistake in the inside. So, I would rather take one application without
Mackenzie Jackson: Okay. All right, Eric Foyer will be happy with that answer.
Edouard Viot: I hope so. [laughter]
Mackenzie Jackson: He's in Vegas, by the way.
Edouard Viot: Oh, we did a podcast.
Mackenzie Jackson: Okay. We did and I asked him these shitty questions, too.
Edouard Viot: [laughter]
Mackenzie Jackson: All right, here's another one. Same scenario, you have an application, but you're you're building out the application. There's two ways. One is that you don't know how to code, and no one in the team, and no one in the world knows how to code. So, you you can only create this application through a prompt. You know, you can't read what's happening in the user prompt, AI generates the application and we put it out there in the world. Or, you cannot use AI to create the application. You have to go back and write it character by character. Which would you rather?
Edouard Viot: Okay. Okay, interesting. I would say the first one you're using Symbiotic Code.
Mackenzie Jackson: [laughter] That's cheating, but I'll allow it. I'll allow it. We'll do one more then we'll then we'll finish up. There's been a lot of supply chain attacks recently, so this one's particularly nasty. Would you rather pin your dependencies, but they're pinned on this version forever? So, as CVEs get created, you're at the risk of of vulnerabilities. Or, auto update auto pull dependencies every time you build.
Edouard Viot: I would say auto update, but if I could put one week of delay.
Mackenzie Jackson: Right. You can't.
Edouard Viot: [laughter] So, so here is the the reason is that, yeah, in both cases it's a nightmare.
Mackenzie Jackson: Yeah.
Edouard Viot: I would say the second one with an auto update like a Dependabot.
Mackenzie Jackson: Yeah.
Edouard Viot: But, we all know that, yeah, it's going, yeah, it's it's going to be bad. But, for me the one week of delay is perfect.
Mackenzie Jackson: Yeah, for sure. For sure. 99% of malware is although again from open source malware was far too mellow last night, so I'll be interested. I'm sitting on her lap right now, so I'll see what she says. But, Emma, thanks so much for coming on. Appreciate it. Can't wait to see the journey.
Edouard Viot: Thank you.
