Mackenzie Jackson: Hello everyone. You're listening to the show where we bring the latest news, research, and leaders in cybersecurity and tech. My name is Mackenzie Jackson, and this is The Secure Disclosure. We have an amazing show for you today. It's probably no surprise that we're going to be diving deep into the Shai-Hulud campaign that was propagating throughout GitHub and npm this week. We have some great guests to talk about this. We're bringing on Charlie Eriksen, one of the researchers that was fundamental in discovering this and understanding how far it was going. We're also bringing on to the show Daniel Pereira. Daniel is a developer that actually discovered this first. We're going to talk about his mammoth journey to try and raise the alarms, which is quite an uncomfortable story to talk about. And then finally, we're bringing on Gaetan Ferry, who's a researcher at GitGuardian, who actually helps us dive through the postmortem of what this actually impacted and what you should do if you're affected. It's going to be a great section. In our next segment, we're sitting down with an open-source security legend, Martin Knobloch. Martin has been working with, volunteering, and contributing to the OWASP Foundation for years, and we get to sit down and talk about shift left, what it means for security, how it can be implemented effectively, and where it fails. It's a pretty fascinating segment, so you're going to want to stay tuned for that. All right, enough from me, let's get into it. It seems that nearly every single week now, we have some kind of internet world-shattering breach that's involving npm. Last week, unfortunately, was no different with the Shai-Hulud campaign that was taking the internet by storm. Now, to recap, this was a malware worm that was self-propagating, which meant that once it had infected a few packages on npm, it would actually go ahead and steal credentials to try and infect more packages automatically. There was the potential that this would get out of control. Luckily, just in time, word got out there, and the security community was able to wrangle it down. Now, last week we did an episode on the massive breaches that happened in npm. Part of that story was how the security community came together and acted in singularity to get this sorted. This week, it's a little bit of a different story. We're going to start the segment by talking to Daniel Pereira. Daniel is a developer from Brazil, and he was the first person that actually found this. What should have been a win for catching it early turned into a little bit of a nightmare. See, Daniel tried to raise the alarm. He reached out to everyone he could possibly think of. He then went into Discord channels to try and spread the word, and he was banned from them. He posted it in forums like Hacker News and got absolutely no interest. Ironically, later on in the day, this story would be the number one thing that anyone is talking about Hacker News, but conveniently, his posts were completely ignored. So, unfortunately, this isn't a story about the security community having a win. This is a story about how the security community completely ignored a threat for many, many hours until finally someone listened. Daniel, I want to start at the beginning. Can you please tell us how you discovered this threat, what you were doing, and what kind of raised alarm bells for you?
Daniel Pereira: Sure. Just a little bit of context, I don't work at NativeScript, but I admire the framework. The day before yesterday, when it all, I was looking into one of their community packages, and I see this weird branch named Shai-Hulud, right? I was like, "This is strange." So, I looked into it, and there was only one file, which was shy-hood.workflow, and I decided to open it. When I opened it, I saw three things, which was secrets, webhook, and curl, and I immediately knew that this was really bad. Then I decided to, "Okay, so there was this rush of adrenaline," and I was like, "Okay, there's something really bad going on, so let me look to make sure that I don't want to freak out for nothing." So, I looked into it, and there was a curl passing this content environment variable and sending this payload to a webhook, so sending this out to the world. Then I was like, "Okay, so there is something bad, and I need to warn the people in NativeScript." And so, I looked into other repositories to see if there is the same branch, and there is the same branch on a different repo with the same file, and immediately I get my phone, I call Ed, which is a guy from NativeScript, he's in the TSC at NativeScript, and I was like, "Ed, there's something wrong, this guy is leaking secrets, I don't know how this is happening, but it's happening." So the next thing is me, him, and a couple of folks from NativeScript on a call. They're doing everything to remove access from this guy and check for other repos for published versions, because if this guy got hacked, maybe someone published a new version, and they realized that there were actually new versions being published that were not intended to be published. I decided to search for this Shai-Hulud on GitHub because it had affected NativeScript, but maybe it affected other repositories as well, and when I searched it, I was actually trying to find branches, but it showed me repositories. There is this repository called Shai-Hulud, I clicked on it, and there is this weird data.json JSON file with a giant string, and I knew that it's Base64 encoded because it has certain shapes, and I was like, "Okay, let me try to decode that." So when you decoded the same data.json content twice, it would give you secrets, and at that moment I was like, "Oh my gosh, this is really bad, like really bad. People are having their secrets leaked on GitHub." There was this npm package.json, and it has the full path. So GitLens was installing Tiny Color, and this guy was infected by Tiny Color because you could see the lifecycle event, and it was a post-install, and it was executing this bundle.js which is using Node, right? So I was like, "Okay, let me take a look into Tiny Color." When I look into it, it was version, the latest version was published like five minutes ago or 30 minutes ago, it was really recent. I was like, "Okay, is this version on GitHub?" It wasn't. So I decided to use this code explorer on npm, and you could see that there was a bundle.js file, and there was a package like inside package.json the post-install was executing that file. I went to the original repo, this didn't exist there. So clearly this was modified, I don't know exactly if this was self-replicating, so I was like, "Maybe someone published this."
Mackenzie Jackson: So once you figured out that this was bad, you knew something was wrong. What did you do? How did you try and reach out to people?
Daniel Pereira: I decided to reach out to GitHub, right? I tried to, on my LinkedIn, I know some people that are influential, so I tried to reach out to them, and I was like, "Hey guys, do you have a direct contact with someone inside Microsoft or GitHub?" They were like, "No, but maybe you can send them an email." I was like, "Okay, let me send an email to security@github.com," right? And then I sent an email. I got a reply back that my ticket was created, and nothing else. And then I was like, "Maybe I cannot find someone, but if I post this on LinkedIn and people repost it, it will reach someone from Microsoft or GitHub." People that work with me here at Loca, they had some contact with someone from GitHub, and they tagged them, and I messaged the guy from GitHub, and he was like, "We created an internal ticket," and I shared everything I knew so far, and he was like, "Okay, I'm forwarding this to the internal ticket." But there was no this sense of urgency, like things are being exposed, and they were like, "Okay, we are creating a ticket." And then I decided to report to npm because, "Okay, so it's not a problem only for Microsoft and GitHub, it's also for npm." So I reported there, and I got a ticket, and I think I didn't get an answer until today. So I was very frustrated. I was like, "What do I do now?" I tried to post on Hacker News, I think I got six upvotes and zero comments, no one was caring about it. I decided to go to a Discord channel for, so I watch this guy, which is Low-Level Learning. I decided to go to his channel because in my head, he's an influential person, right? He knows people, so he will raise this, right? And when I posted saying, "Guys, there is something really bad going on. I need influence to talk to someone inside Microsoft or npm." And next thing I noticed, I was banned from the Discord channel. Like someone kicked me out. It's so frustrating because now I was trying to do a good thing, and now I was kicked out of a channel. Do you see how frustrating that is? And then in an act of despair, I was like, "Okay, what's the next thing I can do?" I went to the OpenJS Foundation Slack channel, and that's when things started to gain traction because I was like, "Where do I post what I found?" I went to the security channel, I posted the exact same thing that I posted on the Low-Level Learning Discord, and there was a guy, his name is Wes, really important, and he said to me, "Hey, maybe I can help you." And then I started dumping all the information I have. I sent all the screenshots of the code I had. I sent the links for the repositories with the secrets, the migration repositories, the link of the packages. And he was really important because not only he listened, he also contacted, he posted on BlueSky because he's an influential guy, so people listen to him. So it started to gain traction on this BlueSky, and then he also reached out to this security company called Socket. When the Socket company came into play, they discovered, I guess it was 40 other packages.
Mackenzie Jackson: I can't imagine how frustrating this must have been to not only have people ignore you, but also to be actively banned from communities that you participate in. Luckily, we have people like Wes Todd who did listen, who did take this seriously, and was able to investigate and then move it forward. What happened then was a great coming together of the community. Finally, Wes informed Socket, which is a company specializing in detecting malware. They found an additional 40 packages that had been compromised. Later on, Charlie Eriksen would increase this to 187 packages that he actually found, including 20 that belong to the security company CrowdStrike. So, I brought Charlie on to the show to explain what exactly this malware did. So Charlie, what did the malware do?
Charlie Eriksen: Yeah, so this malware, it did a lot of things, right? So this is basically a continuation of the NX compromise story, right? With Singularity from was it end of August, right? So it will, it's changed a little bit. It doesn't use local LLM clients anymore to try to find secrets. Now it will try to use TruffleHog, which is obviously a legitimate tool. Nothing nefarious there. It will try to scan a local machine. It will grab your environment variables. And it will publish it as a repository called Shai-Hulud. It will also try to find any repositories that any GitHub token you have access to can actually go and turn public if it's private, which we saw last time happen as well, but I think that was a manual process, right? That kind of happened as a latent effect, at least initially. It will also try to find any AWS, Google Cloud keys that you have and try to iterate any secrets stored in those environments if it can access them. It will also if it has access to a GitHub token and it is able to create a branch and upload a GitHub action, which will leak secrets again in a Shai-Hulud branch. There's a lot of modules, right? You can actually tell once you take the Webpacked stuff and try to unpack a little bit, right? They have like npm module, GCP module, actual classes that do things, and they're just calling them kind of in order. Quite neat.
Mackenzie Jackson: Charlie, how did we know how this started? Do we have any idea who patient zero is? This was self-propagating, but it had to start somewhere. So, do we know the first instances of when this worm appeared?
Charlie Eriksen: Right. So we thought this iron-XT-authentication whatever it was called, right, was patient zero. And yeah, it looks like it was because it also had a mistake. And what's interesting is all the first packages we see because of how they do the compression of the archive before loading and uploading to npm, you see the username of the user that ran the t command, and it's Ki like Kali Linux used by a lot of security professionals.
Mackenzie Jackson: Now, ironically, you've done some further analysis on this malware, and you've actually discovered that there were quite a few bugs that the attackers actually made. It's quite interesting because this was obviously a very sophisticated attack, yet some pretty simple errors were made. Can you explain some of the issues that you found within their malware?
Charlie Eriksen: So, the first mistake they made was that in the actual code, they set post install with an uppercase I in install, which will not work. So they fixed that in the next version. And then they started pushing it out to a few more packages. They already had done a bunch of packages, but they were, yeah, didn't work. In version two, they had clearly tried to push to the ngx like bootstrap packages, not realizing it was a mono repo package where you have a lot of subpackages within it and there's no script tag. So they tried to deploy it, and it did nothing. So in version two, they also checked whether or not there even is a script tag before they try to infect the package. And then in the third version, in the first version to second version, there was also some changes to how TruffleHog ran. They reduced the total max runtime and stuff like that. Just a lot of little things.
Mackenzie Jackson: This malware was self-propagating, which means that it stole credentials to be able to infect more machines automatically. It was going along quite nicely. Luckily, the community did manage to stop it down, but not until multiple repositories were created that contained secrets, not until multiple private repositories were turned public. So I wanted to understand the impact of this. What is the potential? What could potentially come next? So to do that, I wanted to bring onto the show Gaetan Ferry, who is a researcher at GitGuardian. GitGuardian is a company that specializes in detecting secrets, and as part of that, they actually maintain a complete copy of everything that's happened in public spaces in GitHub. That means that if something was deleted, it still exists on GitHub's service, which gives them unique insight that only potentially GitHub may have themselves. So I brought on Gaetan to give us a bit of a rundown into the postmortem of this and the potential impacts. The other part of this attack which I found really interesting was that not only was it creating these public repositories and dumping secrets into them, it was also turning previously private repositories public. So I wanted to discuss this with you. How many of these previously private repositories were flipped public in this attack? And then I'm going to ask a follow-up question of why this is concerning. But let's start. How many did you find in this case?
Gaetan Ferry: Until now, we have found 850 repositories, more or less, the last one having been pushed public yesterday. So on September 16, at 5:00 PM, something like this. So that's quite a big number of repositories, and by the nature of the attack, it's a worm-like attack, so it can somehow restart all alone at any point in time. So we'll probably see more repositories leaked in the few days or weeks, even months.
Mackenzie Jackson: And with these repositories being turned public, why is this a risk? Is this just a risk from proprietary code being leaked? Is there a risk of business logic being exposed? What is the actual risk for businesses of having a private repository flipped public without them being aware of it, without them knowing or planning for it?
Gaetan Ferry: There are multiple risks. Of course, there's this intellectual property risk that you just mentioned. Seeing your code exposed can expose your business or whatever software intellectual property you have in the repositories. So that's one point. Another point linked to leaking source code is that once the source code is public and most importantly known to a threat actor in this case, this code can also be used to hunt for software vulnerabilities that could then be used in other attacks. So it's somehow fueling the threat actor activity. Those are two aspects of leaking source codes, and another problem with leaking private repositories is that in a lot of cases, when you leak private repositories, you leak a lot of secrets because that's a pattern we observe on a regular basis here at GitGuardian. Private repositories contain far more secrets than public repositories because simply people feel safe in their private repositories. There's this wrong feeling that whatever is private is safe, and so people tend to hardcode secrets in private repositories more than what they could do in public repositories. And so when those repositories are turned public, then all the secrets that are contained in those repositories become, yeah, basically leaked, which increases again the magnitude of the attack. One other thing that I really want to touch on here is that this attack seems to bring together ideas and concepts from multiple different attacks. So we're very confident that this is the same attack as from the NX breach that created the singularity attack, very similar, creating public repositories, etc. But there was also another attack that GitGuardian actually found, discovered, and reported upon. It's one that you coined Ghost Action, where there was a malicious GitHub action that was stealing credentials. It feels like this is almost a combination of NX and Ghost Action together. Do you think that this could be the same attackers? Do you see the same kind of concepts between the two, and maybe give a brief explanation into Ghost Action for those that haven't heard of that before?
Gaetan Ferry: Yep. So Ghost Action was an attack that happened two weeks ago or something like this that used the same kind of malicious GitHub Action workflow attack payload to exfiltrate secrets from the CI/CD. From that perspective, it's actually very similar to what we see in the Shai-Hulud campaign. It's pretty much exactly the same payload, just slightly more efficient in the later campaign. So they actually are very similar in such a way that we could imagine that Ghost Action was just like a prelude or testing campaign before Shai-Hulud. I really think there are somehow two options here. Either we are seeing the same group of attackers just reusing techniques and making their own tools and processes evolve to make them more and more efficient by, for example, adding the worm-like payload in the Shai-Hulud campaign, or we are seeing the whole threat landscape just learning from each other and making the whole threat community more and more efficient and reusing techniques from previous campaigns.
Mackenzie Jackson: Well, Gaetan, thank you so much for joining me. Thanks for sharing your insights and expertise.
Gaetan Ferry: Thanks a lot. We'll continue doing our best to monitor this and try to alert and respond to these campaigns.
Mackenzie Jackson: Now, in situations like this, it can be difficult. We all want someone to blame, but the attackers in this case are completely nameless, but there is someone that we can actually put the entirety of the blame on. His name is Ryan Russell. He is a security engineer at VCISO. Why can we blame Ryan Russell? Well, Ryan shared with me a blog that he wrote about the singularity breach. In that blog, Ryan concludes, and I will quote, "You couldn't have done something cool like backdooring all the GitHub repos you compromised. Make a proper worm. Trusting trust is right there." So, I don't know if the attackers read Ryan's blog or not, but I'm putting all of the blame on him for giving them the idea of creating a worm. So if you want someone to blame for all of the time you spent on this, blame Ryan Russell. Now, obviously, I'm joking. Ryan is not to blame for this at all. I just thought it was very funny that he did accurately predict in his blog what was actually going to come next. So, props to you, Ryan. And I hope you don't mind me taking a little bit of fun out of you. And that segment gave me a good segue to talk about the sponsor of the show, Aikido Security. Aikido Security is your complete code security platform. Aikido brings together multiple different tools like static code analysis, dependency scanning, but also it can check things like your API endpoints and your cloud infrastructure for vulnerabilities. But Aikido have just launched a very cool open-source tool called SafeChain. SafeChain wraps around package managers like npm and blocks installations if the package contains malware inside it. This is especially important with all of the attacks going on. You never know if a package has been compromised or not. But with Aikido SafeChain, you do have added protection. You can try Aikido for free today at Aikido. I had the opportunity to sit down with a security leader this week in Martin Knobloch. Now, Martin is a real legend when it comes to open-source security. He has been contributing, volunteering, and being part of the OWASP Foundation for many, many years. And Martin is someone that I really enjoy listening to because he has opinions and he's not afraid to tell them. So I wanted to talk to Martin about shift left. And what it actually means in development process and how we can improve on it and where it potentially fails. Martin, thanks for joining us and welcome to the show. We appreciate you coming here today.
Martin Knobloch: Thank you for having me. Good to see you.
Mackenzie Jackson: So, I wanted to have this segment because I always like to have people onto the show that have opinions, and you're a man of opinions and also some knowledge to back them up too. But I wanted to talk about a trend that really came very prominent about five, six years ago called Shift Left, and this is something that you've spoken out about both for and against. But I thought maybe we could start off by discussing what does it mean when we're talking about Shift Left in security? What are people actually referring to when they say that?
Martin Knobloch: So, normally it's when you look in this typical software development pipeline, how it works, like in the beginning you have these use cases and then you get to the requirements phase, then you design phase, and I mean software design, not the script design and the test cases. So, this from left to right from the idea to whatever you release a software artifact. Security always came at the end. So on the, when you look at it, it came also on the right in the end, you have the functional testing. "Oh yeah, we need the security testing." Shift Left means like have earlier address to security where I see that it kind of changed to become more security tools put on the developer. That's why part of my friends all refer to it as "Left Shift," because it was more like offloading the things that security didn't want to take care of, like, "All the developer do is just they have to address this," and that's what I said that's the biggest failures. It's just more tools, and that's the things I don't want to do. I have no idea about it. So do this please. That's I think the pitfall of shifting left in the wrong way. Yeah.
Mackenzie Jackson: Where does Shift Left really kind of fail?
Martin Knobloch: I think the failure comes from two things mainly. One is our trust and belief the tools will fix stuff. So, more tools, more insights, more vulnerability dashboards gives us more sight on what is wrong. And then we give developers, "Oh, this is all you have to fix." So, make the work, the life of developers more complicated just by saying, "Oh, this is all wrong." And the other side is by having them then with no training, expectations, and in their concept of software development, then most security people don't have been a software developer, they only come, "Oh, everything is wrong, and you're so bad. And by the way, this is the list you have to fix." This is not how it works. And I think when we look, we want to have developers, we call developers, and we call them builders come from this industry idea. And I just thought about this with my team about software assurance is not new or quality assurance is not new. And I come from industry, in the industry, the customer expects some level of quality, right?
Mackenzie Jackson: I get entirely what you're saying, and I definitely agree with you in that there is definitely this distinction of quality. Does Shift Left help at all in trying to improve that quality or trying to do this idea of making security onto the developers? I can understand how someone's logic would be, "Yes, but this is going to help us improve quality and give developers more tools and more understanding." So is there a scenario where Shift Left actually does do that and it works in that regard?
Martin Knobloch: Yeah, I have thought about it with my company and I said, "What is different?" So when I put it above somebody, then it becomes a burden, but I also make them responsible because we want to have mature developers, experienced developers. But when you look at developers, they always been threatened being too expensive and being near source and outsource, and by the way, you have to do quality and you have to be faster, cheaper and more complex. There are trainings where it doesn't help to do everything at once, and then you come from outside expertise and say, "And by the way, you do all wrong, and this is how you do it right." So I think the best thing is to have people do a better job if first one to be appreciated, right, understand the problem and help them be appreciated. The second one is you want to have quality, then you need experts and give them the ability, right? It's not just in the end when I see so many times in everywhere I come, you build, you have all the requirements, in the end there comes a pentest, and never heard anything about security requirements. So when you give somebody a problem, I give them more than a context, you have to understand where they are in the whole pipeline in the scenario, not only this small thing they develop to understand the risk. When you look at people in a production line, for example, I was in BMW motorcycles, and what they did is they had the people sit on all part of the development line. I said, "Why is this?" It's not just that they can, when somebody falls out, and they can replace the person. No, understanding what you're doing, what is the impact of another one, right? So by giving people more insight and more responsibilities and abilities, then they make a better job, right? Make them proud and not just being punished when, "Oh, you do it wrong, and it's too cheap, and it's too slow and too expensive."
Mackenzie Jackson: Yeah, that's a really great analogy, and I love that to think about it is that when people, because I think there is a disconnect between teams, especially in older companies or larger enterprises, where teams are so siloed that security just becomes this department that's kind of harassing devs, and devs is this department that's just making mistakes all the time for security. And you don't understand how the impact relates to the two. I think that's really, really interesting. Let's talk about the security teams for the moment now, is that we talked a little bit about Shift Left being this concept of just shoving what they want to do onto the developers. So I guess what is it in the security's wheelhouse? What should they really be focusing on in order to empower the developers, let them control what they can control, but not to shove the jobs that they don't want to do onto the developers? What is it that security really needs to take ownership of and be doing in this kind of new pipeline?
Martin Knobloch: There are several things that I really frustrate. One is that when you're a pentester, you get paid because you find something. So, you need a report and you have to find issues. So, you get paid, more issues is better, right? That's one thing. No, you should be there to help. And when I was a security consultant, I went there and I said, "Oh, you see this cross their arms, lean back. Oh, you do security." I said, "No, but I can be the crowbar, enable you to get what you already requested." But now somebody external comes, security person comes, and I can help you to get the time and the money, the budget to fix those things you know that were not right, right? You are helping them to be more quality aware, to help them to fix those stuff they never had the time for. I don't care if a team has security issues because there always will be the false positive finding whatever, but I want them the issues to go down. So I want not on the absolute numbers, but on the working on trends. I think that will be much smarter to see that they're improving and get time to improve.
Mackenzie Jackson: I think we've had this shift in security tooling where, I don't know this for sure, but I get the feeling that it used to be security tools would justify their price by the amount of stuff that they found. It was kind of like what you're saying about a pentester, like you find more stuff, the better. But we kind of quickly realized that actually most of that stuff isn't relevant. And just because you have more like this, that we kind of are now entering this new era where tools are kind of much more focusing on finding less things, but more relevant things. There was something in some presentations that you did, and I'm paraphrasing you now, but it's just kind of like a general theme what you said is more like humans will find flaws and tools will find bugs or vulnerabilities or something like that. I wonder could you elaborate more on what is the difference between or what are the different things that people find between you have these security tools that are finding these issues, these vulnerabilities, but then you have people that are also finding vulnerabilities, and they're often quite different.
Martin Knobloch: And the tools are really good in finding cross-site scripting and SQL injection, but the model stage, so the outside of context thing when you need human brains, when you need context of the application where data comes in in this information from a different process, that is what I want to find with my hacker. So I really don't want to have security professionals to find cross-site scripting SQL injection because they're the things that we can prevent easily just using the right tools and we can detect easy by writing tools, right? So you want a pentester not to spend time on verifying is cross-site scripting an issue in an application when data comes in, it's manipulated and then used and comes in a different context. That's something a tool cannot find because they have the limited scope, and that is something that I want to have the security professionals look.
Mackenzie Jackson: That makes total sense, and I completely agree with it, and I think that this is kind of where people misunderstand the value of tools and pentests, and they kind of almost think of them as like one or the other in some regards, like, "Why doesn't my pentester find this SQL vulnerability? Why doesn't my pentester find this dependency that has a critical vulnerability in it?" It's like, "Well, your pentester should be trying to find business logic flaws." There is something that you've mentioned kind of in the past that I want to touch on because it's very topical at the moment, is last week we had the largest supply chain attack ever on npm, which turned out to not actually affect that much because we were quite fortunate there. But the supply chain security, particularly when it comes to open-source supply chain, is a complicated topic, and forever, I think there's been this kind of recommendation of patch regularly and patch often, which of course you should do. But then there's this kind of trap of thinking, "Well, if I want to patch regularly, maybe I should just always pull in the latest version." How do you kind of educate people between those two things of why pulling latest may not be so secure and why you still need to patch regularly and staying back there because the two are in direct conflict with each other and often have kind of like conflicting arguments.
Martin Knobloch: It's even on basic software development, right? I have seen these companies, they didn't upgrade because, actually, maybe a story. I was in the bank, and they upgraded back then to the Oracle, I think it was 8 or 10, I don't know, it's a long time ago. I said, "Why would you do it?" I like, "Oh yeah, but it's finished." It's like, "No, it's out of support. You cannot get any patch anymore." And they had the idea it was out of support, means that the product is finished. It's secure now. First to understand why they not would do upgrading to not supported version anymore. Then understanding that when you not upgrade that means the next major upgrade will take you much more time and much more to break. If you have to refresh your code, maintain your code, it must be kept sharp and clean. People say, "Yeah, but it's not security." No, it's good for craftsmanship, right, to have your code clean and well-maintained code base.
Mackenzie Jackson: I guess this kind of encompasses security in general is these, like you just have all of these different balancing acts between empowering developers, not overloading them, giving them the right tools, not relying too much on the tools. Also, you know, like there's so many things that you have moving in security all at the same time. But when you get that balance right, you know, I think you really feel it.
Martin Knobloch: I think in the base, what I learned, it's not about tools. It's not about the checklist and guidelines. It's about the people.
Mackenzie Jackson: I'm going to wrap this up. I could talk for hours, but I'd be remiss if I had a podcast in 2025 and we didn't talk about AI at least once. So, we have to do it, otherwise, you know, the algorithms won't promote us. But what do you think has changed in all of this AI development of the future in terms of like the security vulnerabilities and flaws that we're seeing? Is AI just kind of perpetuating the vulnerabilities that we had, and we're staying much the same? Is it making everything better? Is it making everything worse? Is it changing it? What are you seeing with the development of kind of these AI-assisted coders? And I feel like there was resistance at the start, but I feel like at least 90% of developers are using some form of AI to assist them at the moment.
Martin Knobloch: I think that's the thing is some form of how to use it, right? But I always wonder about this. When we look in sci-fi, when I look at robotics, we always try to mimic or duplicate humans. It's all the good or bad, right? When I see a robot in the movies, still his head is shot and the robot is dead. Like this makes no sense. Why is this a robot? Why does his head is his brain? Why would not protect it more in a more vital thing? So we take something with humans and we think, "Oh, humans is the most perfect creation." So therefore, everything must make humans with all the mistakes it has. And the same is with AI, right? It's based on all the context. AI is almost unlimited knowledge, like Marvin, like we have all the resources, but then you make the same mistakes because it's based on the mistakes of the humans. So when you use AI as a contribution to be more efficient and more context is much better, you don't just say, "AI, build this application." Now, you use it to help you to better quality applications that makes much more sense, I guess.
Mackenzie Jackson: Well, Martin, on that, on that words of wisdom, we have to wrap up today, but I really want to thank you for coming on and talking to us and sharing your knowledge for us. If people want to follow you, you are quite prolific in the community and especially in OWASP communities. What's the best way for people to kind of follow you and find out about any talks or other podcasts that you might be appearing on?
Martin Knobloch: I would say just Google me or yeah on LinkedIn, of course.
Mackenzie Jackson: I'll add some links down the bottom. But Martin, thanks so much for coming. Really appreciate it, and hope to have you back on the show again.
Martin Knobloch: Thank you for having me.
Mackenzie Jackson: And that's all we had for you this week. I hope you enjoyed this episode. Remember, a new episode of The Secure Disclosure comes out every single Thursday. So make sure you subscribe to the channel wherever you're watching or listening to this. Please give us a thumbs up or a five-star review. It really helps us continue this. We're trying our best to make this content as engaging and informative as possible.
