Mackenzie Jackson: Hello, you are listening to the show where we bring you the latest and greatest in cybersecurity news, research, and leaders. My name is Mackenzie Jackson, and you are listening to The Secure Disclosure podcast. In today's show, we're going to be continuing our coverage of the plight that is malicious VS Code extensions. John Tuckner is joining us. He is the founder of Secure Annex and has recently put out some research in various different types of malicious VS Code extensions that he has found. We're going to talk to him about that and also why this is such a big trend right now. We're also going to briefly cover some other research that looks at why secrets continue to be a problem, particularly in leading AI companies. We're also inviting onto the show Vangelis Stykas, who is the CTO and co-founder of Kumio, and we're going to be discussing how we can secure our energy infrastructure and why this is actually pretty vulnerable right now. All right, enough from me. Let's get into our first segment. We have previously covered on this show various different reports of VS Code extensions being turned malicious. We've brought on researchers like Remy McCarthy, Charlie Eriksen, to discuss this, and today we're continuing. John Tuckner is the founder of Secure Annex. They've recently got a lot of press coverage about some malicious VS Code extensions that they've found: RansomVibe and Sleepy Duck. I, of course, wanted to ask John about these specifics because it's very interesting. But I also wanted to dive deep and get his perspective of why this is such a big problem right now and have attackers really pivot away from other supply chain attack paths like NPM. To start with, I asked him what made him start looking at VS Code extensions in the first place.
John Tuckner: About a year ago, I started a company called Secure Annex that specifically just looked at browser extensions. I thought there was a real gap between what Google was releasing in the Chrome Web Store and what people were actually installing, and more importantly, what companies actually cared about and what they thought was actually risky. And as I started getting going with that, there was an incident called CyberHaven related to CyberHaven last year that a lot of companies really took notice that browser extensions were a big problem. And so my initial customer set really adopted my understanding and analysis of extensions. And that kind of led them to asking me to start doing VS Code extensions because they're basically very similar. There's just JavaScript behind the scenes at the end of the day. And why shouldn't I be able to apply this understanding of what the extension is actually doing versus what the marketplace actually says to something like code extensions? And that really kicked off a second half of the year. The last six months I've really dug deep into code extensions, and honestly, they've been shocking me at every turn.
Mackenzie Jackson: Now, some of you may be wondering, why is this such a big target? Because traditionally we've covered things like when NPM packages are turned malicious and you can understand the massive impact of that. You could potentially target thousands of applications by turning one NPM package malicious. Well, the same is kind of true for VS Code extensions. You can have a large attack surface if you turn a popular VS Code extension malicious or manage to create a popular malicious VS Code extension. But it's actually targeting developers themselves. So I asked John, why is this true? Why are developers themselves being targeted and not so much applications or infrastructure?
John Tuckner: I think when you end up on a developer endpoint, there's a lot more to be done than just ending up in somebody's code. It's not to say that running something in NPM can't compromise a developer endpoint either, but I think the code extensions are much more specifically trying to gain access to everything that you or I might have instead of a build system. There's credentials laying everywhere, but it's really kind of open-ended. When you have a developer endpoint that's compromised, you might be able if you install ScreenConnect, you might be able to get access to their email and reset their GitHub token and do so many other different sorts of things that it's really limitless. And so when you actually compromise one of those endpoints, it's almost like you have an admin level machine into an organization. And most of the time developers do have that level of right given to them just because they're the ones creating the code that creates the company money. And so I think that's why the focus is on what's a way that I can one-click get remote code execution into developer machines: the code marketplaces.
Mackenzie Jackson: Coverage on this topic has been a lot lately. I spent the first half of the year talking about NPM non-stop and I seem to be spending the second half of the year talking about VS Code extensions. But is this actually a new phenomenon? Well, John suggested actually that it wasn't.
John Tuckner: Nobody was really talking about code extensions in the marketplaces like the VS Marketplace and Open VSX. And so if nobody was really analyzing these extensions, then who's to say that there was actually any problems there? But I've seen traces going back like three, four years of extensions that could possibly have been malicious that are still kind of out there in the marketplaces. So while I think it's always been a threat and been a problem that just nobody talked about, the last six months have really picked up because of a lot of friction between Microsoft, Cursor, Open VSX, and the VS Marketplace. With Microsoft cutting Cursor users or Win Surf, these code editor forks, they can no longer install extensions from the VS Marketplace. So I think attackers have really took notice and have started going after Open VSX to be able to push their malware.
Mackenzie Jackson: One of the malicious extensions that Secure Annex found was dubbed RansomVibe. Sometimes malware is interesting because it has a big impact. Sometimes malware is interesting because it's novel or uses very sophisticated methods. And sometimes malware is interesting because it's none of those things. See, with RansomVibe, it was a vibe-coded malicious extension, and you couldn't have made it more obvious that this was malicious. It went as far as stating its malicious intent in the readme, which kind of leads to the question of why didn't this get discovered?
John Tuckner: I caught this extension just right as it was published. It has very little impact to people out there. And so we were able to report it, get it taken down pretty quickly. But it's just shocking that even from the marketplace listing, it's basically saying that I'm going to encrypt a folder, I'm going to upload it. There's probably C2 involved in here. And so I'm just kind of shocked that even something as simple as looking at a marketplace listing is allowed through the marketplace. And then you start looking at the code and there are just these, it's so simplistic and it's so verbatim of what it's doing. Here is where you encrypt files and this is the ransomware key and this is how you leave a note and comments about now performing C2 actions. And it's so blatantly obvious that this is trying to compromise a machine. I'm just shocked that it makes its way into the marketplace. And so if there's any more sophistication in these attacks, we're in for a big problem.
Mackenzie Jackson: It's easy to say, well, shouldn't VS Code Marketplace or the Open VSX Marketplace or other these third-party marketplaces just ban malicious extensions? Couldn't they just find them and search for this? Well, it's a little bit easier said than done. That's because what makes these extensions malware also has legitimate use cases. There are legitimate use cases of why you want to Base64 your code or call back to a C2 server or communicate with GitHub in the case of a lot of these. So it's a little bit harder of a problem than maybe you first think.
John Tuckner: I think it's really hard to perform known good analysis on extensions, on code extensions, because there's no permission structure to them. So you can't say, "Okay, this extension will make web requests," or "This extension will work outside of the workspace that your code editor is currently in," "This extension will access your environment." None of the none of those protections are set up. So it's really just open season on what capabilities can you introduce into a code editor extension, what they're able to do, and who's to say if those techniques and those behaviors are malicious or not. So yeah, this extension just utilized GitHub as a C2. I'm sure GitHub would be utilized by a code editor extension. It was just accessing the file system to read some files and move them. I think a lot of other extensions do the same thing. It's only when you really look at the code and say, "Okay, it's console logging, performing C2 actions," does it really stand out and make you worry.
Mackenzie Jackson: The other malicious extension that John found, which is a little bit more sophisticated, was called Sleepy Duck. Interesting here is that at first this wasn't actually a malicious extension. It was turned malicious later on. Solidity is a language that Ethereum uses to write smart contracts. So it's probably no surprise what this malware did. It was trying to steal Ethereum. But I asked John to kind of take us through what makes this unique and significant.
John Tuckner: Sleepy Duck was a name squat on a very popular extension called Solidity that helps Ethereum developers create contracts for the ecosystem and process transactions. This has been a very popular attack. I've traced at least like 30 other of these instances of people trying to replicate the Solidity package and act as it, manipulate their downloads, show in the marketplace as the most popular extension. And commonly, extensions for developers will click on that extension, install it, and the second that you do, your machine is compromised. So, nothing really shocking there, like the Solidity type of squatting, what you're able to see on the marketplace is a very popular common attack and that honestly makes it really easy to catch as well. But, once you look into the extensions, they all do just similar, slightly different things. So, there's been an evolution of behaviors over time. So, it used to just execute verbatim malicious commands to download ScreenConnect remote management software. Now, it's kind of moved on to a bunch of other different techniques. The latest is this ability to it will reach out to a command and control server for commands to execute. But like traditional malware, if you were able to ever take down that remote server, file an abuse report, then their capabilities would be cut off at the server level. But when you, when it has a backup C2 using an Ethereum contract, that's much harder to take off the blockchain. And while everybody can read what the Ethereum contract says, it's harder to get that update to say, "Okay, they've changed to a new C2 server," or they can even issue commands from the Ethereum contract. And so even if you don't get that extension uninstalled, then that's their machine for as long as the extension stays active.
Mackenzie Jackson: There's a malicious extension that's pretending to be a normal VS extension. So, a lot of you probably would be wondering, well, why would a developer actually go ahead and download that in the first place? Why would they download the malicious version and not the legitimate version? Well, there's actually a lot of sneaky tactics that attackers can use to try and trick developers into thinking that this is actually the legitimate version. Open VSX, for example, actually allows you to manipulate the download numbers so that your malicious package actually gets delivered ahead of the non-malicious versions. I asked John to take us through exactly why that's the case and how that works.
John Tuckner: Yeah, in the VS Marketplace, I think they have a real protection to this, although I've seen them definitely have inflated numbers. For Open VSX, I think it's just you make an API call. They don't have the same telemetry tracking of marketplace to endpoint. So, it's very hard for them to verify that a download is real. So, basically, as many times as you hit the download URL, you can basically pump the number. And so, as long as you're making the right web request to the marketplace, you can go from zero installs or downloads to 54,000 really quickly and that bumps it above the known good Solidity extension. So, when you search in the sidebar for Cursor, it is the first result sometimes.
Mackenzie Jackson: And finally, I wanted to know what can we actually do to stop this. So, John walked us through what he recommends needs to change so that we can actually start getting on top of this problem.
John Tuckner: It's tough, right? Because even though you have trillion-dollar companies like Microsoft, they're only going to put so many resources into security scanning for these marketplaces and to be quite honest with you, I don't think it's in their incentive to do so, right? They need as much capability, as much functionality in these marketplaces. They want to be the source for these extensions to get out to developers. They want to have the solution for everybody. And so, they're going to take down malicious extensions only when they absolutely have to. I mean, I'm a fan of just starting with the basics. So, you need to gather an inventory of the code extensions. I think this has been a very overlooked portion of security for far too long and so, teams just don't even have the basics set up yet. First, you need visibility and you need to have a list of all the extensions that your developers are using, know them from the extension that's used 40 times to the extension that's used once. But, once you have that list, then you need understanding of what they're actually doing and nobody can look through the code of each of those extensions by any means. And so, yeah, the company that I started was Secure Annex. That will download these packages from the marketplaces, analyze them, perform static analysis, perform an AI understanding of what the code is looking to accomplish and that's been really successful in understanding like this is what it says on the marketplace listing combined with here are the behaviors in the code to give teams real actionable understanding and be able to take out extensions that they think are too risky or ones that are actually compromised, right? And so, if you pull a list of a couple thousand, which is not out of place for a lot of the companies I work with, you'll be able to instantly tell here's some that are known malicious or here's ones that are more risky than others.
Mackenzie Jackson: I also wanted to touch on research by Remy McCarthy, who's been on this show before. Him and fellow researchers at Wiz released a report that showed that over 65% of the leading AI companies had publicly exposed secrets. So, when we say secrets, we're talking about things like API key security certificates, even plain text passwords. And often, these leak out. We've covered this before. GitGuardian found 22 million secrets in public GitHub repositories. And sometimes, you could put this off to maybe that's just junior developers or students or kind of old historic companies that don't know how to manage things properly. Well, this report shows that even companies on the bleeding edge of technology right now, the AI leaders, are exposing a lot of secrets. The first thing that you'd learn as a developer is don't hardcode your secrets. But, often, you still do it. And the scenario that this typically happens is that when you're working on a development branch, you hardcode something, you test it, then you remove it, not knowing that it actually exists in your history. And this is something that the research report really focused on, doing deep scans in public repositories belonging to these AI companies in their history. The companies were from the Forbes AI Top 50. So, as I said, companies on the bleeding edge. And only 35% of them didn't have exposed secrets. And these secrets can grant an attacker further access. You only need one leak secret to start a chain of events that can give an attacker a foothold into the most sensitive areas of your infrastructure. The most common secrets that Wiz found was Hugging Face API keys and Google API keys. One interesting thing, which is part of the problem is this, is that disclosure of these types of security incidents is actually really hard. The report states that over 50% of disclosures that they tried to make either didn't end up getting to the recipient or were never responded to. The report touches a little bit on where some of these secrets were found. For example, keys from Long Chain were found inside Python files, but also importantly inside .env files. These are sensitive files that should never end up inside your Git repository. Level Labs also had secrets inside their mcp.json file. And there is some interesting research about MCP services that is going on right now as well. And whilst the idea of secrets leaking in public spaces isn't new, it does reaffirm the idea that we absolutely need to implement secret scanning in our version control systems like Git. We need to make sure that that does deep historic scans in all of our branches. And while none of this is all that new, we've been leaking secrets since we created secrets. But, what it does show is that this is a systemic problem that isn't getting better even for companies on the bleeding edge. So, we need to absolutely ensure that we have secret scanning in place that doesn't just look at our top layer, that looks at our entire history. Which is, of course, a great segue to talk about the sponsor of this video, Aikido Security. Aikido Security is your all-in-one security platform. If you want to secure your applications from the first line of code through the cloud, if you want to ensure the code quality and, of course, if you want to ensure you don't have secrets inside your Git repositories, then make sure you check out Aikido Security for free at aikido.dev. And in our last segment of Leaders and Legends, I get to sit down with the leader and legend Vangelis Stykas, who is the co-founder and CTO of Kumio. Kumio is a company that's securing the future of critical infrastructure, the energy sector. Critical infrastructure like energy networks are big targets for attacks, particularly state-sponsored attacks. We've seen this a lot during conflicts like the Russia-Ukraine conflict, where Russia, for example, has targeted Ukraine's critical infrastructure trying to hack into their power grid. Vangelis has been a legend in security. I've talked to him before about his work hacking hackers and getting into C2 servers. But, he's also done a lot of research in the energy space. It's something that he's clearly passionate about. So, I wanted to sit down and talk to him and understand why there's so many security gaps in our critical infrastructure and what we can do about it. Vangelis, thanks so much for joining me here today. I really appreciate you coming on the show.
Vangelis Stykas: Thank you for inviting me, Mackenzie.
Mackenzie Jackson: So, I wanted to get started. You've recently launched a new company, Kumio, which is focusing on securing critical infrastructure, specifically kind of energy infrastructure. I wanted to start in an obvious place, maybe is why did you feel that this sector in particular was lacking or needed intervention?
Vangelis Stykas: I do believe that most of the critical national infrastructure right now in Greece and in the States are in a limbo state. I have been the person, together with a couple more, that have been crying wolf for the past five or six years and telling everyone that we're insecure, we are just a huge incident away of awakening and it seems that those incidents kind of start piling up. So, it's now or never. The energy sector, but also all the OT and critical national infrastructure are in a phase of transitioning from old of how we thought OT was. So, things that would never have been put online to things that are put online and we see monstrosities like RJ45, RS232 to TCP/IP, things that should never happen open on the internet. So, we need to secure them. And by we, I mean everyone. I don't mean just my company. If anything goes down, if energy goes down, pretty much everything goes down. So, we need to be 100% sure that this is not going to be a snowstorm.
Mackenzie Jackson: And I mean, we definitely are seeing critical infrastructure repeatedly being targeted. It's been targeted in Ukraine a lot, obviously, and it's also kind of been a target in the US. You've done a lot of research in this area. You've spoken about it at DEF CON before. Kind of what are some of the key vulnerabilities that you see out there with critical infrastructure? Why is it, in your opinion, kind of so vulnerable to attackers?
Vangelis Stykas: My released research, because there's more research that is coming in the next years because, unfortunately, when you do research in critical national infrastructure, you have to do the responsible disclosure and full disclosure and wait for it to be patched and then disclose it because otherwise you're giving a huge weapon on a lot of people. My research, because I focused on that, was mostly on insecure APIs and non-secure web applications on controlling the installations of photovoltaic solar panels, hydroelectric and EV chargers. There are more research, as I said, coming for BSS and wind turbines. The thing that we see over and over again is that they don't really care about the security or they put the burning effort in securing their APIs. So, you end up having admin access on everything or even worse, admin access on their servers. And the other really depressing trend that we see is that even when you tell them that there is an issue, they usually act really slow. Vulnerabilities will happen. It's a fact of software engineering. You build things. Sometimes you don't build them right or some bug creeps in and you end up with an either you end up with a wrong ACL, you end up with anything. It's how you treat that vulnerability once you find it that makes a good vendor than a bad vendor. There is no such thing as no vulnerabilities in the modern age of software engineering.
Mackenzie Jackson: In your public research, you've talked about things like the fact that kind of PV and EV or if we're going to talk about EV chargers, their API endpoints kind of almost have no authorization and no access control at all. Why, why did we get, why do we end up in a situation where when that happens, it kind of seems crazy to anyone that you would have kind of these open doors everywhere, particularly when we're dealing with things like infrastructure?
Vangelis Stykas: Actually, a really good POV. It's not happening on everyone, but from time to time we do see an EV or a PV or whatever critical national infrastructure that was stitched together and it had literally no authentication at all, no authorization or it had authentication when you logged in and then it just ignored everything. This is what I like to say, what we say, "rush to market." So, they push so that they get the green wave so that they're on the forefront of the market so that they can get to the market first. So, they didn't care about security and once they were out as the product, they didn't care. So, we have that strange position that people who are controlling a lot of our power were really rushing their products in and now you have them installed in hundreds, if not thousands, if not hundreds of thousands of points and they're totally insecure. So, you have to force them, and by you, I mean everyone, to take security really seriously and rebuild their products with security in mind.
Mackenzie Jackson: In your talk at DEF CON, you talked about something called kind of grid cascade. And I thought maybe this would be interesting to bring up now because what it kind of meant to me, and maybe you can correct me if I'm wrong, is that you don't actually need to attack the entire grid to attack the entire grid. And how it kind of works is that if you can take out chunks of critical infrastructure or chunks of these solar panels or something, that you can kind of create a cascading effect. Is that a real risk that we're seeing? If you put a few of these products with limited security in the grid and knock them out, that it will kind of have a follow-on effect?
Vangelis Stykas: First of all, it was done. The first initial research was done by a really nice guy that I cannot pronounce his name and I should pronounce because he's done a great work and he has done more research. And also, this is not my expertise as in the electrical engineer, but it was proven with people who are smart. And unfortunately, it was also proven by the recent Spain-Portugal peninsula that we have changed our grid to be interconnected, be more and more dependent on solar panels, and that could have a cascading, that had a cascading effect last May when something went wrong to a couple of solar factories. We still don't know what happened there. We cannot say that this was a hack, but we can see that once the solar factory, the solar farm, two solar farms went down, it became an escalation issue and then the demand couldn't be met, so we had a full blackout of two countries. It's no longer a fact of, "Oh, we do have the math and it works out." This happened. I didn't, I'm not saying that this was an issue of a security issue because we don't, we don't know. We don't have logs for it and I guess there's going to be a thorough report once we have it, but we saw that taking down two large farms can cause a huge blackout. Now, what remains to be proven is, can this be, can this happen if we took more smaller plants? My educated guess is yes, but also I have to say that because every time in my talks it's like, people don't do it. This is a huge crime, so don't go around hacking solar farms, but it seems that a lot of, look, I have to say it every time because don't go around and say it, but it seems that national state actors are doing it already and they're in a lot of power plants already, unfortunately.
Mackenzie Jackson: Yeah, yeah. It's funny, it's not a POV, a proof of concept, a POC that we need to that we need to build out.
Vangelis Stykas: Yeah, it's not a POC that we need to build out, but again, being that guy, I have been saying that this would happen for the past three or four years. We are dependent on things that are unstable and insecure. And everyone was saying that, yeah, well, the power grid has been like this for the past 50 years and we are not seeing any blackouts. Well, now we do have a blackout already. Some more, too. And we need to be extra careful and super conscious of how this can be handled.
Mackenzie Jackson: Yeah. This next part I, it's probably going to go into the realm of kind of speculation, but I kind of want to get your opinion on it. We're about to see a gigantic stress test on all of our energy sectors when it comes to these gigantic data centers that the AI overlords are kind of building out now. And we're kind of entering into a power, a power battle. Who's going to be able to generate the most amount of power? What kind of impact do you think putting these gigantic nodes of strain on their kind of an inadequate power system is kind of going to do? What do you kind of make of what's happening in the kind of gigantic data center space that we're seeing?
Vangelis Stykas: All right. Now, the data centers were mostly placed into places that had a good latency, good backbone. Right now, we see enough getting more data centers where the power is cheap or we can also generate with a self-powered green. We see here in Greece and Greece right now a couple of data centers being built in places that they can generate a lot of solar power. So, it is there. So, I can take advantage of minimizing the cost. Again, I'm not an expert in there, but my educated guess is that these stress is going to cause more pain points in several issues. And it will also generate new attack vectors because I can guess. And again, this is a guess-timate and I don't like guessing, but the, during the day, at least in Greece and in places that have enough solar power, most of the power will be self-sustained, but AI will need to run day and night. So, on the night it will have a bigger demand of the grid. And also a really interesting problem to see from the security point of view because we are going to have a lot of new attack vectors that we haven't thought of.
Mackenzie Jackson: Yeah, definitely. Well, that sounds like a very cheery, a very cheery uplifting kind of news that I can I can I can talk about.
Vangelis Stykas: Well, again, I'm a person who is pessimistic by nature, but optimistic by choice. So, I do believe that people are know about these issues and they're working on those issues, but this comes on the nature of the actual OT industry and everything. So, in contrast to the startup market that we want to go fast, all the people in the energy sector and in the CNI sector are really slow decision makers. And we do see people caring about security and trying to solve the whole issue in both in both Europe and the US. So, I'm comfortable saying that we will get there. Not as fast as we should, but we are doing steps in the right direction.
Mackenzie Jackson: Well, I I I definitely think so. And let's talk about those steps now because at Kumio, you're specifically focusing on security in this section. What are you guys going to kind of bring to the table? What is the gap that's currently missing that you can start to plug up and start securing this infrastructure with Kumio?
Vangelis Stykas: Well, what we are doing, the offensive agentic AI, the thing that it does having the 24/7 penetration tester in your OT. Our agent has already discovered, let's say six CVEs on different OT stages. None of them is published yet, unfortunately, because they need to be patched. And as we said, it takes a lot of time to patch those things. So, the actual problem here is that most of the people in this industry don't have the time or the money to secure themselves. So, we are providing them with a 24/7 senior penetration tester that will check all their systems and try to find the report and report those issues. It will generate a report with all the remediation steps. And further down the road, right now we do have defense companies that also cyber defense companies that do that. But we will have the remediation steps built in the AI agent eventually.
Mackenzie Jackson: The AI pen testing, I think it's going to be a total game changer. As someone that has a deep history with offensive security, do you think that in the future agentic pen testing is going to completely release replace the need for kind of human-based pen testing? Or do you think that the two can kind of coexist and focus on perhaps maybe different areas of vulnerabilities?
Vangelis Stykas: That's a really good question and a question I cannot answer, unfortunately. I'm not an AI specialist. I'm an offensive researcher and I like saying that the AI will not replace us. But and there this is a huge button here. The agent has already found things that I missed, on things that I took a huge bite off. And then when the vulnerability was pointed to me by the agent, I was like, "Oh, I should have gotten that." Because it was there. So, I want to say that it's going to be coexistence, but it might totally replace everything. And it's okay because at least for the heavy lifting and the footwork and the things that are really boring, it should replace you because it will never be tired. It will do the research. It will do all the scans that you need 24/7. And then you can review it, at least now. Right now, though, I do believe that we are moving towards an AI native fully autonomous way of handling all the security. Not right now, but we are moving there. We are doing steps into getting there.
Mackenzie Jackson: It is really interesting. And you know, at the moment, I think the real power of AI pen testing is this augmentation where it can discover things or look at things that you didn't think of and vice versa. But it is interesting. I don't think anyone really knows what the future holds. It's a lot of uncertainty. But it's definitely going to be kind of a really big, a really big help here.
Vangelis Stykas: Well, at least that's my opinion. I think AI is going to be a total game changer. It's already. It's not going to be. It's already a game changer. We do see AI agents that are listed first in HackerOne. We do see a lot of things in web application penetration testing because that's where all the agents went.
Mackenzie Jackson: We're approaching the end, but I always like to kind of play a game before we get people out. So, I want to go into a game called "Would You Rather," which I'm going to give you two security options. Both are going to be very crappy, but you have to pick which one would you rather. So, the first question that I have to ask you is, would you rather have all of your secrets in an application stored inside a private Git repository in a let's say, in an environment variable file or hard-coded, or would you rather not have that, but not be able to use any kind of firewall on your application, so everything is public? Which one would you rather?
Vangelis Stykas: I would pick the second option.
Mackenzie Jackson: Yep.
Vangelis Stykas: Again, both of them are terrible, but I would pick the second option.
Mackenzie Jackson: All right. Going to another question here. Would you rather never be able to update dependencies, so all your dependencies are pinned to their current version, or always pull the latest version every time you run a build? So, we're going to deal with malware, we're going to deal with breaking things. Which one would you rather?
Vangelis Stykas: I don't know. That's, that's a really tricky one. I would guess pull everything, but also have a DAST run of everything, but that both sound really terrible.
Mackenzie Jackson: Yeah. Yeah, both are terrible. All right, and last question here. I'm going to change this one up. I'm going to do it for the pen testing version. Would you rather only be able to use kind of your agentic AI systems for pen testing or never be able to use AI for pen testing? So, you know, if you're going to go into a penetration test, you either can only use agentic AI systems or you absolutely cannot use them. Which one would you rather?
Vangelis Stykas: That's a question of time, though. Are we talking forever or right now?
Mackenzie Jackson: Let's just say on the next penetration test.
Vangelis Stykas: Well, I'm old. Right now, as I said, although the agent found things that I lost, I am old and I like saying "back in my day," so I would say I want to do the actual pen test. But if you're talking about the next couple of years, I will switch to just using agentic AI. Because we are bound to be replaced eventually, but right now we still want to believe that we are better.
Mackenzie Jackson: I love it. All right, Vangelis, I want to thank you so much for coming on to the show. As always, it's super, super interesting. And for the listeners, there will be links to Vangelis related talks, the DEF CON one that we brought up in the comments, so please make sure you check that out. So, Vangelis, thanks again for coming on to the show.
Vangelis Stykas: Thank you for having me, man. And I'm wishing you all the best in your new adventure on Kumio. Thank you for having me, Mackenzie. Always happy to talk with you.
