Cailyn Edwards: [00:00:00] Offloading some of that work so that you're not doing the patches really. You're doing upgrades instead. So you're offloading a little bit, you're building that trust relationship. You're putting a bit of ownership onto the cloud platform in, in terms of Bottlerocket, saying Hey I'm buying a product from you.

Ashish Rajan: Yeah,

Cailyn Edwards: give me the product nice and clean and ready to use so I don't have to duct tape it every month. And then the other thing is, again, it's a common conundrum in security is like one of the tenants of security is to not secure by obscurity and.

Ashish Rajan: If you're trying to build container workloads or Kubernetes workload, you're probably looking at container vulnerability management. And in this conversation with Cailyn Edwards she spoke about how she's doing container security at scale in their organization, how she was able to have developers onboarded onto the idea of doing container security.

I'm like. That is awesome. I have to have her on this podcast. So that's why we had a conversation with Cailyn where she spoke about all the open source tools they're using to do container security, what kind of different stages you can include, which are developer friendly, how you could be shifting down, not shifting left, and if that's more of your interest and if you're trying to learn more about [00:01:00] how container vulnerability management could work at scale.

In fact, there are minimal container images available from your cloud providers as well that you can use these days to minimize the amount of custom patching you may need to require, just update the version, but definitely share this episode with someone who's tried to work in that space of containers and Kubernetes.

I'm sure they'll definitely find this valuable as they're starting the journey on Kubernetes and container workloads. If you are listening to an episode of Cloud Security Podcast for a second or third time and have been enjoying these episodes. Have been finding them valuable. Really appreciate if you can drop as a follow, subscribe on Spotify or iTunes.

If you're on audio, if you're on video, like YouTube and LinkedIn, definitely give us a follow, subscribe there as well. It only takes a few seconds and it means a lot to us. Thank you for doing that. And now let's get to the episode. I'll talk to you soon. Peace. Hello and welcome to another episode of Cloud Security Podcast today.

Hey Cailyn, how are you?

Cailyn Edwards: I'm great. How are you?

Ashish Rajan: Good. Thank you for coming. So you're a second time guest?

I wish there'll be a third time as well, soon, but we are talking about container security today and to set some context before, can you share a bit about yourself?

You've obviously come before, so people would've heard you before, but I would love to [00:02:00] set the context again for what your background is. How did you get stuck in containers?

Cailyn Edwards: Sure. Yeah. So again, I'm Cailyn Edwards. I currently work at Auth0 by Okta. I'm a longtime Kubernetes contributor and currently the co-chair of Kubernetes Sig Security.

So I've been very active in the community. The last I guess four years, whenever KubeCon Valencia was is when I got started. And it's been just an amazing journey so far. In my previous role I was very focused on network security and multi-tenancy, which is still part of my role, but also in the last few months Auth0 has really been working to get as close to zero vulns as possible.

So container security has been on my mind and I honestly, my talk largely came from the opportunity to do a montage for containers. So my talk is, do your containers even lift? And that's just too fun to, to give up.

Ashish Rajan: Is fun because you do weightlifting or

Cailyn Edwards: No, it's maybe, but no, it's it's just, I just really wanted to make the idea of container hardening [00:03:00] fun.

And to me, all my talks are quite silly or localized. So I thought that would be a really fun fair, Arnie inspired one.

Ashish Rajan: Oh yeah, actually that's a good but container security, why is it important to maybe just set some conscious of people and because I guess a lot of people understand I guess where I'm coming from is a lot of people who would be on the other end of this they're seeing a lot of new workloads being run on containers, Kubernetes and containers like the OS that's used for Kubernetes as well. Just to give some context of why it's important to focus on it, if you set some context for I think you had some research in your talk as well where it talks about certain things you identified.

Would you be able to set some context for why container security is more important?

Cailyn Edwards: Yeah, absolutely. I think that in the current climate we have almost a overflow of available information. So if you Google, if you use whatever your chosen AI tool is you can really get hit with a whole bunch of information.

And really it's hard to vet that, like we've gotten to the point where you can't really just trust documentation to be accurate. And so me and my co-speaker Daniel [00:04:00] were really concerned that people might not understand the inherent risk of just pulling a configuration from online or from ChatGPT or Gemini or whatever.

And using that in your tiny little application or maybe even your big giant application, maybe you start somewhere small and you wanna prototype and you just pull an image that you know, you're seeing used everywhere else. And there really are many more risks. And in the talk you'll see that we highlight using various tools where you can see exposed and everything online, hacker tools you'll see that there it's not in the magnitude of hundreds. It's thousands and in some cases, hundreds of thousands and even millions of exposed ports in Kubernetes exposed Kube API server. And so there's a, there's all of this cruft that exists in the internet that insecure, and we suspect that this is just a lack of knowledge and a lack of appreciating how impactful a tiny little vulnerability can be, and that if it sticks around forever you're just leaving this door to something that you don't necessarily know the [00:05:00] future of, particularly in the, in your place of employment. You don't know the future of the services you work on.

Ashish Rajan: Interesting. 'cause I'm curious, in the research you did was there any cloud overlap? 'cause you mentioned anonymous the Kubernetes API was available on the internet, the ports are open on the internet. So was there like an overlap of how much was in cloud or how much was self-hosted out of curiosity.

Cailyn Edwards: I'm not a hundred percent sure. Definitely my colleague was the heads down researcher, Daniel. And they will go over the research extensively in our talk, but we did see that like most applications right now are are building, obviously they're building their application image and sometimes self-hosting, sometimes using from Docker, but then they're also pulling in some kind of OS image for their host. So you're seeing that on both sides, right? You'll have almost, basically, you have at least two containers that you need to ensure are secure. So we saw a whole bunch of vulnerabilities on the Kubernetes kind of deployment side, and then we saw a whole bunch of [00:06:00] vulnerabilities on the application image, typically something like Docker. And I think Liz Rice years ago, this is I go back to this talk all the time. She did a pentesting your Kubernetes cluster. And so that I think that talk, if you're looking to learn about what does it mean to, to not specify any security in your Kubernetes deployments.

Liz will show you what it means. It means that basically you're making that available.

Ashish Rajan: Yeah. And because this is an interesting point as well, because a lot of people. Sometimes don't understand the whole self-hosted cloud version. And these days there's a mix of everything is a hybrid cloud, multi-cloud, all of that as well.

In terms of how container security can work, you mentioned some tools as well that you've been using. Just to give some people context of what are some of the ways people can be doing container security in terms of whether it's through automation or through manual. What does it look like in the pre tools world or in a regular world? And maybe then you can talk about some automation around it as well.

Cailyn Edwards: Totally. As a security professional, I think many of us have had a role doing security reviews for new applications, where the first [00:07:00] thing we would do is read through the Docker file and we would have like a list of the basic docker or security principles, OWASP has a really great one and now there are many tools that can help you along each stage. What we ended up leaning really heavy, heavily on just by accident is Trivy, Trivy has added a whole bunch of really amazing Kubernetes specific functionality and scans, which is great, and it gives like a really nice, rich UI to see.

It's you'll see our before and after are very impressive because of the UI that Trivy uses. And so I would say like from framing it as a security reviewer perspective, that's more the manual way is that you would go in, you would take a look with your eyes and you would see is there anything immediately that jumps out?

Do we have, the docker file running as rude the entire time? You know that very obvious stuff. Oh yeah. Are we literally putting a plain text secret in? So you go through and you get that low hanging fruit check, and then the next step would be like, okay, we're humans, we're cannot catch everything. Let's run it through a scanner. There used to be, I'm sure it still exists, but things like Docko or Kubeaudit, like those kind of things that will look at [00:08:00] your manifest files, look at your docker file and pick out just like common misconfigurations. So then you would do that.

Then you would go into something like Trivy, which goes a layer deeper, and that's gonna start to look at the components that your application is made up. You can also do SBOM generation and validation if your application is gonna persist. You wanna see like what's, what's changing over time After that, I would say you're probably in a pretty good shape to go ahead and ship that application.

Obviously you also need to understand like what it's doing, how it's doing, what it's interacting with. Yeah. But after that. You have no power over the application developers, they might go and change things. Maybe they go and add a plain text secret in the next feature ad. So then the flip side is you have to have all of that, those same steps, automated catching any changes, making sure that if a vulnerability is introduced, if an anti-pattern is added if someone just makes a mistake that we catch it and we can action it immediately. And ideally, you're doing that through repeated scanning or admission control. And then automatically opening tickets or issues. However you [00:09:00] manage it in your organization, even if it's a, even if it's a personal app, get it, get an email, get a text message, get a, a GitHub issue that opens and lets you know that, hey, you've gotta go look at this because something is wrong. And it's not necessarily even the people working on the application. We know supply chain security has been hot for years now. Yeah, it, and you might have something in your dependency chain become vulnerable and that will impact you.

So things like Dependabot or there's the other one RenovateBot that will catch those and ensure that, hey, it's time to go ahead and do a little upgrade. Get everything polished up.

Ashish Rajan: Yeah, and to your point, because as it's funny, I think my, in my tiny brain, I always thought, oh, it's just vulnerability management.

I can just do patch management and move on. But I think you set quite interesting things about is the supply chain as well. It's also the parts where, hey, oh, there are open source libraries being used where it's been deployed, how, and there are secrets lying in there as well. And these days a lot of understanding people have had about vulnerability management in general, and that's the category a lot of people would put [00:10:00] the container security, patch management kind of concept in in terms of is how much of it can be automated. I guess you, to what you said a lot of the developers are using CICD pipelines as well. How does all of this fit into that world and what does that look as. Hey, Caitlyn. There you go. I have a container version one. Now what

Cailyn Edwards: I think my principal and most of us who work in security, the ones that find it easy to continue our jobs, like work with developers, not against developers. So we don't want to come in after you've built this complex application and be like, change this.

Also, you're gonna have tickets opening regularly that are gonna be telling you that you have to do work. So as much as we can take on the work early and front load that security experience, the better. So I would say and we've been chatting about this before we started, A great way to start is having a blessed image library, having your own private image registry. At Auth0 we've been really leaning on the Chainguard images or, and no matter what, immutable images. So making sure that those changes, [00:11:00] again, can't hap happen after the fact. And that means like right off the bat, your developers are going to be in a better spot. That means with Chainguard in particular, these are very slim basic images.

You have to make a very intentional decision about everything that you add to the host and why? And like you just cannot use it the same way, which I think. Helps us not create bad habits. Like you're not executing into a Chainguard image, right? And mucking with stuff that's, they haven't intentionally made it.

So that is not how you interact with it. So that's step one, is give them good tools, have that paved road, be clear and with good guardrails. Okay? But stuff happens. And things get introduced. Personally I am learning Python right now and the amount of times that I've accidentally froze my dependencies from my root environment and ended up with them in an application is is mind blowing.

And there's not an easy way to go through those dependencies and see what is being used, what's being used by other dependencies. And so people make mistakes, it's a struggle. And so the next step would be what we've talked about is have this pipeline, have a scan immediately on [00:12:00] changes for as part of your GitHub, as part of your PR request, make sure that nothing absolutely awful is being added and then shape scanning in production, getting notified using the tools that exist like Snyk or you can build your own with trivia or whatever these vulnerabilities skin are, use one of those, get notified, have your internal delivery standards on patching those vulnerabilities.

Ashish Rajan: Yeah. Do you find that with, I think you mentioned Chainguard, but there's Bottlerocket as well. Is that, so are they similar in the context of what they provide?

Cailyn Edwards: They're similar. Bottlerocket is the AWS Blessed image. It is immutable and very regularly updated and patched by AWS and depending on what your platform looks like, either they will do that automatically for you or you can make that decision to, to be slightly off of the latest release.

Yeah, which would be my recommendation is yeah, be a little bit behind so you can vet. But it's very close. It's the AWS bespoke version. It doesn't scale as broadly for all your container use needs. So I think whatever, whether you're using AWS, GCP or Azure, they're going to have some [00:13:00] kind of blessed image that they're gonna, they're going to guarantee and they're gonna stamp and they're gonna update.

And I would recommend using it.

Ashish Rajan: Is that a better approach than, I guess traditionally a lot of people would've had their own docker registries, private ones, and 'cause I think from memory, it sounds like there's a lot of maturity in the whole container security conversation as well, because earlier people were still talking about, Hey, make sure it's your private repository. Don't put your docker registry on the internet. So now we I feel like we are on that thing where artifacts being produced are being put into a private docker registry which hopefully is in the cloud or whatever.

And now we are onto the next stage of, okay we understand instead of just patching, every time there's a new update coming up. And then me reaching out to Cailyn or Shilpi or whoever going, Hey new updates up this Monday. What's it called? Patch Tuesday or Patch Monday, or whatever you say. Oh yeah. So it's it's Patch Tuesday.

Let's get going. And some of, there's a lot more maturity to it. Now, to your point about this Bottlerocket and Chainguard have minimal images that you can use do these images, whether it's Bottlerocket or Chainguard, I'm assuming they come with versions as well. 'cause there's [00:14:00] obviously newer security patches keep coming up.

What does that look like at a scale? So I gave you V1 of it in the beginning.

Now, obviously to what you said you've moved on, built a few applications, maybe throw some AI in there as well. What does that look like in when it's operational, in terms of day to day when Next Patch Tuesday comes up and the one after that?

Cailyn Edwards: I think it, it really depends on your scale and your platform.

Ashish Rajan: Yeah.

Cailyn Edwards: But I would say what we typically do is for our platform that's using Bottlerocket is we will typically have a weekly release. And that weekly release involves pulling in the updates on that image. In terms of Chainguard, they let us know when there's been a patch, like they come perfectly clean and non vulnerable. And if that changes, they let us know. And they have tight SLOs on that. I think, I can't remember exactly what it is, but it's definitely like on the magnitude of days that they promise that they will be back to zero. And so I would say like you still, you're balancing, offloading some of that work so that you're not having to have, you're not having to do [00:15:00] those patches entirely. You're not doing the patches really. You're doing upgrades instead. So you're offloading a little bit, you're building that trust relationship. You're putting a bit of ownership onto the cloud platform in, in terms of Bottlerocket, saying Hey I'm buying a product from you.

Ashish Rajan: Yeah.

Cailyn Edwards: Give me the product nice and clean and ready to use so I don't have to duct tape it every month. Chainguard saw the hole in the industry and fixed it. And so that's a, they productized exactly what you're talking about is the, that container maturity. And then the other thing is, again, it's a common conundrum in security is like one of the tenants of security is to not secure by obscurity and I still think you should have a private registry. I still think you should, make sure that you're not letting someone else decide what your image is like. Like using latest. Basically you're saying, I trust you to give me whatever you want. Whatever that image looks like, give it to me. Yeah, you shouldn't do that.

That's, we all gotta be a little bit more paranoid than that. But we can't also say oh, we did it so it's secure because it's not, or people can't see it, so they're not gonna know we have the vulnerability. They will. It's on the, it is probably on the internet if it's not [00:16:00] on the internet.

Yeah. It's connected to your network, so it's internally available. And so I think it's a little bit of maturity. It's a little bit of deciding where we can fight our battles. Yeah. Can we offload a little bit of that responsibility while still managing those upgrades ourself? Not saying AWS gets to decide what image we run, but say we're gonna lean on them to uphold their side of our contract.

Yeah. And then we're gonna do our due diligence before we put that out into our production workloads.

Ashish Rajan: Awesome. And I think we, you also were talking about scaling as well across I think you had mentioned OPA earlier as well. So we spoke about Trivy, we spoke about secrets, Truffle Hog. I think is what he used for looking at secrets.

You had OPA and other things as well in terms of when this is so Kube-bench as well.

Cailyn Edwards: Kube-bench is another great tool. Yeah. We didn't use it in our talk, but I have used it before. Similarly applicable. So I would say, one that we don't touch on a ton except to say that how impactful it can be to expose secrets and Truffle Hog is a really great way, particularly for any of your, your [00:17:00] home applications.

It'll it's really good at finding the secrets.

Ashish Rajan: These are open source as well. Just to come to be clear, right? These, this, yeah. They're all open source. How amazing is that? These things are just open source as well.

Cailyn Edwards: It's really like incredible the amount of power a user has and we're all like all of us here that are. Software is part of our job. It's becoming part of our lives. You've got your oven connecting to the internet. This is the time to be able to say like, how secure is my home? Yeah. Now that it's on the internet. So the secret pipeline is, should be separate from your container pipeline and there should be a whole bunch of very mature practices in place there.

And that's not super our focus except to say. If that pipeline fails, if your secret management fails, you wanna catch it and you wanna catch it early and you wanna be ready. The opa and admission control side is, okay, so now you've got all your scans, you're getting notified when things go wrong. Can we make things go wrong less? Can we make sure that the, that our platform engineers and our developers are not having to constantly think about security 'cause that's what we get paid for. Yep. Yeah. And I think it's pretty recent. The native Kubernetes pod admission, which is just [00:18:00] awesome. It's so nice.

You can just write in your name space through labels in a very Kubernetes cloud native way. Say, I want to warn on the security the pod security policy being whatever, less than restricted, let people know Hey, you could be more secure. You should be more secure. You can enforce to say, we don't wanna create workloads that don't meet our minimum security standards.

Awesome. That's a bit more impactful. So that's going to cause a block for your developers if you're not ensuring that they're going to very easily meet those standards. Yeah. So then you come into the Gatekeeper OPA is the tool I use, but there are many other admission control enforcement methods out there.

And so they have validating and admission and mutating admission control policies. And the validating ones very similar to the one I just described. For native Kubernetes, they'll say, Hey. Don't do this. You're doing it you're doing the bad thing. Or like you could do the better thing. And then the mutating ones, which I think are really what you wanna do.

And if you have the opportunity to build a container pipeline from scratch, do it [00:19:00] right away. Yep. Is it just changes it, it just changes it, it just changes that line from my insecure setting to my secure setting. And then the developers don't have to think about it. And and if they run into a wall and they say, oh, actually we need this workload to have elevated, elevated permissions, they cannot do it the typical way.

And they have to find out like, how do you isolate that? Obviously we need a different namespace. We need a defined specific, in exception to a rule, which is much better than the opposite, which is like default open and then lockdown. We wanna default lockdown and then open in a way that is minimally impactful because we want developers to like us.

Ashish Rajan: Was there any challenge? 'cause I think getting developers to like is a very hard job. So was there any tips that you have for people who are trying to do this as well? Because obviously it sounds anyone who's trying to work on the container security pieces, they obviously can use all these free tools like Trivy, TruffleHog, OPA, all of that to start building the foundation for a lot of these. And you mentioned, are they different pipelines or are they just basically different stages of a pipeline?

Cailyn Edwards: I [00:20:00] would say different steps in the pipeline. But again, it depends on your platform. Depends on when you do it.

Yeah. And I would say my tips for doing it is like start building that relationship with developers early, educate, let folks understand why these are concerns and why we need to add these limitations. Yeah. And then we all want the same thing. We all want our companies to succeed, our applications to be safe, our applications to be reliable and we are going to learn things about our practices as well to be like, oh, like we have to balance security and reliability.

The most secure application is the one that's turned off. Okay. But how do you use a turned off application? So we crawl back and we meet developers. We're there. We understand their use cases. So we don't say oh, we're gonna put all of these things in place 'cause we think it's best. We say, what do you do in a day?

How much access do you need? How much permission do you need in your container? What tools do you need in the container? Can we find a better option? Or do we need to adjust our security policies to account for what you need to do because it's your job. And then the developers are honestly an easy sell because you want the same things, but then you've gotta go to the leadership and you've [00:21:00] gotta say, we need to make this as easy as possible because security is absolutely silent when it's successful. No one is saying, wow, you didn't get hacked this week. People are saying, oh my gosh, you got hacked. And so you have to highlight where other companies are getting vulnerabilities that really impact them. You have to show that like even though there's not necessarily a dollar value mapping to these security controls, like you need to invest the time in a pipeline because when it does go wrong, it's going to be too late.

Ashish Rajan: And to your point, would you say security people also need to start being proactive about building these pipelines, helping these to, to what you said, developers already have their hands full. And instead of us going with a list or a checklist for, hey, okay, we should do the, these 10 things should be done.

And by the way, I'll be back to next week again with 10 more. It sounds like a better way probably to build a relationship with developer could be US security people could be building those stages for them in a way that it doesn't impact them, but at least they get to be [00:22:00] warned on, Hey, this could be something you don't want to put into production.

Cailyn Edwards: Yeah I agree that has been my experience on platform security teams for a long time, is that the way that we can be the most successful is really having our hands in the work and working directly with developers with other application security teams to say like, how can we have an automated pipeline?

How can we make sure if a developer goes to make a service, they're pulling from a secure template, they're not pulling from some random source. How do we make sure that we have images we already have reviewed and vetted. Yeah. Available for them. So I think all of that. And then I do think, like particularly in the changing landscape, like we're all trying to figure out where we exist alongside AI.

I think that for security teams going beside the developers and working on these things. If they need to do a patch, don't say, Hey, do a patch. Good luck. Say, Hey, we're gonna do a patch together. Wanna hop on a call with me? We're gonna fix this talk, talk through and find out like how can we share the load of application and [00:23:00] platform security mixing with application and platform development.

Ashish Rajan: Wow. Yeah, I can see why you mentioned about the leadership acceptance would be a quite key in making this happen. It's great, but you and I can be friends with developers and everything, but if the leadership doesn't push down on, Hey, we should, this is standardization now. Yeah. That would make the conversation really difficult.

Cailyn Edwards: Yeah, and I'm super lucky to work at a Auth0 by Okta. We're a security company. It's in our blood. Yeah. It's our goal to be the most secure company in the world, and so we really get endorsement for security. There is there's no one is saying. No thank you. It is do it all the time and do it well and be at the forefront of the industry research all the time.

But that's not the case. If security isn't your top priority. If you're leaning on other companies, there's a millions of wonderful companies that will help you with your security. How do you justify your internal security? Because again, you still need to balance that relationship of, you can't just say, this company, Snyk is gonna do my security for me.

They're gonna tell me when I need to do anything. You can't do that. And I [00:24:00] think it is a, it can be a very hard sell if you're not at a company that is so security minded.

Ashish Rajan: Yeah. This has been amazing. Thank you for sharing and any final takeaway for people. Obviously I'll write, I'll put your talk in the show notes as well, so people can go check that out as well.

Both you and your co-presenter is there as well. Yeah I'll put the talk in the show notes as well. Any final takeaways for people who are trying to build the security be friendly with developer moto? Any final tips for them before we can wrap up?

Cailyn Edwards: I would just say that as a security person, be paranoid as an application developer be paranoid and communicate a lot. I think the theme of KubeCon and maybe some of your other guests will say is, now we're not shifting left, we're shifting down. And I agree. It's, it, I think that's a great idea. I think I said the keynote last year is maybe we should stop shifting left and just take a moment and see, because we can't just keep shifting left.

And I like this idea of coming together shifting down, making it easy to adopt, making it. Just less work really.

Ashish Rajan: Yeah. Yeah. Be more hands [00:25:00] on. And we can people find you on the internet to talk more about all of this information if they want you to find your talk? Obviously you can find the talk in show notes, but

Cailyn Edwards: Yeah. I'm not super on the internet these days. It's a weird time to be on the internet. So you can find me on, you could find me on LinkedIn.

Ashish Rajan: I don't judge you for that. Yes. Yeah. Also, LinkedIn is probably the, yeah, LinkedIn is.

Cailyn Edwards: LinkedIn or Strava. Those are my social medias at the moment. Strava? Yeah.

And you runner? I'm a runner, yeah. Yeah. Oh, wait,

Ashish Rajan: I think we should do the three fun questions as well then.

Cailyn Edwards: Okay.

Ashish Rajan: First one being, what do you spend most time on when you're not trying to solve container security problems?

Cailyn Edwards: As a typical atypical minded person in with ADHD, I'm a, my hobby is hobbies, so I do pottery and sewing and running and squash, and I own a farm, and literally everything is what I do outside. I'm a, homesteader. I do great cooking. Right now I'm training for a bunch of races, so definitely a lot of running.

Ashish Rajan: Wow. I was just expecting one thing. But you're like, no, I do it all. Oh, wow. Okay. But we only have one life. Why not?

Cailyn Edwards: Yeah, why not?

Ashish Rajan: Yeah. And the second question is, what is something that you're proud of [00:26:00] that is not only your social media?

Cailyn Edwards: I am proud that before software, I was a farmer and I was able to make my own pizza dough, cook it in my wood-fire pizza oven, dress it with tomato sauce from tomatoes from the garden, put mozzarella on it, from milk from my goats, and then top it with basil from the garden.

That is like the only thing I didn't do was grow the wheat, and now I'm in a place where my neighbor grows wheat, so I think I'm gonna be able to have a within five kilometer pizza next year. And I think that is like a pretty freaking sweet accomplishment.

Ashish Rajan: Wait, you were doing farm to table before it became a thing like

Cailyn Edwards: no, not before it became a thing.

I just did the opposite. I went from farmer to software instead of software to farmer like most people do. Oh,

Ashish Rajan: now what I meant was, how, have you heard of the whole farm to table? Oh yeah. Yeah. So basically. Everything is picked from the farm.

Cailyn Edwards: But farm to my table.

Ashish Rajan: Yeah. Oh farm to your table. But you've been doing that way before.

Cailyn Edwards: Yeah. I've been I was, before I was a farmer, I was a raft guide and so I worked on a eco farm in Argentina and that's where I really got into into the grow it, cook it, eat [00:27:00] it.

Ashish Rajan: What are you taking? Software you could be doing so much more.

Cailyn Edwards: Make, making money is what I'm doing in software.

Ashish Rajan: A fair farmers make money from what I understand. But yeah, it, this is

Cailyn Edwards: Not software money

Ashish Rajan: fair. But I think is I didn't know that. Thank you for sharing that. The third question, what's your favorite cuisine or restaurant?

Cailyn Edwards: I am really into Vietnamese cuisine. I think like a like vermicelli bun is like up there for maybe my favorite. I think it's refreshing and filling.

Ashish Rajan: That's nice. I'll thank you so much for sharing that and I'll put your LinkedIn information and the episode sorry the presentation as well.

Thank you so much for coming on the show and thank you everyone. Thanks. Thank you so much for listening and watching this episode of Cloud Security Podcast. If you've been enjoying content like this, you can find more episodes like these on www.cloudsecuritypodcast.tv. We are also publishing these episodes on social media as well, so you can definitely find these episodes there.

Oh, by the way, just in case there was interest in learning about AI cybersecurity, we also have a sister podcast called AI Cybersecurity Podcast, which may be of interest as well. I'll leave the links in description for you to check them out, and also [00:28:00] for our weekly newsletter where we do in-depth analysis of different topics within cloud security, ranging from identity endpoint, all the way up to what is the CNAPP or whatever a new acronym that comes out tomorrow. Thank you so much for supporting, listening and watching. I'll see you next time.

‍