All right, here we go. Welcome everyone to another episode of Adventures and deva Ops. I'm your host, Will Button and today joining me in the studio our special guest Ory Moncli. How are you or very well? Nice to speak to you, you too, welcome, Welcome. Can you give us a little introduction, a little bit about your background? Sure? Absolutely? First of all, I'm doing software development and anything related to tech since
I was since I can remember myself, sally. It was just a hobby a long time, it became a profession and last twenty plus years I'm doing different kinds of engineering work in the industry, starting as a software developed and in the recent years i'm mostly managing development teams. My current position, I'm heading the engineering team at a Kinness in Security. Still enjoying writing software and learning more about different areas of technologies, things that are renewing all the time.
So that's my passion and that's what I do for a living, right, And that's a hard balance, having a management role but still being able to maintain or enjoy your technical skills. Agree. I mean, I can see that management is an easy gateaway for somebody that doesn't love doing something like that, and kind of switching roles to something else for me out of choice. I'm trying to keep myself up to date. I'm very down to the details. I like to keep maybe small projects not in the critical path of
the development, still keeping my hands dirty and doing some work. But it's a matter of choice eventually, if you like it and you find the time to do it, Yeah, for sure, for sure. So one of the things we're going to talk about today was security in the CICD pipeline. Right right, I mean security, This to me comes with the context of doing things the right way, sometimes corredated to doing things a little bit slower than usual because it has to be the right way, and a lot of
hurdles for their teams. Right, you need to do things, You need to get confirmation from different authorities making sure that this is appropriate. This is according to the standards, according to whatever rule least privilege, zero, standing credentials, et cetera. Our job at a Kills, among other things, is to make the security standards high, or keep the security standards high without the negative impact on velocity, like making it simple, making it easy,
and in some cases making it even easier than usual. Path right, instead of thinking where I should store this whatever, a secret, whatever piece of information that I have, what would be the right repository, the right storage. Now you have a place to do that, and it integrates well with a lot of technologies, authentication types, different infrastructures, platforms, cloud,
the providers, etc. Yeah, for sure. And I think the like putting it in cic D, I think really opens up some interesting possibilities for you because then you can automate it, and I think that's where security really I think that's really where you can start to gain ground on security. Like you mentioned, if you can make the right thing the easier choice than doing it the wrong way, that's really where you start to see the gains from
that. Yeah. Absolutely. I think that in the recent years we see a lot of growth and adoption of a lot of develop tools, develops, tool change, should I say, things related starting from configuration management to CICD,
platforms, container orchestrations. A lot of technologies evolving in this domain, and this becomes a very convenient tool for automation, not necessarily just for releasing an artifact production, but also to have like jobs to help maintaining the usual work the build environment, and related to that, and as such, it
becomes an interesting target for potential hackers. Right, if you gain access to this centralized platform that has access to your cloud service, provide to databases in the organization, a lot of that, that's that's an easy target for hacking credentials and accessing those systems. That's what I think we should we should, Yeah, we should look at when when talking about security, how to protect the identities, workload identities, how to protect different environments. Uh, and
to do that without adding overhead on the process. Yeah, right on. So what would be your for someone who's just acknowledging the security should be part of your organization? What would be the number one thing you would point the map first, or the first thing to say, hey start here. Ideally it would be mapping what kind of sensitive information, sensitive data? What kind of different identities and permissions you have spread across your systems? Because creating identities
and giving access is very easy, right. You simply create another application, another tool, I request access, and all of a sudden it fails up with touns of identities without much of control over it. Like when I ask a develops person how many applications do you have and what kind of permissions each in every application has to perform on a different type of infrastructure. That's not a simple question to answer because in many cases you simply don't have the visibility.
This problem is sometimes referred to as a secret sproll problem because you have a lot of different storages to maintain secrets, to keep access, different different
kinds of ways to manage policies access policies. One cloud provider, you have different type of language and annotation and other type of infrastructure of different things, So it becomes a lot of know how on how to manage it, and in many cases it's kept in a very selected few individuals' minds where to set what Talking about dashboards and visibility to executive level is something that very rarely found, So identifying where the sensitive data is would be the number one step.
I think, yeah, that makes a lot of sense, because I think from my own perspective, my gut reaction to any problem is to start building something to solve that problem. But actually taking a step back and documenting where this problem exists, where it's used, would change the perspective because then you kind of have a better understand of the size and the scope of the problem
that you're trying to solve exactly. I would say that afterwards, once you have that mapped, you probably want to sort them by the most impactful type of identities to the listed platforms, right, which one has access to many resources, privileged access, et cetera, and then try to deal with them first, because the virtual blast reduce should I say, of somebody's accessing those
can be the most significant negatively significant to the organization. Ideally, you don't want to maintain something that is lasting forever, right, So any type of credential, any type of access, should be limited in time for a reasonable duration. When I say reasonable, it cannot be ten years or fifteen years, because in that time you can do a lot of them. I'm talking in many cases minutes maybe hours to perform some kind of tasks, but not
much more than that. Yeah, you know, it was just about a year ago I stumbled across the open id connect, I think OIDC and I haven't really seen it talked about a lot in many places, but I've actually fallen in love with it, and we've updated a bunch of our infrastructure to use that for that specific reason, Because whenever you go to take an action, the OIDC gets a set of short lived tokens and then you can scope
those scope the access permissions for those credentials down to just the exact deployment that you're dealing with at that time. And I thought that was such a cool idea. It's relatively easy to implement, but it doesn't seem to be very popular. Yeah, I think O I d C is positioning as one of the slowly but one of the most popular authentication methods for humans. It's in my opinions, it's second to summon, which is more legacy one but still
very widely used. But I think that over time we will start to see more and more. This is kind of the evolution of some and we start to see more and more relying on O I d C. The foundation or the underlying technology is basically all OFF or JOT authentication, which is very popular
for application type of authentication. A lot of c CD platforms today are providing a temporary signed job that can be used to verify to identify the actual runner and the right context of what kind of project idea, who trigger the job or what kind of resources running, et cetera, and all those attributes both coming from Native job authentication or YDC can be leveraged for access permissions, and
that's very handy. Like imagine that you log into a platform and all of a sudden you have all the types of permission associated with your identity without the need or the operational hussle of managing those same permissions in two different platforms, one being the actual infrastructure, the other one being the secret management site. Right, So basically take the same like if you modify something in your IDP, the identity provider automatically, it reflects to the same its management and the
access permissions you have there. So from an administrative perspective of managing identities, that's a very easy and convenient approach where identities live only in one place according to one policy. Yeah, and that's there's just so many, so many wins to take away from that. The security team loves it, but also just the it and the support folks like it too because then it's just less
chainsaws to be juggling at the same time. Absolutely absolutely, And I think another thing that I was talking about the adoption of different tools and technologies to the develops environment, and one thing that still is not there is the unification of those tools. In terms of visibility, Okay, how many many tools you have, how many different users, both human users and applications are using
specific flows, et cetera. The fact that you're using a centralized platform for secrets management is giving you implicitly giving you visibility to all types of activities in the develops world. Right, so you can see, oh, this client is connecting from CICD platform disguise, this application is connecting through a communities cluster, this flow is coming from configuration management. This is a human authenticating to
my Jenkins webuy wherever it may be. But because of the fact that any entity requires access to secrets, this gives you implicitly a wide visibility to what's going on inside your organization. And that's gold for security officers because there is no other way that I can think of to see all those activities coming from different platforms. Maybe in one infrastructure, like if you're running on a single cloud provider in a single flow, maybe that is another way to see that.
But if you're multi cloud or hybrid, if you're using different kinds of tools in different locations, the only good way to show that it might be it would be through secrets Management Central. Yeah, so the secret manager at that point not only becomes the source restoring your secrets, but also the like the audit tool for defining the footprint and and use of the secrets across it
entire organization. Agreed, Yeah, hundred percent. And maybe as an evolution as a next step, applying some kind of AI based logic on this audit log can detect different kinds of anomalies, like this activity is not something usual for this time of day, or is a day of week or something like that. The number of requests here seems unusual with respect to previous weeks.
This application is behaving really in terms of accessing different kinds of secrets. And maybe, I mean it's not something that is part of modern solutions as far as I know today. But maybe as a next step, this could be interesting in helping humans detecting breaches. Security breaches attacks something that would be hard to detect otherwise. Oh for sure, that's actually a pretty cool idea. So if let's talk a little bit about how you gain like support and sponsorship
for this type of project. If you want to do the full audit to gain to improve your security plusture, what are some of the tools or stories that someone should be thinking about to help sell the to their management team and get people on board with it. Yeah. I think that this can be approached in two ways. One from the security perspective, identifying areas and technologies that are not well protected today and defining what would be the impact if specific
credential specific identities would be exposed or breached. That's one motivation. Another one is to facilitate as I mentioned, unified view from an operational perspective. A third approach would be to meet with certain requirements to compliance regulations, etc. Like in order to be compliant to a certain standard, you have to have
something like that, so different triggers by different business units. And also about the model, I think that model that you tell you you took about sponsoring that this can be sponsored by the main driver, some kind of centralized entity in the organization like the CSO or the CIO or something like that can also be done by the IT department if we're talking about the operational side of things, and it can also be shared shared sponsorship in a sense that it's very
easy to know on using a centralized platform, which departments or which applications consume services from the secrets management. So ideally you can divide the payment based on internal shared model internal to the organization to say, okay, the department that is using the most would carry most of the costs of that sharing. So putting like the you know, the dollars aside for a moment, I think that the motivation can come from different angles. Each organization that we see is
coming from a different reason, or maybe a combination of different reasons. But it's definitely definitely becoming a defacto standard for large organizations and getting lower and lower. Like if in the beginning it was just for large enterprises or corporates, Today we see even SMBs asking about secrets management because it's obvious that you should have some solution. Yeah, for sure, Like the number of stories that we hear about every day just keeps growing. It seems like the people who
are actually impacted most by that are the SMBs. You know. The enterprises I think typically have a larger they have more people, more resources to work with, so maybe they're a little bit better positioned. But you just here a day after day of small and medium businesses that have been shut down, locked out, or been unable to continue business because of security breaches. Yeah,
and bridges is not something that happens once. And that's it. I mean the fact that hacker gains access to even side applications something that looks maybe
less relevant. There is the lateral movement, you know, like when you're starting small and expanding the knowledge and gaining more and more access and more and more possession of infrastructure and resources inside organization and waiting for this special moment doomsday, when something like that is exploding, and when it explodes them it becomes
a big business problem for this particular vendor or this particular organization. So detecting it when it's still small, relatively small, and the impact is still scoped and known. The ability to detect and also remediate that problem right by restricting access to this application, rotating set of credentials, revoking access to certain applications,
all that is very important in the process of securing the organization. And that ties right back into the mapping exercise that you mentioned at the start of the episode, because now you know what credentials this application use, what services it talks to, and where else those components are used in your infrastructure. Yes, an interesting concept that I think that is getting more and more attraction
of the time is the use of just in time credentials. Historically, like if you're at many years in the industry like myself, the war files configuration files with static credentials using m passwords, token's API keys, and typically they lasted four years. If somebody got a got a view of them, they can keep using them without any ability to detect that This is a misuse right from if you look from the back inside of the service side perspective, it's
a value authentication of an authorized entity. What we see more and more is that there is no reason to have standing privileges in systems across the environment. Okay, only when an application argument needs access for a certain reason for a certain task. Only then the credentials will be generated, and they will also be a thermeral like meaning they have time to lead. They have a duration that after this time they will be revoked automatically without any human intervention in the
process. And that model is becoming more and more popular for two main reasons. One is the impact like if I forget my workstation open, if somebody grabs access to a certain set of credentials, they can do so much with it until they expire. But secondly, it's also enforcing the use of a
centralized system. Imagine that we're talking about humans, and humans are very lazy by nature, and that's very normal, and they say, Okay, why should I log into a secrets management platform statch and use them password over and every day and to connect to my database? Right the second time you do that, you say, hey, I can keep a copy of that because it's static. I can keep it in my notepad and a story not need
to log in anymore. And that's true if you're talking about static secrets, But what if there is no static secret anytime you need to get dynamic secret, then you're basically forced or enforced to do that the right way. Now, our job is to make it easier and less painful to people like that, in the sense that there is single sign on integration you mentioned OIDC before and some and also you don't have to retype over and over your credentials to
get some access. But secondly, it's mostly done by applications, and applications can use their trusted identities, like if they're running on cloud service providers infrastructure, they can use the cloud IAM to authenticate to a kill is similitly like you don't have to have an additional set of credentials. If you're working on modern infrastructure like Cobernetti's clus, they can use the Cobernetus identities to authenticate similar
stame fetch credentials. So you find ways to make it easy but secure to authenticate to secretsman on the platform rely on just in time credentials to apply the principle that don't have so what's called zero standing privileges, and also making sure that the credentials are biding with the right policy in terms of access the authorization layer, which means that if here it applies to the principle of least privilege,
you don't provide anything beyond what the application or the human requires for this particular task. If using standing credentials, you would have to have tons of sets of users and only a very educated person would pick the right one for this task. But when you use dynamic secrets or just in time access, it's very easy because you have access only for read or the operations, only for specific set of secrets that are required for this application. So it's helping
in so many ways. And I think that this is a trend that we see more and more, and I think that in a few years time from now, it would be very rare to see static credentials in production environments.
Yeah, that would be cool, Like like you have been doing this for a long time, and I remember many times whenever someone would say we need to rotate these keys, and everyone would just cringe because we knew that it was going to involve production downtime, because nobody knew where they were used, and it was going to be painful and we were going to have everyone mad at us. It's a huge project for many organizations. Sometimes they run it's
funny because we have other ways to do that. But I so places that they run campaigns, like they said the same messages, have you rotated this set of users? Have you've done that? Please send me confirmation, Please do that. It takes months to do that. It's very painful, like you, Like you said, it's very scary. What would be the impact of that? And I have to be honest, that is something that is
not going away soon. Like using just in time credentials is very common, but not necessarily for privileged accounts like break class admins or something like that. That we have to stay and for that, the solution is to use rotated secrets, but to do that in an automated fashion, meaning that something that
you don't even think about. You have a pretty fine configuration how often you want to rotate those privileged privileged credentials, and at that time an automated task is performed and doing that, including the validation of it, in a similess manner, and the new version is kept in the management and the previous version is still available in case you want to roll back or revert that change, and therefore no human intervention in the process. Therefore no need to have complex
and expensive campaigns to force people to do that. It simply happened. It's a non event. Yeah, and I think that's you know, we have all the tools to do that, the technology exists. I think part of that is just a comfort level, you know, because it takes a high level of confidence in your tooling to just put it on autopilot like that and say, yeah, just rotate the creds whenever you think it's good. I'll
I'm sure it's going to be fine. The only way that you can achieve that is if all the systems, all the applications, all the humans are working with a centralized secrets management because if there are two source of one of them will break one the other one. Yeah, so it has to be relying on that, and that's one of the biggest advantages I think of a centralized system. Yeah, you know, because it's specifically in areas where you
have like multi cloud organizations. It's so easy with AWS to just use secrets Manager or in GCP use their secrets manager. But then whenever you have to bridge both of those, you've got to step back to something that's external to
both of those, and so then you have this big social campaign. So now you've got to socialize your new secrets manager to your engineering teams who are writing the code so that they know that this other thing exists and that they should be using that rather than building in using the built in native tools. And I think that social component of it is probably one of the hardest things
for a lot of people. I know it is for me personally because I'm very I like doing things very technical, I'm not really good at socializing things. But that's a huge component to making that type of effort successful. Yeah, one hundred percent agreed, and add to multi cloud legacy environments on premise something that does not interact well with cloud, So you get yourself a lot of secret silos, different policies, different processes, different automation scripts, whatever
you want to call that. That's in the good case that you're automating or trying to automate. The other alternative is worse that it's simply like that forever and everybody's afraid of touching, so something would break. Yeah, I think that's a That's something I've encountered in the past, is people hesitating to do this because they're afraid of breaking it. One argument I've used to overcome that in the past is saying, look, it's going to break either way.
We can either choose to break it intentionally right now for the purposes of fixing it, or we can wait for it to break at some random, undetermined time in the future that we can absolutely guarantee is not going to be convenient for anyone. So it's it's our choice. Yeah, And I would add to that, maybe not following recommended practice when it comes to production environment for
different reasons. It can be costs, it can be laziness. Ideally you would want to have a staging environment or a dev environment or testing environment that is identical to your production environment, so you are able to test something before
it applies or affects production workload. Maintaining that is something that is expensive, both in the amount of resources that you need to duplicate, but also humans or engineers that need to maintain it to make sure it's synchronized, to make sure it's aligned, etc. But once you're at that point, you can simulate a lot of scenarios. What happens if I rotate this value, how what's the impact? What would break? And you do that before it's impacting
customers, before it's impacting business, and that would be ideal. I mean, if I look at our production environment the way that it's structured, it's part of our pipeline. You cannot do a single change to production if it's not passing all the tests, all the validation steps that we have in staging environments prior to that. Now it costs money, right, you need to basically double the dollars you pay for production, but it buys you reliability,
which in some sense values for money for our customers. Okay, imagine it's something like that business critical system like secrets management is not accessible. This means automatically that our customers are bleeding money pages all over the place. I mean, it's it's becoming a mad place. But we need to be very confident about the changes that we do, and I think that our customers, many of them, are following same practices to achieve that goal of not being afraid
of doing changes, being less afraid. Right, an circling back to the c CD integrating with security thing, what are the what are the different areas in a CD c C pipeline that you think are our stop points or security checkpoints. So today a lot of CICD platforms are integrating the SEM with the part of the deployment. Okay, so checking out code is a honish, it's part of the same platform. You don't have to authenticate to a remote
kit tabripo or something like that. In the past it used to be like that, Like I mean, I don't know, using Jenkins or something like that, you have to authenticate to a remote It triple and the second part is about the deployment, the CD part of things. Right, So when you deploy something, it normally involves two phases. One of them is building the artifact and uploading it to some kind of artifactor or artifactory serving. It
can be a container registry that holds the recent version of the image. It can be a few sets up binaries that you stage somewhere in the kind of a street bucket or something equivalent to that. And the second phase is to apply the new artifacts in the production environment. That can be by applying restart rollout to your communities, deployment, or reinstalling certain components in software to pick
them up. All of that is like a typical CICD flow, checking out a piece of code, building something, getting artifacts, uploading them somewhere, applying it to production environment, all those steps without any exception. Maybe just the buill part will require a set of credentials okay to authenticate to get to doctor hub or whatever registry you have Kubernitis, et cetera. And typically it's not for a long time, like you need it for just a minute or
two for the authentication. So just in time is a perfect match to this, to this flow, and it's very diverse, so you see a lot of technology. Sometimes you even use database to query something in order to decide where to apply or what to do something that's another security checkpoint to authenticate to that database. So I believe that if you look at the flow, you will see a lot of a lot of integrations with the secrets management that's yeah
for sure. Yeah, just pretty much every step along the way you need a different set of credentials or different set of secrets for that step. Yeah. Right, So we're saying that the secrets management platform has all of our secrets, So how do we how do we set up the secrets management platform to be secret itself? Right? I'm guessing that you're aiming, how would an application CICD pipeline, for example, would authenticate to a secrets management platform
without having an initial secret by itself. Yeah, and that's an interesting point. I mean, talking about legacy workload, that probably was the case. I mean, there wasn't any kind of underlying or fancy underlying infrastructure just run on burn metal hosts with no type of identification for this particular workload, let alone in a trusted manner. So you had to have something like that. Today, most of the infrastructure is running on top of modern infrastructure. May
it be a cloud service provider, different kinds of services. There comberneties, clusters, CICD platforms, and all of them are providing some kind of trusted identity. When I say trusted, it means that it can be verified by
a third party. If we were talking about this job authentication, it means that the cicity platform is holding a sensitive private key that is used to sign this job for a short duration, and it's also providing an external endpoint with access to the public matching public key that any third party can just validate if this is signed by this trust identity. Cloud service providers are doing something similar to that, using different service and SDS service and others to be able to
validate. And if you're still if you're still using a legacy workload running on burmetals or VMS on prem there are ways to bypass that. We have implemented something an authentication method called we call it universal identity. The concept is to have tokens that are frequently and rapidly rotating. So there is an initial token, but immediately after that it's been constantly and frequently rotated. Each rotation is
invalidating the previous version of the token. So the reason it's it's considered more secure is because a random hacker that gets access to this improvement has no identity to still outside of that environment. Like, if I see this token, I can maybe take it and try to use it elsewhere. In a second from now, it will no longer be valid because by then it was rotated. One of the questions that I asked when you when you say short lived,
you're talking numbers of seconds. Numbers of seconds? Wow, right on, yes, And what I'm being asked is, in order to rotate a token, you need to have access to the token itself, right, This is the identity that allows you to perform the rotata operation. So somebody asked me once, what if this hacker is rotating the token before the valued application is even though it's we're talking about seconds, we're still quick enough to do
that. That may be the case, But one of the events that would because as a result of that is the rotation of operation of the valued application would fail. And that event alone can be triggered. Can be triggered in order to revoke access to the application something is bad happening. I simply revoke
access to anyone who's using this identity. So in any case, this random hacker would not be able to enjoy or to get access to secrets, and that's based taking an old school environment and making it a trusted environment or trusted identity without the secret zero problem or the chicken and an egg problem like that you descript right on, and that ties kind of into the difference between authentication and authorization, right, So the sign the token is the authentication piece of
that, and then the contents of the token itself are the requested authorization that may be granted once the sign token is validated. Right to be precise, the token contains a set of attributes which in the back end are associated with
an authorization layer. It's in our case, it's it's based on role based access control or our back So it's definitely relying on the attributes that are part of that token, but that the loan is not the access role because it's the language is more reached and just holding it in a token, it's about capabilities, what kind of access rules, which kind of secrets, what type
of permissions based on crude attribute. So you have a lot of data behind the scene and holding it inside a token that's supposed to be relatively small in size is not realistic. Gotcha cool? So from someone just getting started on
this or just trying to gain traction on it. The mapping exercise to understand the scope of the problem, prioritize it, to attack the or to address the biggest risk items first, and then use that to start bringing in other teams to sell it to them and show them the benefit or why they may have a vested interest in this, and then from that point you may have a pretty good idea what your implemented solution is going to look like to sound
about, right, Yeah, actually it's a it's a fair description of our discus piece of cake. Just an afternoon's work, right, absolutely, It's always like that. Yeah, cool, All right, Well, I think we are coming up on an hour here. Is there anything else that you would like to share or offer as words of wisdom to someone taking on their security journey. I think we've covered pretty much the main stuff that I wanted
to discuss. Obviously we can expand on different areas. Yeah, I see different topics, but I don't think we have enough time to cover everything. So I think it's a good start and maybe in future sessions. Yeah, it sounds like you just teed us up for a part two of this conversation. Why not right on cool? So let's do let's do some picks just to introduce something cool. My pick for today is going to be the gov Lights go v G, o V E E dot Com. I put some
of these lights. We have this recessed ceiling in our living room, so I put some up there and it's just been super cool and you can control it all with your app and it uses it connects to your Wi Fi and you know, I think one of the biggest concern I have with all of these smart lights is giving them access to my network. And yeah, so I don't know if you is any secure, any more secure than any of
the others. This is not a security endorsement. The only disclaimer I'll say there is I do have an isolated Wi Fi network, And yeah, I separate the networks. I don't know, it's something that I put in the past. One for the computers and sensitive information and all the rest for all the unknown devices that I purchase online. And I don't know what the hell are doing exactly. Yeah, I run three networks. I have the one for my work computer and then the one that the rest of the family uses
with their phones and computers. And stuff. And then there's the third one for anything that wants to claim its smart like, okay, well you can go be smart over there. Absolutely, And once when I had the time, I even tracked. I don't know, I took some TCP dams to see what kind of activity is this device doing when I'm not doing anything. You'll be surprised how many packets it's sending two different IP addresses across the globe
where I did get a chance to investigate. But as long as it's not able to access the local network at the computer network, I'm quite okay with it. Yeah, for sure, you just got to limit your exposure. It's about all you can do. Absolutely. I'm also I'm also dealing with like improving my smart home devices. It's a project that I started many years ago, when before all the easy to plug in devices were selling online. I started with a small r the window project. The initially just to turn
on and off a light a lot bulb. Later on, it was so embarrassing to buy something much cheaper than the than the board itself to do everything for you, plus connecting to the internet and Wi Fi. And today I'm combining it all in a mobile application. So it's very easy sometimes, like when I'm driving home, like I turned on the see when when it's hot outside. So I get home and everything is all brazy and nice, opening the the winds, the shields in the morning and closing them at night and
all that. So it's a project that is ongoing, but I enjoy you playing with it when I have the time. Yeah, for sure. Time is a big commitment there because I find it super interesting. But meanwhile, when my wife is like, well you just stop, leave it alone, I just want it to work exactly. You need to have a fair sef meccas and is something that all defence and stuff is not working, you still
have a knob to get what you wanted to do. Then I need a staging environment for my home automation so that I can keep production of time and keep it with a secrets management for all the sensitive day that you have exactly exactly cool, So go VI lights or my pick. What what have you got for? Sorry, it's it's hard because most of the innovation that I'm playing with is related to what I do at work. So recent evolution that
a small gig that I did is related to application monitoring. You know, sometimes it's hard to identify what specific flow in the application is the one causing an unexpected use of resources, whether it's CPU, memory and other stuff. There are many tools to do that today, but the interesting part is how to facilitate that to the developers so they can see exactly what's the problem, capturing this very moment and facilitating that. So we had a different solution part
of our product for accessing web applications. The challenge was that this data is textual and can be converted to an HTML, but it's required to do some kind of an operation to run or to execute the process before the page is proper or rendered. So I combine that with a small LUA script that runs
on Engine X and that this triggers the command to populate the HTMIL. It's fast enough so you wouldn't notice in the browser that something is happening in the background, but it's in a click of a button you're able to see the application flow. So that's that's something I work in the site. It's not directly related to what I do, but it was a nice project that I claim, right, and that's super cool cool. So if people want to get in touch with you, talk more about security. How can they do?
I think the best way through my email. It's already at a kidos dot io. I cannot promise an immediate or fast response, but I can promise a response, so fair enough, give it a try. Awesome, Well, thank you so much for coming on the show. It's been a great conversation and I look forward to having you back on to talk more about this. Thank you very much, Will for hosting me here. It was truly pleasure and fun, and I look forward to talk against right on. Thanks everyone, we'll see all next week.