Mackenzie Jackson: Hello everyone. Welcome to another episode of The Secure Disclosure Podcast. John, thanks so much for being here today with me.
John Amaral: Mackenzie, great to be here. I love the pod. Happy to talk security stuff with you.
Mackenzie Jackson: Awesome. Awesome. We're in kind of swingy comfy chairs.
John Amaral: Yeah, great. I like, I like it. I might fall asleep.
Mackenzie Jackson: It's like a therapy session. We might need it after this because we're going to be talking about a pretty traumatic part of security at the moment, which is the supply chain. Why are we seeing such drastic activity in this particular kind of area of security? It's not new. It's always been a risk. We've talked about it, but now it feels really kind of very privileged. It's turned a corner.
John Amaral: Yeah, we've been using open source forever, right? Most software is open source software. Theoretically, the open source risk of maintainer compromise has been there all the time. It's always been a hard, it's always been a hard exploit to carry off and I think with AI enablement in the attackers and some successes, Shyude was a recent success, and I think it was actually maybe a follow-on to other minor successes that highly organized actors have figured out that they can exploit upstream in the open source supply chain, compromise maintainer credentials, take over their build systems and deploy weaponized payloads through those packages that actually propagate once they get updated in the developer's environment or wherever those end up. And they can do that at scale because it's a massive lever arm, right? You compromise in one place and you get it distributed. So it makes the open source package management systems into a distribution mechanism at scale.
Mackenzie Jackson: Yeah, it feels, you know, a lot like you're right and the model's been proven a bit these attacks recently, like it's with all of these successes, it's we have something to point to and these threat groups that are out there from the state sponsored ones to the more recent ones of Team PCP and all that. We have this, we have this kind of false image of them that they're just kind of rogue people, but they operate like businesses and I think that now that you've had some successes, they can actually calculate, they can, you know, what's going to happen.
John Amaral: That's right. And they can perfect these attacks and the methods. You know, in the end, these attacks aren't a CVE that got somewhere that caused a problem. They're the kinds of risks that are presented by humans basically going about their business, but can be social engineered or fished or what have you. So the attackers have found this to be extremely lucrative in that they can really infest massive areas and with AI powered exploit cycles now they can go really wide into the maintainer base of people and target them relentlessly, automatically and it makes the attack more efficient. It makes the cost go down. Now, it's probably not that easy with, I'll call it software savvy maintainers, to get them to steal their creds, but you just have to be right a few times for the right repos and you get this massive, massive impact.
Mackenzie Jackson: Yeah, we actually look at the attacks of how they happen. You know, we've seen some, you know, the phishing emails and they're very good, but also in the contagious interview style attacks that are going on. There was the recent, a recent one where the maintainer, you know, they get a business opportunity and fake air mic issues like, oh, here, download this to solve your mic issue. Like, and it's like, they're quite, they're quite clever. I want to break up, I want to kind of talk about two areas now. We have to talk about malware because that's kind of the vague. You also mentioned CVEs and I want to kind of talk about that and I want to talk about both of them as how has this next generation of development AI really impacted that? So let's start with the malware side of things. How is the malware part component just kind of accelerated, driven or how is it changed with AI coming into the scene?
John Amaral: Yeah, I spend most of my time thinking about software supply chain attacks and the Team PCP style attacks are super interesting to me. Again, the kill chain on that attack starts way upstream with the maintainers. But because they know they're going after weaponizing these, these, I'll call it package payloads, right, through the through the NPM system or what have you, they've really crafted a style of malware that's very good at propagating through the package ecosystem. So, so they'll insert it into a, into a library. The library comes down, it runs in Node or however it wakes up and runs and that that malware now activates and kind of continues to replicate itself into other repositories that you have as soon as, and it's, it's seeking tokens, access tokens, API tokens of all sorts locally, but it's also knows that it can self-replicate. So you've got these kind of package centric self-replicating like malware that's, that's really after stealing more credentials as far as it can propagate and then it can insert itself into the build life cycle for the next set of repositories that it infects and and away it goes. So I think I heard a some kind of a release by the Team PCP actors that they had something on the order of 320 gigabytes of compressed token payloads that they hadn't gone through.
Mackenzie Jackson: Crikey.
John Amaral: So it's a new kind of attack meant to walk its way down package ecosystems. It's super effective, right? And hard to catch, especially if you have auto updates on, which has always been the way we, going back to CVEs, which has always been the way we were trained to be secure. The maintainers patch regularly, patch regularly, patch quickly. And automated updaters are super good mostly until until you have to worry about it now.
Mackenzie Jackson: Yeah. Because the risk of updating automatically was typically like, oh, something's going to break in your application.
John Amaral: That's right.
Mackenzie Jackson: And then, you know, we had these powerful CI/CD pipeline mechanisms where we could test that happening, that gave us the confidence. DevOps maturity cycle.
John Amaral: We if you're good at testing then you can absorb these changes and if you push a lot of this, you know, back to the developer with the, I call it shift left mindset, you can help them get through the change cycle, but now it's weaponization that you're worried about.
Mackenzie Jackson: Absolutely. And so now, so now what, what we thought was correct, actually made us secure because now the risk is, oh, we pull in malware automatically.
John Amaral: That's right.
Mackenzie Jackson: And we're through the update cycle. Yeah.
John Amaral: So and, well, so then let's kind of switch. I think we'll come back to malware, but I kind of also want to understand some of these other components of it too. To why did we actually start doing those automated updates? And that's kind of the idea of CVE. So maybe if we just explain a little bit about not the malware component, but vulnerability cycle, right? So maintainers, you know, all these great benevolent, well-acting maintainers that have built the world of software for us and it's changed everything, right? So it's fantastic and and largely very secure on average. I mean, Linux is one of the most secure and successful open source and probably one of the first ever. Maintainers have always been pretty good about fixing CVEs. So, you know, they produce software, it gets out there in the world. People scan it, researchers look at it, and because it's open source, you get this kind of crowdsourcing security review and CVEs get reported to the NVD and propagate. And then maintainers see those of course and pick them up and fix them. And where they always fix them is in sort of the latest version, right? So, it's nice of them to do it at all and they care so they do it and it's fantastic. We were always able to take latest or you know, whatever that latest version is on that line and upgrade to it. It comes along with, you know, maybe some breaking changes or features, but also features and bug fixes. And that's been the path to goodness, right, for security. CVEs get fixed as they get, they get reported, they get fixed, we upgrade, we get them out. Now what they don't do is generally fix all of the versions back.
Mackenzie Jackson: Right. Yeah.
John Amaral: So, so yeah, it's always on latest, right? So, so we've been conditioned to take latest to get CVE fixes and what we need. And it's exactly the pattern, right, that forced us into auto-updating, which is a good thing up until lately. And that's what exactly the bad guys exploited. This idea that, you know, you've got to take them because you want CVE fixed, known vulnerabilities fixed, and in exchange you got some malware.
Mackenzie Jackson: And then we also had, you know, like the other kind of problem of this too is that, you know, things did break and often like, especially big bumps of things. And we kind of ended up in this world where we actually started to accept a lot of vulnerabilities in our systems simply because we couldn't change.
John Amaral: Couldn't change. Didn't have the resources. And it sounds crazy, but especially when you're dealing with legacy systems, you got tight production, it's not broken, right? And then you can convince yourself that it's a complex chain. This could actually be exploited on and all that. Complex as it may be, it's still a chain, it's still exploitable.
Mackenzie Jackson: That's right.
John Amaral: I we talked about effectively, you know, the way I was communicating, I'll call it a package in isolation, but that's not how it really works, right? It's a massive dependency tree that lives around pretty much any popularized package and those dependency trees interact. So interoperability can change between them and if you bump a version of something down your dependency tree, it can actually have a ripple effect where you have to upgrade a whole bunch of things, right? And one of those things might be something that if you change it, it breaks your system that you that that's built using that software. And that cascaded dependency inter interaction is what literally drives a lot of these like challenges. It's like, oh, if I bump this, then I got to bump that and I got to bump this and I got to bump that, which means, oh, my system's going to break and let's go talk to the engineering folks and ask them how long it's going to take to fix that. And they're like, I can do the thing on the road map or I can do the thing on the upgrade going to generate revenue, excitement, all of that. All the make money, spend money. Oh, let's see what which one do I want to do. And so that's that's been the challenge. And when you when you're stuck in that, you could end up like Spring Boot and these these Java libraries are notorious for being hard to move forward. You wind up with a massive amount of what's now tech debt and CVE pile up.
Mackenzie Jackson: I'm going to briefly interrupt this episode to thank our sponsor of the podcast, Aikido Security. Aikido Security is your complete code to cloud security solution. It secures everything from the first line of code that you write all the way through your supply chain, your dependencies. And of course, Aikido is also a leader in AI pen testing and AI code auditing. So, make sure you check them out today. You can start for free at aikido.dev. All right, enough about that. Let's get back to the episode. I I think we now can kind of talk about some of the solutions behind this so we don't turn this into a completely depressing episode, which I have had many depressing episodes on here, I will say. But you at Root are working on solutions to solve this and essentially a lot of that comes down to hardened images and various other kind of techniques. I guess how does how does that technology help solve it? And then I have a thousand questions about how the how the heck it works because it seems to be a black box.
John Amaral: And we have a nice integration with Aikido as well that we've had for like a year now that we can even bring into this at toward the end. But I'll tell you a little bit about Root. Root at its core has created what we call an Agentic Software Factory. And what it does is it combines a lot of really sophisticated AI agents and humans in the loop. And those humans are in the loop and the people around it are experts at maintaining and patching open source software. So we took what all these great people have in their minds about how to do this and we codified it as agents that can act autonomously. And at the core of that Agentic Factory, we make patches. Remember earlier I said the great maintainers fix the latest version, but as we just discussed, you may be on an earlier version and in some reasons stuck there and in some reasons want to stay there. And you think about being on an earlier version with Team PCP here, you might want to stay on N minus one.
Mackenzie Jackson: Yeah.
John Amaral: For as long as you feel safe there, which means pin it. We'll talk about the idea of pinning dependencies. Pin it, actually lock down your SBOM or lock down the dependency tree and use that one because you know it's not being exploited because you already have the library and it's not being rebuilt by the maintainers, possibly infected build pipeline. So at Root, we came up with this idea that if we could pin versions, have our customers pin versions of libraries, but our software factory could continue to backport fixes to those versions as many versions back as our customers want across our customer population, then we could be effectively the adjunct maintainer for any open source project. Our AI agents looking for maintainer releases of new fixes in newer versions where we take those fixes and really surgically backport just the changes around that security fix back to older releases, maybe four, five, six, eight releases prior. And then now we have this big shelf of patched libraries that we've cloned from the maintainer and continue to do the backporting work for them so that we know they don't go back and do this generally. So we could do it on behalf of our customers and allows them to stay on the versions they want to stay on either to avoid breaking changes or to avoid this Team PCP risk. We bundle that up in those patches in a few ways. One, we actually bundle it up as libraries. So customers can point their NPM pulls to us, their Pi pulls, they can point their Jfrog Artifactorys to us and act like a mirror. And then when they ask for a package, we can either direct them to what we believe is a safe version from open source by just proxying through, or if they ask for a version that we know has CVEs and it's an older version, we'll just source them the version that we have off our shelf. And that's the essence of the service. You can get it as packages or for convenience, we also make images with these packages built in hardened. Now the key differentiator for Root is as you might imagine, we don't have our own distros. We don't have our own versions of libraries. We we build from source and we rebundle, but we do it across a number of ecosystems. So if you're a customer who wants Ubuntu style or Debian style or Debian packages or Python packages, we're not going to force you into using our version of Linux where you have to kind of retool everything to reference that. We're going to say, oh, what are you using? Okay, we turn the factory on. The factory says, oh, I see that we have that. Here you go. Or I see you want it in this shape. So the factory turns on, the agents go to work, and they pull and reshape and rebuild in the form you want. So that we're trying to provide the highest likelihood that what we produce will be pin for pin compatible, so to speak, with what you're doing. And we want to make sure that you have very low adoption friction. Really, when you say change from, if you say from image name-Root, you can believe that's going to be compositionally identical to exactly the the packages, libraries, binaries that you already have. Only our factories remediated them for you and pinned them, right? I mean, so there's a lot going on there, but essentially it comes down to the fact that you can pin a version.
Mackenzie Jackson: Every version that removes the risk of malware, the TPVC, and then and then you would have had the risk of CVE vulnerabilities and all that stacking up.
John Amaral: Now you don't.
Mackenzie Jackson: Now you don't. Exactly. That's the answer. It seems like such an obvious kind of solution. Of course, you still want to upgrade packages for functionality, but it just removes that ability that need to have to do it for correct for for, yeah, on the on the interface with our company, like with our service. It's super simple, right? Like you're just telling us what images and packages you need and we're producing them like you just described and we continue to always watch them and pick CVE for you. You can specify which SLA you want from us so that you're getting them in time and we can do it very quickly and that interface just looks like a library manager or a or a or a repo to you. All of the sausage making happens inside the Agentic Factory where we're literally patching hundreds and hundreds of patches a day and and and working on thousands of libraries a day and thousands of images a day, recombining them, passing them through our our human reviewers who are approving all the PRs against those libraries, forking new libraries, cloning new libraries, reissuing patches back to the open source community, which we do because we we want to keep be really friendly. If the maintainer wanted to take one of those patches and use it across the backboards, we'd love it if they did.
John Amaral: Yeah.
Mackenzie Jackson: So, you know, we think we're an intermediary that's needed in this age to to help there, but we're really trying to be true to open source. We know that people chose those open source packages by and large because they um they like them, they need them. We want to see open source thrive. We just want to help with a maintenance model that helps, you know, the consumers have security choices that they probably don't have. And and if I were a maintainer, I wouldn't want to be in the business of uh I have been a maintainer. I don't want to be in the in the business of backporting stuff. I want to be in the business of building new cool stuff.
John Amaral: I mean, of course. And you can totally see it from the maintainer's perspective. It's like, no, well, I solved the vulnerabilities in the latest.
Mackenzie Jackson: Yeah, I did the job.
John Amaral: And and I added cool new stuff, you know.
Mackenzie Jackson: That's right.
John Amaral: And and like and just from the maintainer's point of view, too, it's kind of like, you know, there's you can't be thinking about everyone's edge use case. I mean, they'll scream and shout at you on GitHub.
Mackenzie Jackson: You can't control which versions they use and consume. They might have cloned the repo, forked the repo, done all the things. And you want to keep that available to everyone. It's just for production. And I'd say like you know, commercial use and production use and government use, you need to have, you know, security assurance and and yeah, there's been a gap. And with in the age of AI, we were able to, you know, figure out a way to do it in a, you know, that's cost effective and fast. And and really the speed in being able to to do this this maintenance work is really the key here, right? Because as you know, with with AI and Mythos coming and all the FUD around that, right, you can't human human patchers just can't go fast enough. Yeah, at scale.
John Amaral: I mean, and especially when you come to the fact that now, I mean, like there's a lot to say about the the Mythos kind of stuff, but I think one part that definitely is true is when a vulnerability was released, it would take some time for for exploits. That's almost instantaneous. It's like zero.
Mackenzie Jackson: It's like zero. It's like it's like a zero day. It's just like a zero day. We should make a, we should make a name for that. Yeah, I mean, that's exactly right. It's like yeah, the timeline is is has gone down. And with everything and the number of them stacking up, it's much wider problem and it's a much faster problem.
John Amaral: But it's kind of like that's that's actually a great use case because it's pretty much the polar opposite of what you are doing and how you're describing your factory works, right? As in I can use AI to create an exploit and your, you know, Agentic Factory that you describe, which is a great way to kind of think about it, is doing the opposite. It's finding these things and working backwards just kind of surgically.
Mackenzie Jackson: That's right. So it it, you know, these AI risks require an AI response. You can't mismatch these timings. Yeah.
John Amaral: The history of vulnerability management. Let's just talk about CVEs, not the malware part that we've already kind of scared everybody with. The CVE, it's it's true and Aikido is in the business of helping companies solve this problem. Every most every company's underwater with CVEs for all the reasons we talked about. Dependency management is really difficult. People don't know how to pin. And this is kind of where we can introduce a little bit about the integrations we've done. But in general, the average company has a massive CVE backlog. And what I'm hearing from customers and partners, I had some interesting conversations with a big partner this week. They basically told me that, you know, even status quo before the risk of of AI accelerating all of this by three or four orders of magnitude, most of their companies have a CVE backlog that's untenable. And they're really scared now, right? Because what Mythos, at least what we learned through the Glasswing project, is that Mythos can chain together maybe medium CVE in a way that turns them into kind of a critical exploit pattern. It's really good at seeing how one links to the other. And so they're worried about a deluge more CVE because AI accelerated discovery happens and two really complicated exploit patterns that that bring them together. If you're just scanning, triaging and and and and trying to dispatch that work out to the engineers, we know they're underwater. Then that's a human speed, I'd say, or traditional security workflow kind of response. It's not going to work, right? Because because the exploits will stack up at AI speed and the response will be at human speed and everything will break. So, our Agentic Factory helps with a bunch of that. There's other things that happen in in the organization, so to speak, with DevSecOps that needs to be accelerated. Aikido is doing a great job with those kinds of things.
Mackenzie Jackson: I want to ask a bit of a spicy question.
John Amaral: Yeah, let's do it.
Mackenzie Jackson: One of the things that Aikido does is SCA, software composition analysis. Is this pretty much now with this new technology going to become a legacy tool?
John Amaral: I think that in general the workflows that were revolving around traditional SCA, the stuff that kind of happened before this age and I and I'll put Aikido in a special class because you guys are AI born, you have things like autofix. It's actually, it's actually the answer for Aikido is actually different than everybody else in the industry. Let's just talk about status quo traditional SCA. Let's put it there and then I'll talk about Aikido because I think you're doing a really good job with this. SCA was, you know, scan, make a list, create Jira tickets. Maybe you use some reachability analysis tools to kind of prioritize which of those you can not care about and which you can't care about. You still end up with a pretty beefy list. You were doing these auto updates. Maybe you're afraid of that now, but but the list is stacking up and engineers need to do something about it. That's traditional and we know that it didn't work. Like didn't get resolved. We still need SCA. We still need to know which CVEs are in environment and the more insight you can have about where they manifest themselves, how, you know, which packages do it, the whole up and down the tree, that's good information and you need it. It shouldn't go away. So scanning will not die in my opinion. It's still crucial information. It's what you do with that information that really separates the the companies that I think will go forward and will will kind of die on the vine unless they do something different. And that response is really about remediation automation. Detection again is not enough. Way not enough. Aikido is a remediation first company. It's AI powered. I would say you guys are doing as good a job as I've seen, maybe maybe the best job I've seen at turning SCA results into something that actually turns into solved problems. Remediation. That was at the heart of our integration that we've had now for almost a year. It's the ability to match up our libraries and packages, and images with your autofix. You see some a problem there. You say, "Hey, if I just change out this this base image and if I just apply that library." And I'm going to make a PR for you and I'm going to make the Jira ticket for you and it's going to go into your build next time you do it. Just click yes. Suddenly you've got, you know, the the same package you had with just with just the patches. Now it's been pinned by Aikido. You've got this magic DevSecOps team that lives inside of the Aikido box that's going through with and throwing pixie dust over your things and it's low friction. It's high impact and you see remediation happen. And remediation is is is where it has to be. You have to do remediation now at AI speed to counteract the the exploits and the and the risks and CVEs at AI speed. And that's where the world is going and I think anything else will be just not useful.
Mackenzie Jackson: Yeah. No, that makes total sense. And and like going back to one of the things I always don't like to talk too much about Aikido, but one of the things that I love that we do is breaking changes analysis. Now we know, okay, we've got a critical vulnerability, upgrading is going to break the change. The solution is not to auto fix this. Let's pin it. Let's pin it.
John Amaral: Let's pin it.
Mackenzie Jackson: So then it doesn't need to be you don't need to pin everything. And I think that's like an important tool is that you you it's more of a precision, a precision tool that it is here.
John Amaral: It is and it's very aware of the of the software context, the functional context. And and I think that's key, right? It's remediation first with with the insight to know if you're going to do harm or break. And and it also keeps in mind kind of your maintenance model. There's a there's kind of a continuum of maintenance models. One, you may have a legacy piece of software that you know you you're maintaining, your customers buy it, it's still under life cycle control by the by the vendor. You may want to have a completely different kind of pinning and and strategy there than you would say with a green field where you want to be a little bit more loving of of new stuff. So you want to kind of live on the risk-free edge of new things so that you can have new features. Something there might be you pin, but you say, you know, I'm going to wait. I I won't take anything new pinned earlier than maybe 48 hours or a week. There's kind of a waiting period. Let's see what the malware response is. Let's see what the maintenance response is. If I think it's safe, then I'll take it and I can keep on the on the edge of latest for for various reasons. And that, you know, that's sort of like the one edge of the continuum, which is software that's evolving because we're building it and we're making it new and all the way down to software that I I make money with. I sell it to my customers, they love it. It's installed. It might be there for another decade. But I need to treat that differently and we're not really adding a lot of features, but we want it to be secure.
Mackenzie Jackson: Yeah. No, I think this makes total total sense. I I do want to play devil's advocate and ask some pessimistic questions because I think that people I think probably one of the the questions that people might have is, I mean, it is a great use case of AI updating these updating these versions precisionally. How can we trust that that has solved the issue? How can we trust that this Agentic Factory actually does what it says on the box?
John Amaral: Yeah. So as I mentioned earlier, we have a lot of experience making patches. These we have some experts at this that have been doing it for a long time. So we know what good looks like and we have human eyes on everything and that's I think that's an important thing. In the end, you're getting software change in response to CVEs. You're getting fixes. One of the things I mentioned earlier was this idea of backports. Backports are extractions from the maintainer. The maintainer of that code who knows it better than anybody in the world. So the original judgment about whether that about that patch will will will work will will fix the problem was actually the insight of the maintainer that we've extracted from the newer release and brought backwards. Now what does it take to do a backport? It takes one understanding the context of that patch from the maintainer. Two, being able to judge like which parts of it are are necessary to move back to a new version. And three, being able to contextualize those changes into the version you're trying to backport it to. Oftentimes these are very small number of changes. The average patch has just a few lines of of changes. So we we take that approach. We try to surgically extract just what changed for the patch only. And and often we're able to isolate that. Like when I mean often I mean like 99% of the time and then and then it turns out that AI coders are pretty good at recontextualizing. A lot of times it could be as simple as that those lines of code actually work exactly right in the older version, especially if it's like a small semantic version gap, but we do have to shift some lines around. Other times there may be like interface changes that need to happen, like the way you define the the function. There are more complex ones and actually our agents actually gauge the complexity that they have there depending upon that complexity gauge from like zero complexity to that's a pretty tough one. That's what we use to to provide insight back to the our our human reviewers and and and they'll see that, oh, this was a complexity rating of 70. So I better have my eyes on all of it. I'm acting like a patcher now. And and that could take a little time, but that's a very small fraction of the patches. Turns out these are mostly pretty straightforward. So so we use a lot of these kind of extraction techniques, experience from humans. We have a really smart tool chain and and and and all kinds of like assistance for the for the reviewers so they can go really fast. So look, in the end, you're accepting change when you get CVEs patched by the maintainer. Yeah, it there's there's no there's no avoiding the change cycle. I think it's it's taking care to make sure you do a good job with the backport and and we've made, you know, literally thousands and thousands of backports that are in production.
Mackenzie Jackson: We could talk about this for days and we, you know, there's a lot of topics that we haven't even covered. We haven't even talked about end of life components, which, but I think that at least this we we understand the technology, I understand a whole lot better.
John Amaral: Great.
Mackenzie Jackson: Which is quite important that I understand this technology a lot better because you, we have a bit of announcement.
John Amaral: We do have an announcement. As I've been very complimentary about Aikido, we've decided to join forces together with and and merge the companies and super exciting for me as a founder of of Root having been on this journey to solve this problem and as I was mentioning earlier, I think the combination of kind of our Agentic Factory and Aikido's ability to be in the mix with the developers and live by the code and bridge these two worlds, solve for malware, solve for Team PCP, solve for CVE remediation automatically with remediation. Like I think we're going to make the perfect solution.
Mackenzie Jackson: I I think so. I think so too. As you said, we've been integrated for a long time. But this just makes so much sense.
John Amaral: And the teams get along perfectly. We're we're actually kicking ass in in in development together. Yeah, absolutely. Yeah, it's going to be awesome.
Mackenzie Jackson: Cool. All right. Well, before we close up, I always like to play a game. The game is called Would You Rather? I give you two very crappy options, and you have to pick one. Okay. So now you can't cheat in this question. You can't say hardened images for this. Okay. Here's the question. Would you rather pin to the latest version now, but it stays there forever? And so, okay, you can't do it or add a degree of difficulty. Auto update everything.
John Amaral: I would rather pin to the latest version. Yeah. Yeah. I think in the end at least in this climate, I think on average, CVEs are kind of difficult to exploit and the exploit paths can actually be, I could I could use something else. I'm going to assume that I can't get any CVEs fixed. I have to, that's my assumption here. I think that's what you wanted me to do.
Mackenzie Jackson: Say that was the cheap. That's okay.
John Amaral: I would I would try to use compensated controls around the edges of whatever that system is to just try not to let attackers get at those CVEs. I'd look for the highs and criticals and try to do something else, right? And I know most of the lows and mediums are really hard to exploit, especially if they're on the inside of my infrastructure. So, I'd stick with that one because I don't want Team PCP running around my environment.
Mackenzie Jackson: I think that's why if someone put the answer to your question is like even if I can't get rid of the CVEs, I still have some control and mitigation. Whereas the other one is kind of like a Hail Mary. It attacked me while I was sleeping. Like updates happen and then I got to go figure out the extent of that attack. And I also assumed by the way that in my mind that it wasn't like something where I had a CVE SLA where my customers like forced me to fix the CVE. So there's a little cheat on my side with that with that Kobayashi Maru. Okay, another question here. Would you rather have all your secrets stored in a file in a private GitHub repository? So it's in the history. They're there. It's in that one file or you don't have any application firewalls for your for your system. So you can't block traffic, malicious, anything like that. So secrets in a private repository, no firewalls on your application.
John Amaral: I'd have to go with secrets in a private repository. I'd have to go there. I I'd have to I'd have to trust that and this is a really complicated trust scenario, right? I'd have to trust that my provider is has good security and they would, you know, protect my interests and the world couldn't see them and no one could get in there over what I know will happen is every AI agent will pwn my application like overnight, you know, like possibly. We have pretty good security on our apps regardless, but I always worry about the unfettered, you know, waves of internet gamma radiation coming at my coming at my apps when they're not protected.
Mackenzie Jackson: Okay, final question here. I'm just going to make a ridiculous scenario. Wormhole opens up and you can go into two parallel universes. One, AI exists. One, it doesn't.
John Amaral: Oh, AI exists 100%. Not only that, but I I'm I'm I'm generally too impatient for more AI. I want like more. Give me it all.
Mackenzie Jackson: Because I know a lot of people that love AI, want to use AI. However, given the choice, they're kind of thinking, but you know, I'd also be pretty stoked if it just vanished too.
John Amaral: I want it all faster.
Mackenzie Jackson: All right. Well, John, it's been amazing. Thanks so much for sitting down for you. It's awesome to have us working on the same team now together. Be exciting and I'm sure we'll sit down and have a chat about new things when they happen.
John Amaral: Let's do more. Pleasure.
Mackenzie Jackson: Awesome.
