Runtime

"It's prime time for runtime!"

In this episode of the mnemonic security podcast, we're joined by Sergej Epp, Global CISO & Member of the Executive Team of Sysdig, to discuss threats at machine speed and runtime security.

Sergej explains how runtime security enables organisations to understand what is really happening inside containers and serverless workloads, and why, without it, they are effectively blind to critical activity within their cloud-native environments. He shares recent examples of supply chain incidents that highlight these risks, including the GitHub Actions compromise, NPM attacks, and the two waves of Shai-Hulud.

Robby and Sergej also discuss the most common ways that attackers get access to clusters and containers, and how organisations can stay ahead of attacks using real-time telemetry.

Transcript

Speaker 0:03

From our headquarters in Oslo, Normal, and on behalf of our host, Robby Peralta, welcome to the mnemonic security podcast.

Robby Peralta 0:15

Runtime, runtime, runtime. Not guardrails, not promises, runtime. Because it's not about what the model says, it's about what the system does. The truth lives in the execution. What processes are running, what are they connecting to, what identities are acting, what data is being touched. If the behavior matches the intent, allow it. If it deviates, alert or block. This isn't new. Cloud natives have worked here for years. But autonomous agents change the blast radius. So as today's guest said, it's prime time for runtime. Sergej Epp, welcome to the podcast.

Sergej Epp 1:08

Thank you, Robby.

Robby Peralta 1:09

Where are you joining us from today?

Sergej Epp 1:11

I'm uh based in Frankfurt, Germany.

Robby Peralta 1:14

A busy man you are. I see that on your LinkedIn, you have like eight jobs. It says like present for like eight different things. So of all these uh great places and fun roles that you've had, it seems that you chose to sort of dedicate your future to the concept of what we're gonna talk about today, runtime security. What does that mean to you, runtime security?

Sergej Epp 1:36

Or runtime security is really the ground truth where you sort of see what's really happening. And I think in security, we tend always to go first of all for visibility. That's the first principle in security. You always want to understand what is really happening out there to be able to judge what good looks like, what bad looks like, where we can stop things, where we have to improve things. Take, for instance, the traditional endpoints, the traditional antivirus world. Remember how it was evolving. We had initially some checks which would run once in a day, right? And then we've evolved towards real-time telemetry where we as a security team could start judging on what's really happening. And this is really runtime to me. So if you think of uh configuration checks or cloud security being more or less like a photograph, right? Where you just do a snapshot and you check this once in a day, runtime is more like a video where you can gather real-time stream and you can judge on what's really happening across the environment and whatnot.

Robby Peralta 2:41

You said that uh like in the on-prem world, EDR is number one control for your cloud and containers, runtime security is number one. If everything else fails, runtime security is the only way to detect and stop attacks for lateral movement. You still agree with that? A year later?

Sergej Epp 2:56

Oh, yeah, I think it's it's more true than ever. We saw during this year a lot of different security events which just not just confirmed this statement, but accelerated this to a massive degree. We've seen multiple crazy supply chain attacks this year. I mean, just remember back beginning of the year it was TG Actions, which leaked um, you know, CICD secrets. We had multiple NPM incident attacks. We had two waves of shy halut uh Maw, which impacted thousands of organizations out there, more than 25,000 um repositories. And I think such supply chain attacks are really good proof that even if you're controlling your code security and part of your CI CD pipeline, it's very hard just to understand if you secured your code uh 100%, right? Specifically with Shai Halut, I think we we saw this very, very smart way how the attackers tried to first of all uh take over certain npm packages, right? Having then multiple scripts being installed, pre-post installed scripts on CI CD pipeline, then having really um, you know, a scan for NPM, uh NPM access for secrets. If they would find something that would try to register then self-hosted uh GitHub actions in order to uh connect back and use this really as a foothold into the organization. So very smart way how it would orchestrators to get access to the environment. And then, you know, the the uh the outcome of this was let's just quietly exfiltrate secrets, right? And what it could would give to them is first of all, they can like in a virus, in a classical virus, they could spread very, very quickly. And then compared to classical virus, it's not that you can just supply certain uh detections and stop them or patch your operating systems. You have really, as an organization, to identify if you're impacted where all the secrets being used today. You have to rotate the secrets, which is a very, very painful task. So I think having seen this type of supply chain attacks, it was it was pretty obvious to all the organizations out there, securing and controlling the code is not enough. You have really to assume breach, you have to ensure that your runtime secured, your production environment is monitored, is secured. And then, and that's the second point, I think, where we're starting to see some demand, you have to be able to explain as well what happened in case something happens. Because now imagine such a scenario where you're hit by a supply chain attack or by a target attack, even what you have to do is you have to go back and try to reconstruct what happened across your environment, where's the attacker hiding, what has he done? Did he deploy some other malicious workloads, some other credentials he was exfiltrating, just to be able to derive the most basic response to this attack? So if you don't know what happened, you can't really derive a proper response to this attack. And this is where runtime security becomes essential because obviously all of your workloads they're running in runtime, they're running in Kubernetes within containers. That's your ground truth. Runtime is your ground truths, where if you don't understand this, you have to take a lot of assumptions. And if you have to take a lot of assumptions, it creates more work and it increases as well the risk for the organization.

Robby Peralta 6:30

And the traditional approaches, I'm thinking of SIEM, EDR, they don't go to the level that runtime in these cloud native environments really require.

Sergej Epp 6:40

No, absolutely. I think this uh picture which is being always painted is that cloud detection response is like an EDR, but for the cloud, which is not really true because in the cloud, the cloud works completely different. It's first of all a very dynamic environment where it's not just about really getting the visibility into the container, but you have to stitch all this information together with the entire orchestration stack. For instance, the Kubernetes stack you're using. There are multiple different ways how lateral movement can happen. And most of them really features rather than bugs if you compare this to a traditional environment. Now, again, it's not enough just to look into the runtime. You have to stitch the orchestration layer like Kubernetes, but then also all of your cloud information, cloud looks, because this is how the attackers would typically move going forward if they get access either through exploiting your application or getting one of the credentials you've been using. And that's where it's becoming very, very challenging to really, from a security point of view, to understand and triage even basic alerts within your cloud environment. If you see only the posture part, the configuration part of your cloud, or only the runtime part of your cloud, you can't really create this understanding of attackers movement, of potential actions he has performed. So you have to have both. But runtime is typically the foundation because this is where most of the data lives, and uh most of the data is also being produced by applications and by by the attackers as well.

Robby Peralta 8:21

What an impossible job reactive security has these days. Like they're if they were struggling with like SIEM and EDR and kind of like the old traditional security methods, are your teams combining all these alerts into one, or how does that look for in your experience and in Sysdig?

Sergej Epp 8:39

I think specifically cloud security and Kubernetes security is uh like a completely special novel skill, I would say, for the cybersecurity teams. Uh at Sysdig itself, we have as well this capability being split. So the team members in my team who are focused on cloud security, securing Sysdig with Sysdig as well, obviously, they are they have a different background. Most of them are engineers or were engineers in the past. In order to really being able to triage, understand what is happening across your cloud, to interpret the alerts, you have to have the understanding how the entire engineering ecosystem is working. While the the typical EDR or you know AT, and we don't have really a lot of AT because we are we are cloud native, but these alerts are handled by different team members. And again, this is not just applicable for Sysdig. If you just look at any other company, let's say 95% of SOCs out there, they don't have really a very deep native expertise on how to handle cloud security alerts, besides just looking at a dashboard of a specific tool and trying to understand is a tool telling me something bad happens or not. So being going really a level below this is sometimes possible, but in most organizations, I think we don't have really this expertise. And this is, by the way, also true, just to add, for the attacker side of things, they're always trying as well to follow the least difficult paths. And I think container security in general is very difficult, right? Going beyond and scanning your cloud infrastructure for open S3 buckets requires really understanding how Kubernetes is working. It requires understanding if you even if you like got access through a vulnerable application to a container, how do you move lateral? Uh all that is not really trivial for people who are not familiar with cloud infrastructures. And I think that's why they would just typically choose then to go and attack another company, right? Or try to find another approach how to monetize, for instance, a criminal activity. And I think now this is starting to change simply because the barrier to learn new skills, to learn new environments is becoming very easy, right? We saw multiple nation states, for instance, just intercepting satellite traffic and then using LLMs just to analyze that. Everyone can just ask and prompt his favorite LLM to understand how do I move lateral if I now got access to this specific mainframe? What kind of command should I type? Tell me more about this. And the smart ones, they even potentially going to try to apply computer use, right, to automate all that.

Robby Peralta 11:15

Right. What is this sort of threat model for clusters and containers? What is like the most common way to get into these environments?

Sergej Epp 11:23

They are not significantly different to traditional environments. So a common attack pattern is just to be able to compromise a specific application. Let's say you've uh you've written application and there's a vulnerability like a SQL injection or anything like that, like direct retroversion vulnerability. Somebody with this access could then be able to execute code on a container, right? And then he could do next steps and you know try to find, for instance, certain credentials being mounted to this container, trying to analyze the applications, uh, the application code running on this container, drop a malware, uh, whatever. There are multiple endless steps how he can go further. A second way, a classical way, would be to be able to identify certain stolen credentials, for instance, from your cloud environment or secrets. This is what we've seen with the supply chain attacks, where uh there were multiple very smart ways to really get access to the secrets or credentials. And a big challenge, specifically in the cloud environment, is that it's very hard, the cloud is very open, right? And you can't really have a clear understanding as an as a responder how to understand if a specific credentials is being misused by somebody, or if it's really your team accessing this. There are multiple controls you can implement in addition to this, but for random cloud, it's not it's not that easy. And then the obvious way we've already for the last 10 years is you just try to scan for misconfigured workloads, for instance, like uh S3 buckets, uh, where you find a lot of data and then you know misuses data. So I think these are the the the three most obvious patterns, what we would see, but there are many other ways as well how a cloud can be compromised to attack.

Robby Peralta 13:10

Yeah, so a lot of ways in, and once they are in, it's not trivial to see what's going on unless you have the the right telemetry, the right people, the understanding of how the application works. We've been lucky so far then, since the since people haven't been focusing on uh the these cloud native environments.

Sergej Epp 13:28

No, exactly. I mean, it's such a complexity, it's also the speed of the cloud where everything is changing literally within a minute. So what what we see is that 60% of the containers across our customers are being renewed every minute. So imagine a worker is living class in a minute. How quickly can you react as a human? How quickly can a machine react? Let's say if you're even going to take all the logs from this specific container, send them somewhere to a sim system to analyze them and correlate them and send them back. Very often it's just not enough time, even to take a counter reaction if something happened, something executed in this container going forward. So I think that's one of the biggest challenges. It's not just the complexity, it's also the speed of the cloud, which you have to account for.

Robby Peralta 14:17

And a lot of data. You guys have to process a lot of data to be able to catch those attacks.

Sergej Epp 14:21

Oh, yes, absolutely. I would say like 60% of the data we're looking at is runtime-based and not really cloud-based, simply because that's where you'll see a lot of activity and where you can reconstruct as well uh what a specific, you know, malicious binary was trying to do, right? And uh, if you don't collect for this data, if you don't account for potential post forensics, this data will be gone.

Robby Peralta 14:44

Yeah, right.

Sergej Epp 14:44

And if the data will be gone, you'll be simply not in a position to explain what happened. So you have to take a lot of assumptions and uh potentially reboot your entire cloud, right? Because of that. And that's what we're trying really to counter.

Robby Peralta 14:57

Yeah. Interesting. So now I want to move on to this post I saw from from Joe Sullivan. So the uh ex Uber.

Sergej Epp 15:04

I know the post you know.

Robby Peralta 15:05

Yeah, yeah, exactly. ex Uber, CISO. Uh he had a post. Let me see what it says here. Someone asked, What is your word for 2026? And I immediately said runtime. And I won't read out the whole entire thing, but basically he said, the best bang for the buck will be investing in visibility at the time the AI agents are in action. What do you think that he what do you find interesting about that post? And maybe explain it too, just because I didn't explain it very well.

Sergej Epp 15:35

I think what's important to understand is AI security is really just cloud native security done right. You can just simply replace one application, the container, with an EI agent, right? And now we start to to talk about the same type of controls. Now, the big difference to EI agents is that they're much more easier to compromise. We all know that the problem of prompt injections cannot be mitigated. We have not found as an industry solutions for prompt injections, and therefore we have to assume bridge. Again, in the same way we're assuming bridge in a cloud environment with classical workloads, we have to do the same as well for AI workloads. And also, on the other hand, I mean, which company is not using today AI coding agents like cursors of this world in cloud code, more code being pushed to production, very often as well, bypassing the traditional CI CD pipelines in some organizations, which is crazy at all. What it creates is much more insecure code in your production environment. And again, runtime is the ground truth. This is where you see what's happening. This is where you see not just isn't EI model secure or not. I mean, we can't really prove if the I models are secure, we can't really look inside. It's not possible mathematically from a mathematical point of view, but we can see the actions the models are performing. We see can see the actions our traditional programs can perform. And based on this, we can judge if an action is good or bad. And I think that's just enforcing again that it's uh it's prime time for RAM time.

Robby Peralta 17:16

Prime time for run time. To get a name for the episode, I guess. When it comes to AI agents, I know that uh Sysdig works with the companies that take these things, these matters seriously and have big budgets. Have you actually seen this sort of AI agents rollout yet? Is it is it just marketing or is this actually happening?

Sergej Epp 17:35

No, look, I think so. There are two perspectives on this of Sysdig for Sysdig. Um, Sysdig is a pioneer in eBPF-based container-based technology. And what we did is we have donated the first eBPF probes and a project we call Falco to CNCF. Falco became de facto the standard for Kubernetes security and container security in the world. And to give you some data points, 60% of Fortune 500 companies are using Falco. And this includes as well a lot of early adapters of container securities like telecommunication companies or neo clouds and AI labs. And that's where we started to see already uh two years ago, quite a lot of activity. Obviously, a neo cloud is about running agents, running AI workloads, in the same way EI labs facing the challenge that when they've turned the EI chatbots from just being a chatbot to be able to have a memory, to be able to perform an action, you give effectively to this chatbot the permission to run code. And you have to account for potentially the code for the IAG, first of all, to be lured by a prompt injection and then for malicious code to run across your environment. And the only way is really to be able to observe what is happening across your containers, what kind of code is running. And that's where we saw a lot of consumption. We're starting to see some industries being very, very aggressive around not using just the API from Open AI or cloud, but running their own models. So there's one pharma company, for instance, uh we have talked recently to an AI lead. They saw more than 10,000 downloads within the environment of models like DeepSeek and so on. And that just shows, once again, there's a lot of experimentation going on. Now, do we see a lot of the AI agents being run in production already? I don't think that's the case. Um, but I'm pretty sure we're going to see this year specifically a lot of those POCs going live.

Robby Peralta 19:39

That's actually an interesting example. If somebody downloads uh one of these on-prem models, do you need a tool, let's say systig, to be able to understand what's going on in the inside of that? Because you can't really, if you don't have that, you don't have visibility in what it's doing, or am I thinking wrong?

Sergej Epp 19:56

Oh, yes, absolutely. I mean, if somebody runs an AI model, you would run today in the i model in a containerized environment. So it runs in a container. And then if your container can execute commands and or run code, and today, if you just ask um, you know, any smart command, like even parser PDF file, uh, in most cases, this LLM models would create uh code and then they would execute this code. And now what you can do is you can first of all try to sandbox this as much as possible. But on the other hand, you will still have possibilities, how you can run code in non-secure environments and where you simply have as well to account to understand what is the attacker really doing. So if somebody will try to break out out of the sandbox, even if somebody sandboxes uh this container, you need to understand what is really happening. Is the attacker trying now to run malicious code? What is he trying to achieve with the code? Is it, you know, sandbox escape? Is that getting access to certain critical files? So all that will be visible to you only by looking at the runtime level, really trying to understand what kind of commands are being run, what is happening across your container, what is the code trying to do. And that's where um both Falco and Sustic CNAP can support um the security operations teams, but also platform engineering teams um to reconstruct these activities and be able to react fast in case there's an attack going on.

Robby Peralta 21:24

And this is a very dumb question, but there's no hands-on keyboard for these attacks, right? This is all automated actions that are being done by the attacker.

Sergej Epp 21:34

Yeah, I mean, obviously there's a lot of um a lot of possibilities to do things manually, but uh yes, a lot of this attacks start to become more and more automated. We saw already two years ago the first attacks from a scanner happening up to the attacker came in, uh, took over an AI workload, installed a cryptocurrency miner, moved lateral, tried to identify certain critical data, uh, leaked the data. And all that happened within less than five minutes. So this type of attacks are becoming very automated, and specifically now, EI, Gen EI is really good at uh at offense, being able to automate not just the specific atomic commands, specific atomic steps, but the entire orchestration stack of your friends of operation.

Robby Peralta 22:24

Right. Interesting. So the Sysdig product that is just logging a lot. And then you guys, I'm assuming you have some sort of AI in there that is helping the whoever's looking at the logs to stitch things together and make a timeline and to paint a picture of what's going on.

Sergej Epp 22:39

Yeah, absolutely. I mean, I think that there are multiple levels of how you would try to understand what is happening. So, first of all, we have a huge community around deterministic rules on what bad behavior looks like and what good behavior looks like. And the AI is not going to replace that. The AI requires deterministic verifiers to be able to succeed. And then we do have a lot of behavior-based uh detections on top of the stateless, stateful detections, which we're all using to explain the activity of a specific workload, of a specific identity, and basing this, alert this back to the analyst for further verification.

Robby Peralta 23:20

So you wrote a paper winning the AI Cyber Race, verifiability. Verifiability is all you need. But what is your main point there?

Sergej Epp 23:31

Yeah, sure. So um Jason Wei, who's an open AI researcher, he wrote a summary in 2025 around the verifiers law. And it was a blog post which really just pointed out that EI learns fast when you can easily check if it's wrong or right. It's very simple. I mean, think Sudoku, for instance. It's uh very, very hard to solve, but even a five year old can verify the answer if it's correct or not. And this fast uh feedback loop is really gold for both for training AI, but also using uh agents and inference, for instance, right? Now, think about a counter example to this, like a diet. It's easy to come up with multiple diets, but then the verification will happen after a couple of months or after a couple of years. So it's not that easy to verify from the eye this type of problem set. Now, the proof for this is if you just look at all the different benchmarks which were created around the eye, take mathematics, take uh coding, take reasoning, all this benchmark. If you can measure something, the eye was able to solve that literature within a couple of months or a couple of years, depending on the problem set. Now, and what I tried to do is to apply this principle to cybersecurity and see where in which domains is cybersecurity easy to verify and where not. And you know, the results of this is attackers, the offensive security has really cheap verifiers. They can just very easily write an exploit, run it, and then they check do I get a share or not, right? Steal credentials and see are these credentials working or not. They can exfiltrate data and check the data. So there's an instant feedback. And this is where you know EI gets really, really good feedback. First of all, to train your models and uh fine-tuning models based on that feedback, but then also have EI agents perform step-by-step type of activity. Now, if you look at defenders, you know, just ask yourself, are we secure? Right? We're going to do an audit every six months, we're going to get a lot of noisy spaghetti alerts from your sim system and then trying to reconstruct and stitch the data together and then guess, I don't know, is it is it really non-attack or not? Is this specific alert related to this alert? So it's not that easy to verify for the I agent. Um, it's very costly to do this type of verification. It takes very often time as well. And this is why offense is really outpacing defense in cybersecurity. And we have tons of proof points around that. Just look at uh Hacker One, one of the largest uh backbounding communities out there. We have NEI leading the scoreboard. Uh there were multiple studies recently, for instance, Stanford IT just had NEI agent to go after, I think it was 8,000 servers in the network, and then tried to find vulnerabilities. And EIF scored as a second on this and on the status and was able to identify certain vulnerabilities which no humans were able to identify, like there was an old IDEC server, for instance. We have uh antropic releasing reports where state-sponsored attackers starting now to utilize EI in a fully orchestrated uh way. And we had Systic as well uncovered, for instance, very interesting campaigns like uh the Isarat campaign, where you would see for the first time a blockchain command control infrastructure paired with AI and literally like all these things you can imagine a malware should do or could do. Where it was very clearly that there was an AI assistant campaign happening around this because it wouldn't make sense. And the speed at which they were able to innovate and update us about the malware was just not real for humans. So AI offense is dominating and is sort of shifting the balance even further towards offense being more successful in this post-ER world than defense. Um, take malware analysis, for instance. It's very difficult and complex and costly to verify if a specific foul is malware or is benign. Now, what we came up with is having certain task infrastructure, like run this malware sample on a sandbox to understand the behavior, look at the code. And then if we if we have a conclusion, is it now malware or not? We would create certain signatures for behavior or static signatures for this malware. So we'll make the verification very easy and distribute that. And this type of approach can help us to think to apply this as well to other domains and see how we can really apply uh and make verification easy for defense to be able really to leverage more AI and more agentic decisions going forward.

Robby Peralta 28:37

How are you gonna do that in your world of container security?

Sergej Epp 28:42

Yeah, look, it's really the the runtime telemetry, which is the best ground truths, uh cloud and runtime. Because for cloud security, there are a couple of ways to do to think about that. So, first of all, you have you can declare ground truths from the beginning on. Things like policy as a code. So I now everything what is moving in my production environment, in my containers, I understand the executables which are moving through my CI CD pipeline. And there's even a feature actually in Kubernetes specifically to detect drifts. So if you think a bit about the traditional roads, we're always hunting for certain bad patterns, which would suggest malware. In Kubernetes security, we can just define this is what good looks like because it's moving through my CI CD pipeline, and then you would detect drift. So in case somebody is compromising your application production, you can just cue it automatically. Right? So uh policy as code, drift detections are pretty, pretty helpful from that perspective. But what's also very important, apparently the most powerful way to make verification easy in cloud environment is make rich reachability binary. And you can do this on multiple levels. One level could be, for instance, vulnerabilities. So guess what? 85% of vulnerabilities, which you will scan if you just look at your code, would never be reachable because developers are taking certain libraries and then they would just use only one specific function from this library, but the code, the vulnerable code, ends up in production without being really used, and then you would push it all to your developers and ask the developers to fix this. Well, it's not really necessary because it's not being used. So reachability on vulnerability level, but then also reachability on the cloud level. That's also pretty powerful. If you can if you understand how a specific identity is reachable within your cloud, how a specific application access is reachable within your cloud, you can really have the sort of an attack graph. And based on this attack graph, you can very easily take a decision. I'll give you an example. If there's an admin panel running in a container environment for PHP, for instance, and it's being exposed, so there's a vulnerability, but at the same time, it's not reachable through the network because your cloud is configured in a way that it there's no egress across traffic happening. You know that this specific workload cannot be exploited. There couldn't be any C2 traffic or whatever. So you can already have this type, you can provide to an AI agent this type of understanding to ensure that it can reason that this vulnerability, this traffic cannot happen. So let's move on another alert where this can really happen. Because in the end, the biggest problem in defense is how do you keep focused on what matters and ignore what doesn't matter, right? And that's where attack graphs, for instance, reachability, but also declaring ground truths can help to decrease this verification of the problem itself.

Robby Peralta 31:50

Yeah. How is the problem of false positives in this cloud native in your experience?

Sergej Epp 31:56

False positives can happen everywhere in in defense, just because it's so difficult to verify them, right? And therefore, the question is how do we go go back and try to build a very easy atomic verification architecture, the verifiers, to be able to stitch them together and then be able to take the conclusion. Let's say there's a targeted attack against the organization. You found out the first proof that this is happening on one of the machines. Typically, you would need now to stitch the data across all the different machines, try to understand if data is being exfiltrated. Who is the passion zero? How did they come in? What kind of tools were they using? So you stitch all this together. The end result of this is a forensic report. And the forensic report will guide you instant response to understand how you react on this. Do you need to reboot your entire environment? Was data exfiltrated? Are they still in a network? So that's that's how you can think about that. If you could create a forensic report instantly, you can make verification much more cheaper and easier. Now, will you still have to have false positives? Of course, you will have false positives because there's another big problem in cybersecurity defense is the amount of data. You can't really capture all of the data. And you can't capture all the data from a runtime environment from a container, for instance, or from the cloud. It will be insane. The amount of data being captured today is potentially 5% or even less. And that's um, you know, that's where you just need to make very smart decisions with your deterministic architecture, first of all. What kind of data are you capturing to be able to create this attack graph, this forensic report, to be able to verify and judge what is really happening across my environment and feedback this loop to either you humans or UI agents to take the next step, you know, on responding or performing any other actions.

Robby Peralta 33:52

Off topic. What is your thoughts around anthropic, open AI, Google getting into cybersecurity? Do you think they're like the future cybersecurity companies?

Sergej Epp 34:04

Look, I think, first of all, they have amazing teams around AI and potentially also internal security teams. But in the end, as I've just explained, it's not about AI. It's very often and the model and the how good the model is. It's about the scaffolding of UI models. How do you really build all these different verifiers and how do you connect UI models to get this ground truth? And for certain use cases in cybersecurity, like off fans, for instance, or code security, it's a bit more easier to apply those because if you want to just get access to your code base, that's pretty easy to configure, right? Or if you want to get access, for instance, to your uh documentation around the code architecture, the application architecture, I think that's where potentially we'll see a lot of innovation from this ER first companies. But on the other hand, understanding the runtime in a multi-cloud environment, like we have, for instance, some customers, small tech companies, which have a cloud within AWS, GCP, Oracle, IBM, and just being able to build connections into all these environments, being able to understand those environments, being able to stitch the data together, is not that easy. So I don't I don't think that we'll see the CI labs moving into that direction because it's not easy to solve, but we'll definitely see a lot of innovation across specific use cases where scaffolding is cheap and where they can integrate very easily with enterprise environments. Because very important takeaway to summarize this cybersecurity was potentially the first industry to use and apply AI. And the first use case was around spam. Remember back in the 2000s, we just had the spam wave. And I feel just that it's based on my understanding, we we saw the first machine learning models being applied there. So AI worked already really well in this public domain where you had access to the data. But AI never worked from a security point of view in the past in private domains, simply because we didn't have the access to data, we didn't have this knowledge graphs, we didn't capture this decision points from a security point of view. And that's the architecture we need. And this is why we're so so bullish about um uh having a deterministic architecture to be able and the right data set as well, right? We can talk as well about the data which is required for that, but you need both. You need the verification architecture, the data set in order to be able to apply AI in an effective way and be able as well to trust the AI to take decisions without really breaking anything.

Robby Peralta 36:48

See, we're running out of time here, Mr. Epp. Do you have any closing thoughts? What are you gonna be using your time on moving forward?

Sergej Epp 36:54

Oh, look, I think um I'm trying to enable right now my team, but also of my people around me to see how we can share more test results around what way AI is working a lot and run a lot of tests. Um and uh yeah, it's it's a it's an amazing time we're living in right now to be able to learn a lot of new things. I'm learning with my kids a bit of remote robotics, embedded devices. That's what we do as a hobby. And it's just uh it's just great to to be able to live in this uh in this time.

Robby Peralta 37:23

What a time to be alive. Mr. Epp, thank you so much for sharing your expertise and looking forward to talking with you again. Take care.

Sergej Epp 37:30

Thank you, Robby. Thank you. Thanks.

Robby Peralta 37:31

Take care, bye-bye. Well, that's all for today, folks. Thank you for tuning in to the mnemonic security podcast. If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcastnemnemonic.no. Thank you for listening, and we'll see you next time.