The Surge in Supply Chain Attacks

Software supply chain attacks have escalated dramatically, turning open-source packages, CI/CD pipelines, and developer environments into lucrative targets for threat actors. This increase is driven by a confluence of factors, including the rise of AI and the 'citizen developer' phenomenon, as noted by Ahmed Nassri, CTO at Socket. These advancements empower threat actors while also expanding the pool of less security-aware developers.

John Amaral, CSTO at Aikido Security, highlighted the high leverage these attacks offer:

"If you can go upstream and compromise a single maintainer repo, then you get the lever arm of all those automatic updates pulling down things."

This allows for widespread compromise from a single point of entry.

Jenn Gile, Co-founder of OpenSource Malware, attributed a significant portion of the current malware surge to nation-state actors, particularly North Korea.

"We have seen in our research that the vast majority of malware is coming out of North Korea,"

she stated, explaining their shift from counterfeit currency to cyberattacks as a low-risk, high-reward funding mechanism for their programs.

CI/CD Pipelines: A Critical Attack Vector

CI/CD pipelines, especially GitHub Actions, have become a prime target due to their highly privileged environment and frequent execution of untrusted code. Ashish Kurmi, Co-founder and CTO of Step Security, explained,

"CI/CD is a highly privileged environment. It has privileged secrets, elevated secrets, and it's running a lot of untrusted code. So that creates a high-risk environment."

The widespread adoption of GitHub Actions in open-source projects makes it an attractive target. Many developers, however, lack a deep understanding of how these systems work, leading to misconfigurations.

Paul McCarty, Co-founder of OpenSource Malware, added,

"Most of the people that use GitHub Actions don't really understand how it works."

This knowledge gap, combined with the prioritization of developer velocity over stringent security checks, creates significant vulnerabilities. Boaz Barzel, Field CTO at Ox Security, advocated for treating CI/CD systems as production environments to enforce greater security discipline.

The Developer Velocity vs. Security Dilemma

A contentious point among the panel was the industry's emphasis on developer velocity. Paul McCarty offered a "super spicy" take:

"I think the single biggest problem that we have is this idea that we constantly underscore the fact that developers need velocity at all costs. That is wrong."

He argued that while velocity is important, it must be balanced with checks and balances. John Amaral concurred, adding,

"The secure way needs to be the easy way, right? If you can get there, great."

Actionable Advice for Developers

Given the evolving threat landscape, developers must take proactive steps to secure their environments:

  • Be Aware You Are a Target: Paul McCarty emphasized, "I would hope that developers realize that they're being... they're a target right now, too." Developer machines and credentials are prime targets for sophisticated attackers.
  • Understand Your Tools: Ahmed Nassri advised organizations to "invest in, uh, training their, uh, employees and people in our category and get more familiar with the risks and the threats." Developers should deeply understand how package managers and CI systems function.
  • Enhance Visibility and Practice Security Hygiene: John Amaral urged developers to be "more proactive at knowing what software they're using, like, from all the different ways and, and locking things and pinning things." Ashish Kurmi added, "have better visibility into the software that you're pulling in, but also, you know, have better visibility into the dev tools and, you know, uh... other platforms that you use." This includes being vigilant about IDE extensions and other commonly used developer tools.
Read full transcript

Mackenzie Jackson: Hi everyone, and welcome to this very special episode of The Secure Disclosure podcast. This is the most logistically challenging thing I've ever done in my life. I'm so thrilled I managed to fit you all in here. This came about because we all work in similar spaces. Occasionally we're friendly, occasionally we're not, but we're all trying to solve similar problems. So I wanted to put the people that are doing really great work, really great research in the same room and discuss how can we actually solve some of the problems that we have. I'm Mackenzie, I'm the Field CTO of Aikido, if you don't know that already, and I'm going to pass it on to quickly do some introductions.

Jenn Gile: Yeah, Jenn Gile, co-founder of opensourcemalware.com.

Ahmad Nassri: Ahmad Nassri. I'm the CTO at Socket and former CTO of npm.

Paul McCarty: Paul McCarty, also co-founder of OpenSource Malware.

John Amaral: John Amaral, CSTO of Aikido and formerly founder of Root.io, which was recently acquired by Aikido.

Boaz Barzel: My name is Boaz Barzel. I'm the Field CTO at OX Security.

Ashish Kurmi: Great to meet everyone. My name is Ashish Kurmi, and I'm a co-founder and CTO of Step Security.

Mackenzie Jackson: I want to start off, open the room as to why have we seen such a gigantic increase in supply chain attacks in the last couple of years? And I know that everyone's probably going to have opinions on this, but what has kind of been the catalyst in here? I know Socket's been in this space for a long time, so maybe we'll start here. Did we see a massive increase, or I think we all can say that, but what do you think that catalyst has been?

Ahmad Nassri: Well, I mean, it's hard to pinpoint a singular catalyst, but I think the confluence of this AI development that's happening and the citizen developer that we're seeing now is encouraging more of the threat actors to take advantage of the moment. And also the threat actors themselves are leveraging the same tools, using the AI and using these things to discover mechanisms and ways to do things that they weren't able to do before. But also, I want to also pay attention to the registries themselves that they're not doing enough.

Mackenzie Jackson: Which we're going to come back to, because it's good for you.

Ahmad Nassri: Right. So that's the thing where you know, we have to have some empathy, but also hold some businesses accountable where it makes sense because they've also been caught under the same workload and impact of this growth. So it's not easy to say, "Well, it's the registry's fault," but it's also not easy to say they can do something about it because they're also under the same workload and the same challenges. And I know a lot of them are trying, and also a lot of them are not backed by multi-billion dollar corporations, so they can't necessarily put in the resources into it.

Mackenzie Jackson: Paul, I see you kind of nodding.

Paul McCarty: Yeah, I mean, listen, I agree. I think a big part of the rise in software supply chain attacks has been just the bad guys will find the path of least resistance, right? That's really what it comes down to. It's that simple. Most of the attacks that we see are interpreted JavaScript or Python, relatively easy. The advent of AI makes it even easier to write that kind of stuff. But I want to go back to something Ahmad talked about, which is that PyPi is a registry, not-for-profit. npm is owned by Microsoft, right? Billions and billions of dollars. So I want to be careful that we don't conflate the two of them, right? And I think that PyPi has done a lot of things better than npm has, frankly.

John Amaral: I'd like to add that from the attacker perspective, this is a high-leverage kind of thing, right? If you can go upstream and compromise a single maintainer repo, then you get the lever arm of all those automatic updates pulling down things. And subsequently sort of the width of this thing, like an angle, small angle at the beginning, wide aperture after miles downstream, they're able to get a lot of compromises to happen in a very short time with extremely high width. So this is a really lucrative attack, if you think about it.

Jenn Gile: Yeah, I mean, I would add that we're experiencing a bit of a flywheel. So we're almost exactly a year since high-profile account takeovers really started becoming something that people noticed, paid attention to, right? I can't remember which two it was in July, but then it escalated to Chalk and Debug. We had the Singularity attack. I can name them all. And so the flywheel that you have is the more that the public, or in this case, our industry pays attention to these attacks, perhaps the people in this room talking about these attacks, publicizing them on our blogs, the higher profile they get, the more threat actors are like, "Ooh, interesting. This is a new place for me to lay my malware." As we know, TeamPCP didn't used to play in this space. We saw them get into it early in 2026. And so I think, in some ways, it's always been here, right? We've seen malware in open source ecosystems for years. It tended to be more in the typosquats and the dependency confusion. And if I rewind a couple years ago, I used to work at Andor Labs, we couldn't get anybody to turn on the malware scanning. It was there, it was part of the product. It wasn't an upsell, and nobody would turn it on because they didn't understand the necessity or the value. And now two years later, we're in a totally different market where people are starting to understand the challenge. And I think a lot of that comes from the threat actor behavior as well as the security vendor behavior.

Ahmad Nassri: I think you touched on something there that's very actually important, which is historically it's been a lot of the typosquat, the dependency confusion. And I think that pattern has mostly been associated, at least in the minds of people, is that an attacker is going to target a company and therefore their production environments or their system. There's like a specific target in their mind that they're trying to get to, in most cases, or at least that's how people thought. But then once that floodgate opened, as you said, with the account takeover of popular packages and maintainers, all of a sudden it's like, "Oh, wait a second, I have a much bigger blast radius that might yield bigger results or bigger value." And now everybody's cascading on that.

Ashish Kurmi: Just to add to what you said, this broader trend that we are seeing in the industry is that attackers are also shifting left. So they realize it's a lot easier

John Amaral: Yeah.

Ashish Kurmi: to compromise open source packages and then use that to compromise secrets from developer machines and CI/CD. And once you do that, you know, you can attack a large number of open source projects and enterprises as opposed to targeting one particular company.

John Amaral: A single maintainer, these folks are, you know, they're working nights and weekends to make software. They're not necessarily security experts, perhaps.

Ashish Kurmi: Yeah.

John Amaral: These long-lived tokens and all the things that happen that are kind of easy to transpire.

Ashish Kurmi: Yeah.

John Amaral: These kind of bad habits. And you just have to be right once for one maintainer that has kind of high distribution, and you've got a really effective attack.

Ashish Kurmi: Yeah.

Paul McCarty: I think what happened to Jason at Axios, that is just crazy. Like he was w-

John Amaral: To Jason at Axios.

Paul McCarty: Yeah, and you guys had a great interview with him. I was really impressed when you guys got him to do that interview. So basically, he was wined and dined by North Korea for, what, nine months? They met him physically multiple times. They put a million dollars in an account, right? This was not a short affair. This was a big contraption with lots of moving pieces over many months to get him to trust them so they could then, you know, go and compromise Axios.

Mackenzie Jackson: I want to push back on just an overall theme a little bit and ask this question, is we've come up with a whole lot of reasons why basically supply chain attacks are a great idea for attackers, right? But all of that was true to beyond two years ago. Like, what was the catalyst now that they all figured it out? Because we talked about for the longest time Event Stream or UA Parser or something like that, and on reflection, they're tiny compared to the, at least the blast radius that we're getting now.

Jenn Gile: Well, I will share a hypothesis, and I want to be clear,

Mackenzie Jackson: Okay.

Jenn Gile: it's a hypothesis. I'm curious what the group thinks about it. Paul mentioned North Korea. We have seen in our research that the vast majority of malware is coming out of North Korea. And this is a little, I won't say new, but it's a little newer, as they've shifted their criminal enterprises. You know, they're under sanctions. They can't go forth and have legitimate exports. And so they have found, they actually started... There's a great podcast, To Catch a Thief, that is... It's so good. If you haven't caught it yet, you have to listen to it. But they actually started with counterfeit currency, and they were really good at it. That's the reason, fun fact, that we have shiny, colorful one hundred dollar bills in the US is because of North Korean counterfeits. And so they were really successful, and as security people do, they close the gap. The threat actor goes, "Okay, what else can I do?" And they found that targeting tech companies and specifically developer organizations was both highly lucrative as well as low risk, because you don't physically have to send your people into a dangerous place. You get burned. Okay, fine, you just get a new identity. And so North Korea has shifted over the last couple of years, three years or so. We see this with Contagious Interview, with other attack vectors where they're doing the IT worker scams, and then they're just putting a tremendous amount of malware out there with initially the plan was to steal cryptocurrency. And they've stolen billions successfully of cryptocurrency.

Mackenzie Jackson: Yeah.

Jenn Gile: And, you know, that's, you know, they-

Mackenzie Jackson: And they stole seven hundred dollars from. Let's not forget. Let's not forget.

Jenn Gile: Yeah, yeah.

Paul McCarty: Well, by some accounts, half of their GDP in the last two years, half-

Boaz Barzel: Is stolen cryptocurrency.

Paul McCarty: has been from crypto, 2.2 billion dollars last year alone.

Jenn Gile: Yeah, so if you think about the economic drivers here, you know, this is a state actor that needs to fund their programs, and they found a lucrative, low-risk way to do it. Why would they stop?

Mackenzie Jackson: Yeah, I actually haven't-

Jenn Gile: And so we've seen them escalate. Anyway.

Boaz Barzel: Yeah, I want to touch a few points. So first of all, I think that what you said is, why haven't they done it sooner? I think that I like to compare people to water. Water takes the least resistance path, as you said, but we also had blockers. And I think that the last blocker was the ability to use AI into doing something that you're not used to doing. So the expertise of building something... For example, I built an agentic pen tester within NCI. It usually would take months to do it. It took me five days, not because of, you know, I'm using it as a product, just because it's a hobby of mine to build things.

Mackenzie Jackson: Yeah.

Boaz Barzel: So the last blocker, I think, from either state actors or any individuals to actually go and start creating malware that spreads like a worm is just what we're seeing as an amplification of everything that was, you know, being done. And because now, as we're told, everybody's a developer, the agent makes the decision. The agent really doesn't understand, doesn't know, which gives us that targeted attacks where-

John Amaral: There's also a proliferation of, say, fake websites, fake corporate websites. A lot of fakes, AI is powering the attacker's ability to be more convincing.

Mackenzie Jackson: Yeah, look very legitimate. Yeah.

John Amaral: Spear phishing attacks and, you know, and you can go very wide. So you could target a thousand important developers or one hundred thousand important developers, and you can send agents off to do a whole bunch of work for you that makes you look real.

Mackenzie Jackson: I have a funny, I have a funny story about this. I got an email from, I actually sent it to you guys, but then I deleted it once I found out it was wrong. But I got sent an email from Alibaba Cloud, but it was like a really weird .lad, like it looked super phishing, and it was like a weird email. And then I was like, "Oh, I'm finally getting targeted by Contagious Interview." Turns out it was legitimate. I was so excited. I was so-

Jenn Gile: You know you've made it.

Mackenzie Jackson: Yeah. And I sent it to you, and then someone from work was like, "No, that's, that's actually..." Like, they were looking into it, and then I was like, "I'm going to delete that." I want to, I want to kind of focus this, because I know we can talk about this, but I want to talk a little bit, now that we're talking about phishing, about also entry points. One of the entry points, and a very big entry point, where I'm looking at you because this is a lot of what you have been working on-

Ashish Kurmi: Mm-hmm.

Mackenzie Jackson: is through GitHub Actions and CI/CD pipelines. And it's kind of crazy when these complex, but inherent vulnerabilities in the system.

Ashish Kurmi: Yeah.

Mackenzie Jackson: So, I guess, what's your take, and then we'll take a round about that kind of CI/CD pipelines as an attack vector. Are there kind of fundamental flaws in here? Are we just bad at kind of writing pipelines? What's your opinion?

Ashish Kurmi: Yeah, so I feel, you know, as you all know, CI/CD is a highly privileged environment, right? It has privileged secrets, elevated secrets, and it's running a lot of untrusted code. So that creates a high-risk environment because, you know, now if you have untrusted code, bad code running in a CI environment, they get access to your production environment, right? And the reason we see GitHub Actions in particular being targeted is, in my opinion, is because of simple unit economics, as we all are alluding to, right? So GitHub Actions, if you think about, you know, what was the CI situation before GitHub Actions, either you needed to self-host it, or if you could use a hosted solution, it required complex configuration. But with GitHub Actions, it's so simple to build your CI pipeline, and that is why we see a huge adoption by the open source community. And because this one was heavily adopted by the open source community, it becomes an easy target for these attackers to compromise these open source projects and then start a, basically, a supply chain attack. And then, obviously, GitHub Actions has some GitHub Action-specific security issues because of the way it's implemented, such as the use of mutable tags, the use of third-party actions. But I don't think it's specific to GitHub Action. The reason we are seeing GitHub Actions being targeted, like I said, is because it's heavily used. If tomorrow open source community moves to another CI provider, I'm sure the attackers will target that CI provider.

Mackenzie Jackson: Yeah.

Paul McCarty: Everything he said is absolutely true. At the same time, most of the people that use GitHub Actions don't really understand how it works. And this is why we're still seeing pull requests, still to this day, one, because GitHub hasn't disabled being able to run in the context of the original repository. And so, and people don't understand that. So we're still seeing pull requests, right? And that's because it's complex, right? It's easy to set them up, but understanding what it's doing behind the scenes?

Ashish Kurmi: Especially for open source repositories, right, because their CI pipelines are also open source. So anyone can exploit this vulnerability. And again, that creates a huge attack surface.

Mackenzie Jackson: Yeah.

Ahmad Nassri: There's also what I call the deep lore of how package managers work that not everybody is fully kind of versed in, like maybe us in the room here would be. Like, I always work with AppSec teams and people who are obviously doing the scanning and running our tools and things. And then they kind of show me their CI/CD pipeline. I'm like, "Oh, I see you're running npm install on that, yet you have a package lock file, but that's completely useless now." Right? And they don't make that mental association. Or running NPX as like a runtime, like CLI tooling, right? There's all these core principles of how to do the things the right way and understand how, not just how the CI works, but also how the tooling that you're using works. And then if you're not deeply embedded and deeply experienced in that category, whether you're an open source developer or like an AppSec team or a DevOps team, you might make that mistake and you might think you're protected because you have lock files, you have cool-down periods and all of that. But then you're running NPX CLI for-

Mackenzie Jackson: And ten thousand citizen-

Jenn Gile: A little exposed. Yeah.

Mackenzie Jackson: And ten thousand citizen developers are cropping up while we sit here-

Ahmad Nassri: Exactly.

Mackenzie Jackson: who know even less.

Ahmad Nassri: Exactly. And their AI, their AI is doing the work.

Mackenzie Jackson: Their AI is doing it, and they have no idea what's going on.

Ahmad Nassri: And what is the AI trained on? All the open source things and all the articles.

Mackenzie Jackson: All the wrong, all the things.

Ahmad Nassri: Correct. Yeah.

Boaz Barzel: I want to add something to your point because it's absolutely correct, is the way that we treat those systems. We should probably start treating those as production systems, and it's not development systems.

Mackenzie Jackson: Right.

Boaz Barzel: And once we start treating those as production systems, people will naturally have to start understanding more, which kind of solves this point. But for what you touched, it's really the ability to understand, okay, this is how is the correct way or the correct action, and even disabling some of the features or getting some of the controls into place will help mitigate it, because I don't think it's possible to solve all the supply chain aspects, but definitely will help to mitigate it, like other techniques that we're implementing.

Paul McCarty: I think CI in particular ages badly because once we get it working, we don't want to touch it, right? We don't want to mess with it, no?

Mackenzie Jackson: God forbid you have to... Like, no one migrates off their CI/CD system, right? This is like a-

Ahmad Nassri: You mean you don't enjoy writing YAML files all day?

Paul McCarty: And to that point, we all see, like, npm 12.0, it's going to fix all these things. The reality is just go and look at GitHub Actions and look how many people are still running npm 8.9.2 in their CI pipelines, right? This is not going to get fixed until-

Mackenzie Jackson: And we've had Salsa, right, around for a long time and a lot of, like, I think really well-intended things to get some real security around this, but no one uses it, I think. You know, like, signing, using signatures and attestations, all the things. I mean, that doesn't solve all the problems we talked about, but this is a big-

Jenn Gile: Well, I did some research earlier this year-

Mackenzie Jackson: Yes.

Jenn Gile: into could you tell how many people had implemented the npm trusted publishing after it came out? And I looked specifically at people who had been compromised before, and it was something like 12%. And so if you think about the body of people who absolutely know the danger, and, you know, many of those are companies, not just individual developers. So if people who have been compromised before are not turning these controls on, then what do we expect? This, this is the world we live in.

Paul McCarty: We kind of are our own-

Mackenzie Jackson: It's the people's fault.

Paul McCarty: We, we honestly are kind of our own worst enemy, right? Like, we kind of, as an industry, we kind of do this to ourselves.

Ahmad Nassri: Well, it kind of goes back to what you were saying earlier, like, you know, water takes the path of least resistance, but so do humans, right? Like, we don't want to do the hard-

Jenn Gile: You have to make the right thing easy.

Ahmad Nassri: Yeah, exactly.

Boaz Barzel: Nobody wants to be the one that broke the CI, you know? That's-

Ashish Kurmi: Typically, I've seen, you know, there is friction between developer productivity and the speed of adoption versus security, and it tears both ways. When you make things really easy for developers, to your point, they don't really understand how to secure it and end up making mistakes. Or when you make it really secure, then it causes adoption friction.

John Amaral: The secure way needs to be the easy way, right? If you can get there.

Paul McCarty: I'm going to say something super spicy, and I am, I'm not scared. Jenn's looking at me like, "What is that?"

Jenn Gile: What is it?

Paul McCarty: I, I, I think the single biggest problem that we have is this idea that we constantly underscore the fact that developers need velocity at all costs. That is wrong, and that is... I'm not saying they shouldn't have velocity. What I'm saying is, there always needs to be checks and balances. There needs to be resistance, pushback on that. And this idea that we should give them anything they need so they can go as fast as possible, that is ultimately what is causing us this problem today.

Ahmad Nassri: I agree with that. I think that's also an opportunity for education and for leveling up. So, like, create the resistance, create the kind of barriers, but couple them with learning and opportunity for improvements, because that's how you win the developer as well.

Paul McCarty: Yes. Thank you.

Boaz Barzel: I don't think that's coming from the developers, by the way. It's coming from management.

Paul McCarty: Oh, I totally agree. They're being incentivized.

Boaz Barzel: The developers themselves, they don't want it.

Paul McCarty: They're being... Yeah, that's the problem. You see all these CEOs get up on stage and say, "Oh, security's really important to us." But they singularly incentivize their developers based on speed and features, nothing else. Well, there we go.

Jenn Gile: But I mean, let's also think about how some of these security features get pushed out. You've, we've all looked at npm version 12. We know very well about the dangers of lifecycle scripts and this concept that, okay, it's going to be off by default for version 12. You need lifecycle scripts to use a lot of packages. And so if your developers are constantly having to request workarounds, at what point do they become blind to the dangers of those workarounds? And so I think, like, we look at these processes that we put in place. The intent is good. Like, we all agree you should be cautious about what kind of controls you turn on. But if you make it something that you have to do every time you download a package, it's not going to be an effective control.

Ahmad Nassri: Yeah.

John Amaral: Yeah. And then, and then of course, the shift left movement happened, right? But it ended up dumping a lot of hard things on developers' desks to do the work, right? So this idea that you can just pile work on their, on their, on their laps and not give them ways to actually automate or remediate or impart the change in a way that's really convenient for them and doesn't cause these side effects like you're describing, I think, I think we've done a disservice to those developers in the way we've presented them with solutions. It's really hard.

Mackenzie Jackson: I want to, I want to kind of make sure that we get to some, some other things too. But one of the things we've kind of mentioned lifecycle scripts and other things that npm is removing, and they, and it kind of goes back. We've been yelling at npm for a while, "Look, remove the long-lived keys." They did it, didn't solve the problem. Do this, move that. What are registries... Like, what, what, what is the position of the registries? What responsibility do they have in solving this? Are they doing enough? Are they not doing enough? You know, it is interesting because a lot of people, and you'll be able to speak to this far better than I, but a lot of people ask me, like, "Why doesn't npm do this?" And I'm like, "Well, npm was created pretty much for the purpose of making it as easy as possible to share, to share packages and all of that." And every friction you put in there goes against it. And I don't think it's isolated that JavaScript ecosystem grew so fast with that. But bringing it back, let's not... I'm not giving them too much of a pass here. Like, where, what, what is the responsibility here? Have they done an okay job or not a good job? And, you know, where we go?

Jenn Gile: Well, I will say we've seen two different responses. So I got to know the head of security for OpenVSX recently, and they have taken a very different approach to what we've seen with npm. Theirs is, and I'm not saying whether or not it's working, but they have... You know, they were first to implement, implement pre-publication scanning. They're doing a lot of things before stuff gets into their ecosystem. Whereas npm just announced, what, last week, the week before, that they were going to do pre-publication scanning, and the jury's out on whether it's effective. I mean, we had a major attack this week-

John Amaral: There's not a lot of studies. Yeah.

Jenn Gile: so I don't know. It was through a post-install script.

Mackenzie Jackson: What, and what-

Jenn Gile: Hypothetically, I would have caught that.

Mackenzie Jackson: What's the problem?

Jenn Gile: I don't know. We were all busy, right? So I don't know. I think, we can debate responsibility, but we're seeing different models in place already. And some of those models, to the earlier point, like maybe we shouldn't conflate a corporate-run registry versus a foundation-run registry. And, you know, they have different priorities, and I don't know about the liability involved in a corporation, you know, taking responsibility. I'm curious what... You know, you've watched it go from foundation to...

Ahmad Nassri: Yeah, I mean, I can't comment on the current state of npm directly, obviously, for obvious reasons. But like, yeah, like to that point, there's obviously different incentives, right? As well as different obligations when it comes to operating our industry. So I know that there's, you know, a lot of effort around, like, the OpenSSF foundation work, all these individual kind of foundations coming together and trying to do investments in the category to serve the community better. But also, like, to the earlier point about things like, for example, npm and, you know, lifecycle scripts, I mean, that's kind of something that npm, you know, created in the category. And now you have the state, to your point as well, where there's some fundamental dependency on that mechanism. So by pulling that back or removing it and saying it's not good anymore, you're going to destroy a large portion of the ecosystem and their, their needs. So you can't just do that. So now you have to come up with alternative mechanisms to deal with it. You have to do, like, you know, pre-published kind of scanning or whatever the other things that those registries can invest in. But I would still say, like, even in the context of whether it's, like, an open source foundation or a big corporation kind of serving these registries. And by the way, npm is not the only one that's backed by a big corporation. I know I'm on the spot for being the ex-npm person there, but, you know, there's more companies out there that also-

Mackenzie Jackson: I did promise it would be a spicy session.

Ahmad Nassri: Yeah.

Boaz Barzel: But we don't, we don't mind. That's fine.

Ahmad Nassri: But, I also got to look at the teams and the members and the people involved, and that doesn't necessarily mean they have the expertise that we have and the things that we've been building and the knowledge that we've created, right? So that's also a responsibility on us to share some of that learning and share that kind of collaboration, because of course they can't solve it alone. And if all these security companies in the space, like, not just the ones in the room, we hire all the security experts and all the threat, threat researcher expert, there's nobody left for, you know, Microsoft to hire and solve the problem internally either.

Paul McCarty: There's lots of people from Microsoft to hire. Come on.

John Amaral: Yeah, yeah. I think they can pretty much hire anybody at probably-

Boaz Barzel: No, but I think... I want to touch something. The... If you remember when cloud started, we talked about shared responsibility.

Ahmad Nassri: Yes.

Boaz Barzel: It's not wrong. I think that on the npm side and the different package managers, it's also to allow themselves to start mitigating or start understanding, okay, something is already known. We're able to do some sort of mitigation within, let's say, the package manager. But then we're also can create some instructions on the best practices and the best way. I don't think that they do a good job in that. They're saying, "Okay, we're just hosting the packages for you, and you can use whatever you want." No, this is the right way or the best way to do it. And they have to start sharing those types of best practices because they probably know better how it works, not just, you know, us in the room. But on the other side, it doesn't remove the responsibility from the customer side or the developer side because eventually we all know, I would say, the right way or the best way as far as we know on how to operate it today. And to your point, only 12% of organizations are actually implemented it. So I think that there's something missing. There's a big unknown that usually happens with new types of attacks that we're seeing until it becomes something that's mainstream, easier to understand, easier to implement. And I think at that point, we're going to start seeing a different shift, shifting from supply chain attacks to maybe upstream even more and trying to say, I don't know, maybe affecting what we're seeing right now, affecting the models themselves that are recommending the package. I, I don't really-

Mackenzie Jackson: Well, let me put this to you, is that npm is putting in a lot of things now, including scanning for malware, which is interesting. So I kind of want to get people's opinion on npm doing that because it's kind of, you know, like... Yeah, here we go. Because, like, you know, I'll be the first to admit that, like, we, we have a product that, you know, that does that too.

Jenn Gile: We rely on them not doing it well, right?

Ahmad Nassri: Yeah.

Jenn Gile: So it's like, let's call it what it is.

Mackenzie Jackson: I mean, no-

Jenn Gile: Yeah.

John Amaral: There are a lot more, there are a lot more ecosystems too. I mean, is there-

Mackenzie Jackson: So two parts to my question. One is, let's... what do we all think about npm doing this? And the other question that I, I want to go is, let's say that npm becomes, you know, the most secured registry. Do the supply chain stop,

Mackenzie Jackson: or do they move to PyPi, you know, or somewhere else? As in, like, as... because going back to water leaks, the path of least resistance. So like-

Jenn Gile: Well, I will say we're already seeing movement toward poisoning agents.

Mackenzie Jackson: Right.

Jenn Gile: You know, we're seeing lots of skills and MCPE servers-

John Amaral: More high leverage there, right?

Jenn Gile: and repositories published in GitHub that have nothing to do with npm necessarily. So the, the ball is already moving.

John Amaral: I want to say that I, I connected the dots on two points. You said earlier no one turned the malware scanning on, right? And, and you said there's lots of untrusted code running through the, through our, through the GitHub Actions, right? I think that most users don't really make this connection that every package decision is implicitly a trust decision. And, and, and I think we've, we've, we've talked to them so much about fix the CVEs, fix the CVEs, which is still important and super important, but I think they've lost the connection with, by the way, all that code I run is actually, right, could be malicious code. And they... I, I was talking about some of the TCP stuff with some folks down in the... at Black Hat, right? And I said, "You know, we had another supply chain attack yesterday." And they said, "Oh, yeah, another zero day."

John Amaral: And I said-

Jenn Gile: Or they'll say something about Mythos. That's the other response. Yeah.

John Amaral: No, I said, "That's not a zero day. It's malware. And it's, and it's in the software that you're using." There was no CVE. And I think that's a huge disconnect, honestly.

Mackenzie Jackson: Totally agree.

John Amaral: It's a huge disconnect.

John Amaral: Right?

John Amaral: Correct.

Jenn Gile: The mouth drops. We were like, "Oh my goodness."

Mackenzie Jackson: Oh, should we stop the podcast?

John Amaral: Yeah.

Mackenzie Jackson: No one emailed me about this.

John Amaral: You're obsolete.

Paul McCarty: That's the first order of business, is we got to help people understand those are two different types of risks, right?

John Amaral: Yeah. And we might be educating the North Koreans, but we haven't done a good enough job at educating the people who actually have the problems, to know what to do yet.

Mackenzie Jackson: All right, let's get back to it. One of the questions that, you know, we've kind of... we didn't answer is, what, what is the opinion of npm doing this? Is this very positive for the ecosystem that we can actually get in this? Is, or is it...

Mackenzie Jackson: are, are we letting npm take on too much responsibility? What do, what do people think about it? I'm going to be very quiet on this, on this particular one. But, but-

Jenn Gile: I mean, I think the intent is good, and I think we all agree npm should be doing this. We're seeing other ecosystems doing this. The question we should be asking is, is what they're doing adequate? And I don't think we have enough information about the, you know, the recent announcements. We saw there were two on July 28th. One was about the pre-publication scanning. The other was about GitHub Actions. I mean, the GitHub Actions announcement was, like, four sentences, so we really don't know anything about that. So I will, like, again, repeat, yes, please do this. You know, we all love open source. All of us, I think, have worked in previous open source, you know, parts of the ecosystem. We want to see it healthy, but we don't know if what they're doing is adequate. So, like, is it more harmful to implement something like this poorly versus not at all? I would argue, yeah, because you're going to have people trust that it's, you know, safe to consume. They're like, "Oh, well, scanning has happened. npm looked at it." A, you know, it's false sense of security.

John Amaral: It's an awfully big surface area to be good at, and I think it's going to require a lot of, like, collaboration and more than just one set of eyes on this.

Ahmad Nassri: I think we should, like, we should-

John Amaral: It's great that they're doing it.

Ahmad Nassri: like, we should encourage these type of investments.

John Amaral: Yes.

Ahmad Nassri: from anybody and anything.

John Amaral: Agree.

Ahmad Nassri: Us collectively as well, like, we should do that. But like, you know, back to the old saying, you know, trust but verify.

Ahmad Nassri: Right? And to your point as well, and what we were just saying, like, we, we got to inform and educate so that it's not just a false sense of safety and, "Oh, it's just somebody else taking care of it." Because I was, I was saying earlier before we started recording, I remember from back in my day at npm, and I would meet with people and talk about Node and open source and stuff like that. And they would ask me where I would work, and I would say, "Oh, I work at npm." And they're like,

Ahmad Nassri: "npm is a company?" Right? Like, there's this sense of not knowing where your open source comes from, not appreciating that there's actual work that goes behind it. So, like, that education is important for everybody, the consumers, the security practitioners, everybody, that, you know, there is foundational investment and also there's, you know, limitation to what that could provide.

Ashish Kurmi: Just to add to what you, what you said, you know, in my opinion, supply chain, you know, by design touches multiple components, right? So we can't just, you know, assume that there is a silver bullet that will fix, in my opinion, fix all the problems. In my opinion, registry is just one piece of it. So you also have other components like, you know, developer machine, CI/CD pipelines, code repositories. And I think you need, you know, like, comprehensive controls across the stack. That is one point. Second point is, you know, the adversaries are also very smart and they're also quickly evolving, and we all see the evidence of that, right? So, like, initially the, the recommendation was don't use long-term credentials. Then, you know, we moved to OIDC. But in all these recent attacks, we saw that they're actually exploiting OIDC workflows.

Ahmad Nassri: Yeah.

Ashish Kurmi: And they're shifting even further left and going after, you know, GitHub, GitHub credentials. And I mean, we all know that it, it will go-- they, they will continue to evolve. So, you know, we need to have a, like a balanced approach to make sure that, you know, we look at all the pieces

Ahmad Nassri: Yeah.

Ashish Kurmi: and, you know, have adequate controls.

Ahmad Nassri: Yeah, to give you an example of that, like, again, with the npm malware scanning, we just saw, I think a couple weeks ago, there was a targeted attack on the Alibaba Cloud environment with SDKs and tools. And if you looked at the packages individually, they were kind of benign. But when you put them together in the same dependency tree, all of a sudden they can become malicious. So again, it depends on how does this malware scanning work, how does the, the knowledge that you're building your training on and the, the, that kind of-

Ashish Kurmi: Yeah.

Ahmad Nassri: data that you're training on.

Ashish Kurmi: To your point, supply chain is not just a dependency graph. It's also-

Ahmad Nassri: Exactly.

Ashish Kurmi: execution graph.

Ahmad Nassri: Exactly.

Ashish Kurmi: The context also matters.

Ahmad Nassri: Exactly.

Ashish Kurmi: You know, where the code is being built, you know.

John Amaral: And, and, and using AI tooling to kind of deduce these, these, these exploit paths like this. Like, humans, we're not that great at, at these kinds of maybe distributed style of attacks like you just described, but agents can figure that out.

Ahmad Nassri: And to your point, the attackers are also using the agents to get more creative.

John Amaral: Of course.

Ahmad Nassri: with their own.

John Amaral: They're also using agents that they've on guardrails-

Ahmad Nassri: That's right.

John Amaral: and are able to get those to be more effective for those kinds of attacks.

Paul McCarty: I want to come back to your original question about npm, because I want to take my opportunity to skewer them. He's, he's not been there for eight years. The reality is that these changes in npm 12 are great.

Paul McCarty: You know, hallelujah. But the reality is that Microsoft has a lot of money, a lot of cash, and they should be spending a lot more money internally and building out their teams and their capability to do this themselves, right? They bought npm. They need to treat it with the respect and keep it safe the way that you should, like when you buy any asset. And they are not doing that. And I want to be very explicit. They are not doing that enough. Straight up.

Jenn Gile: I think it's a microcosm of what we're seeing across security, where budgets are moving from security to AI. I mean, if you look, you just look at the job postings that are at Microsoft and everything. You know, they're hiring AI-focused roles rather than security roles. And it's, you know, the money, follow the money and you'll see where it's invested.

John Amaral: Ah, that's wrong.

Paul McCarty: A lot of my response is like, when I turn in an npm package as malicious, basically how long it takes for them to take it off the repo, off the registry is kind of a good denominator.

John Amaral: That's a great indicator, yeah.

Paul McCarty: And that is like, sure, sometimes they, they throw a bunch of people in it and it goes down to, like, two days. But then within a week, it's back up to, like, four weeks or something. I've had them take five and a half months to take packages-

John Amaral: Oof.

Paul McCarty: off of the npm registry.

John Amaral: Colonel.

Paul McCarty: Right? So the reality, and they've outsourced a lot of that now. They don't have that internal. They're doing that outsourced, right? And that means it's even slower and they have less of that subject matter expertise in those teams to do that. And that is wrong. They need to bring that, that subject matter expertise in-house, build up those teams so that we don't have to do it. Because as Charlie says all the time, he and I shouldn't be doing this. We should not be-

John Amaral: Yeah.

Paul McCarty: doing this, right?

John Amaral: Yeah.

Paul McCarty: Straight up.

John Amaral: Yeah. And, and you saw, you see this happening also with centralized, like, systems like that. NVD a year ago or more had this, you know, massive backlog they've never caught up with that's deteriorating. I think it's just, you know, like, the, these, these, the incentives just aren't there for these organizations.

Jenn Gile: To support the ecosystem.

John Amaral: to some degree to do this, which is, is warped. Like, it's just backwards.

Paul McCarty: Yeah. It's easier for them to do nothing than to do something.

John Amaral: Yeah. And, and, and the inputs to them that, that they'll need to react to are just going to keep growing and growing, right? As we've seen in, in both cases. I'm sure there's more malware than they ever anticipated coming at them.

Mackenzie Jackson: But okay, let's talk about vendors, right? Because we're, we're all here. And, you know, we do a lot of great things, and I wanted to put the people that are doing great research in the room, because I think that overall we, we have a net good. We also have a couple of toxic traits that we do. I think some of that, there's been some pretty public fights, some, you know, some, some social media posts about who found it first and yada yada, and not, you know... What, what are vendors doing that is totally unhelpful in, in this situation? And I'll, I'll-

Paul McCarty: I'll be quiet.

Jenn Gile: Application-

Mackenzie Jackson: Yeah.

Paul McCarty: I'm going to shut up.

Jenn Gile: Application security has gotten so competitive and malware discovery analysis has become a differentiator. And if you look as the former marketer in the room who has had to have these conversations with people about how do you, you know, raise awareness of a company, how do you improve SEO and now what they call AI SEO or GEO, a lot of it comes back to who can make the discovery first, who can get it picked up by PR first. We haven't even talked about Reddit. I don't know if we're going to go there, but, you know, the poisoning of Reddit that's happening. And all of this is this game to get to the top of people's attention for the limited dollars that are available in application security. And you layer on top of it the negative incentives that are there because of the need to be the AI fill in the blank. I mean, there's just so much incentive right now to kind of not always do the right thing for the community in order to do the right thing for your company. And those things are constantly-

Paul McCarty: Yeah.

Jenn Gile: butting heads. And so I will say, I don't, I don't think anybody's intending to, you know, poison the industry. I think everyone here has the right intention, but we're also just in a really competitive market.

Mackenzie Jackson: Yeah.

Jenn Gile: And it, it, the behavior is what you would expect from that.

Mackenzie Jackson: Yeah.

John Amaral: My, my North Star is really thinking about the, the, the compromise, the end people who are suffering from these style of attacks. I think find it first and find it fast is a good thing. And I think generally from the user's perspective, I want to find things as fast as I can because I want them to know. What leaves me lingering, what lingers in my mind is not the effect to the, to the, to the vulnerable on who found it first. It's who's the last person to get remediated after the, after, after the fact? I think we don't do a good enough job at, at, like, following through and making sure every last compromised person, giving them the tools, the knowledge, all the things that the end user will need to, or the end, the, the victims will need to get their, themselves right and never have it happen again. I think that's super important, and we don't talk enough about that probably last survivor who didn't get their Log4j out of their environment. Like, that's pretty important, too. And, and we don't talk much about it. It's not sexy. It's just hard work, and, and we need to do more of it, in my opinion.

Paul McCarty: Yeah. I think one of the things that frustrates me as, as a, you know, researcher at the coal face of malware detection is that everybody's rushing to be first, right?

Mackenzie Jackson: Yeah.

Paul McCarty: But also, too, then when we find something, we don't necessarily, you know, give a shout-out to the other people that have been working on that, right?

Mackenzie Jackson: Yeah. Yeah.

Paul McCarty: And this is something you and I have talked about multiple times, right?

Mackenzie Jackson: Yeah.

Jenn Gile: Technology amongst, you know, many of the researchers has gotten great. Like, the time to detection is seconds, if not minutes.

Mackenzie Jackson: I, I think-

Jenn Gile: And that's amazing.

Mackenzie Jackson: Amazing. And what's also, like, you know, frustrating is that, like, it's, we, we're all finding stuff, and then it's just like, who's awake, you know?

Paul McCarty: Yeah.

Mackenzie Jackson: Like-

Paul McCarty: Exactly.

Mackenzie Jackson: Like, we're on different time zones with Socket, right? Which is, you know, like we're-

Paul McCarty: Yeah.

Mackenzie Jackson: which is what, you know, so that's been very helpful, you know, at like different for everyone, right? But-

John Amaral: You got to put the detector in the earliest time zones. Yeah, yeah, yeah.

Paul McCarty: And I'm somewhere in between the two of you, right?

Mackenzie Jackson: Yeah. Right. So, you know, but I want to talk about another thing that, that vendors are kind of into. And, like, I mean, it's in your name, OpenSource Malware. You have a, like a public threat feed. We have a public feed too, but, you know, like, not as scannable or as that, but, like, private feeds, all that, helpful, not helpful. How do we, how do we manage that while still acknowledging that we're offering a service and it costs money to employ people and build these systems? So, like-

Paul McCarty: Yeah.

Mackenzie Jackson: you know, there, there is a challenge of this. What's people's opinions of that?

Ahmad Nassri: I mean, we're, we, we like the fact that we publish all of our findings on all of our package pages. And we don't just publish the, the findings themselves. We also, like, show you the source code of the package. You can navigate it. You can explore it. Show you all the history of all that package's content. It's almost like, not a full mirror of npm and PyPi and so on, but you can go through the history and see how these things have evolved.

Paul McCarty: Your file explorer works better than the npm file explorer.

Ahmad Nassri: Than the npm one, yes.

Paul McCarty: Which you were telling me that you wrote.

Ahmad Nassri: I wrote, yeah, the npm file ex-

Mackenzie Jackson: You wrote the npm.

Paul McCarty: You wrote the npm.

Ahmad Nassri: Yeah. That was the, that was the last feature we released before, you know, Microsoft came in. But we want to share that information. And the way we look at it, I guess, at least from our perspective, is like, from an AppSec tooling perspective, usually that's, you know, not accessible to the developer. The context and information is not always given to the end developer. And the developer is being told, "Nope, you're being blocked and you need to remediate the CVE," or, you know, "This package is not allowed." Why? And then you have to open up a ticket and have a conversation, all of that. So we want to provide as much context to the end developers so that the education and the learning becomes an opportunity for them to avoid the mistake the next time and learn how to not to do these things. And yeah, like, we do see some, like, scraping activities. We do see some, like, other kind of mechanisms that, you know, we try to block and try not to encourage. But at the same time, like, it's kind of like the high, the high tide raises all the boats approach. Like, if that research is in the public and that information is available, then ideally we all elevate the practice to a point where not just the developers are improving, but also each other. And, you know, there, there's a, there's a point of having, I don't know what to call it, but like a bit of a rivalry as well to-

Mackenzie Jackson: Yeah.

Ahmad Nassri: It's not so much about who got it first or who got it second or so on, and the timezone difference and all that. Like, that matters from, like, a messaging to the end customer that-

Mackenzie Jackson: Yeah.

Ahmad Nassri: we're doing the right thing, so we're all collectively doing that. But also, like, knowing what we look at versus what you look at and how we did our analysis, how you did your analysis kind of educates us as well about how to improve.

Jenn Gile: There's always going to be people who can't afford it also.

Mackenzie Jackson: Of course.

Jenn Gile: And it-

Mackenzie Jackson: Yeah.

Jenn Gile: it's damaging, I think, if we all, you know, everyone who did this research kept it gated-

Mackenzie Jackson: Yeah.

Jenn Gile: which let's be honest, a lot of the security industry is that way.

Mackenzie Jackson: Yeah.

Jenn Gile: And I think application security is kind of at the forefront of saying, "Hey, we shouldn't gate everything, you guys."

Mackenzie Jackson: Yeah.

Jenn Gile: But there's always going to be people who can't afford it, and gating it will not change whether they spend dollars on it. And I think we're all hurt by people getting, you know, popped by malware. So it, it's in the community's best interest.

Mackenzie Jackson: I mean, it also-

Jenn Gile: And it's marketing, let's be honest.

Mackenzie Jackson: And it, and it encourages the attackers to keep going, right?

Jenn Gile: Yeah, exactly. They're so successful.

Mackenzie Jackson: The more you hunt these things, the more they feel encouraged.

Paul McCarty: At, at the same time, just to be clear, the free feeds that we do do cost us each individually.

Mackenzie Jackson: Of course. Yeah, correct.

John Amaral: Lots, lots of money.

Paul McCarty: We're all paying for our AWS and S3 bills where all that stuff goes, right?

John Amaral: And, and, and the AI bills that go along with it, right? It's all, it's all happening.

Mackenzie Jackson: You think Charlie's cute? I mean...

Paul McCarty: There's so many jokes I want to make right now.

John Amaral: I didn't throw that in front of you, Charlie.

Mackenzie Jackson: Yeah, no. I totally... How can we be better at this? Like, I wanted this to kind of be a conversation around like, what do we actually do to solve, to solve this? So what can we do as vendors, as a community, as everyone to actually be better?

Ashish Kurmi: Sorry, one, one thing that, that, you know, we have heard from multiple people is when the supply chain attacks happen, there's a lot of chaos, you know, because these attacks are evolving.

Mackenzie Jackson: Yeah.

Ashish Kurmi: We are, we are learning about things in real time. And then there is lack of coordination. Like, if you have a vulnerability, you have a CVE and you can, you know, put that CVE in a search engine and you can find everything about that vulnerability. We don't have anything like that for the supply chain attacks. And, you know, we all-

Mackenzie Jackson: Yeah.

Ashish Kurmi: come up with our own different terms and it gets very difficult to find out everything related to that supply chain attack. So I think one thing that I can think of, you know, something like a central repository, and there are pros and cons. I'm not sure whether-

Mackenzie Jackson: Yeah.

Ashish Kurmi: that's practical or not, to provide consistency to the community about this.

Mackenzie Jackson: It would need to be a separate foundation or something to-

Ashish Kurmi: Yeah.

Mackenzie Jackson: to run that. I think that's the key, is that what... if something does become the central source of that, it can't be vendor owned.

Paul McCarty: Yeah.

Mackenzie Jackson: And it also can't be like open source that someone could...

John Amaral: I, I, I certainly don't want to see this kind of stuff going into NVD.

Jenn Gile: Well, I guess what I would say is, I love it, and how would we make sure it doesn't have the problems that OSV-

Mackenzie Jackson: Right.

Jenn Gile: has? Because we're seeing false positives.

Mackenzie Jackson: Yes.

Jenn Gile: We're seeing delays, you know, in things getting into OSV. And so if it's not vendor-run, then how... And I don't have the answer, because clearly we've got these problems that the industry hasn't solved. How do we make sure that these systems can keep up? I don't know.

Mackenzie Jackson: Yeah. Well, and it... You know, I, I think, like for me, I think a key part would be it would have to involve the vendors, but also the, the registries themselves, you know, tying into this and helping. If we actually wanted to solve it, then it needs to also involve them as well.

John Amaral: What, what you said earlier about disclosure to how long does it take to actually get the package taken down or the malware remediated, that kind of information would be super useful if people had it in their hands, right?

Jenn Gile: Yeah. And I mean, I think if credible, well-known researchers are reporting things and it's not getting taken down-

Mackenzie Jackson: Correct.

Ashish Kurmi: Yeah.

Jenn Gile: you know, what else might be happening? We saw just two days ago with that new npm worm, Jared Ray-

Mackenzie Jackson: Yep.

Jenn Gile: you know, took to X and other platforms because he couldn't get, you know, any response from npm or GitHub.

Mackenzie Jackson: Yeah.

Ashish Kurmi: Yeah.

Jenn Gile: And I... Maybe I'm going off track here, but, you know...

Paul McCarty: No, that's absolutely on track.

Jenn Gile: If a maintainer can't get engagement and well-known researchers can't get engagement, then we have bigger problems in the industry.

Mackenzie Jackson: It was, that was also the same when Josh Juno got, got compromised.

Jenn Gile: Yeah, exact same thing.

Mackenzie Jackson: We were chatting to him and he's like, "I don't know what to do."

Jenn Gile: Yeah.

Mackenzie Jackson: "Because I don't... I, like, I'm just waiting for npm to tell me that I can access-"

John Amaral: And maybe that's the education place, like education for maintainers or just providing these resources so we can do a way better-

Paul McCarty: I'm going to take the opportunity to skewer GitHub again. I think that GitHub needs to take ownership of this and say, "Hey, listen." Cause what they're doing is they're basically... they're blocking people because it makes sense, right? Those people have pushed out packages that are malicious, and in this case this week, which we're seeing more and more, their GitHub repos are also malicious too as well, right? So it makes sense that GitHub would do that. But then the problem becomes that the, the maintainer, once they know, can't undo any of that, can't mitigate that, right? So if... And this is happening enough, I feel like there can be like a team at GitHub that does this part of their time and handles this kind of stuff. Because when we're talking about two billion downloads a week, to me, I feel like there's some, some... You know, we can have some people doing this-

John Amaral: Yep.

Paul McCarty: you know, for that kind of impact.

Mackenzie Jackson: Absolutely. I, I also kind of like... I'm curious about from the maintainers side of thing too, because the other part is, like, there's not enough support out there for maintainers as well on this. And that's like... How... What can, what can the industry do to better support, you know, maintainers in, in this? Because the, the weight on their shoulder and then, you know, they're, they're such a great guy or great girl maintaining something until they're the worst person ever because they got phished.

Jenn Gile: Well, I will say in like some positive way, you know, I DMed with Jason and he already had people, you know, reaching out and helping him. And we offered him, you know, "Hey, you might look for persistence in these ways." Like, he was actually getting lots of engagement from the security community. And that's like, that's great. I love seeing that. And, you know, you kind of tend to see the same thing with GitHub issues. You know, "Hey, I saw, you know, something malicious pushed. Here's the things I think you need to do." Like, I think that is kind of happening somewhat organically already, and I think that's a good thing.

Mackenzie Jackson: What would be advice for developers right now? If we just keep it quick, like what, what can developers do to protect themselves or organizations do to protect themselves from supply chain attacks? Because I know we've solved it in this room, but it's going to take us a couple of weeks to sort it out. So within that time, you know, what can the industry do?

Jenn Gile: I would love to see more people working on integrating agents with intelligence feeds. You know, wherever that intel is coming from, if you can... because this is, again, coming to what people do and don't understand about how malware works. If you can prevent it from coming into your system in the first place by making sure your agent doesn't select something malicious, then you have fewer knock-on issues later. So I would love to see more people, like, prioritizing that type of a data integration.

Ahmad Nassri: I think organizations need to invest in training their employees and people in our category and get more familiar with the risks and the threats and all these things. Because it's not enough to just hire developers to build features. You also want to hire developers and make them responsible and more familiar with this category of technology and all the challenges that comes along with it. Like what we were saying earlier about, like, the deep lore of how package managers work, how CIs work and all that stuff. It's not enough to just say, "Let the agent do it." You have to build some expertise there.

Paul McCarty: I think my answer is I, I, I would hope that developers realize that they're being... they're a target right now, right? Like, DPRK has got persistence on thousands of, of, you know, developers' machines, and they're a target because of all those things we said at, at the top. So developers, if you understand that, do those things you need to do, whether it's installing the Socket Firewall or Aikido's version of that. Start being proactive on your endpoint to take control of some of that, you know, plugging feeds into whatever that thing is, right? Because your laptop is being attacked.

John Amaral: Yeah, I think they need to be trained and they need to be better at and even more proactive at knowing what software they're using, like, from all the different ways and, and locking things and pinning things. I think just more practice in this. Knowing what, you know, a package manager directive is going to do when you, when you tell it to upgrade something. Like, just having more understanding of how all that works and just really being the, the steward of your software. It's so easy now to build software that this all gets lost.

Ashish Kurmi: And just to add to what you said, you know, have better visibility into the software that you're pulling in, but also, you know, have better visibility into the dev tools and, you know, that-

John Amaral: Yeah.

Ashish Kurmi: other platforms that you use, because we saw now attackers are also going after IDE extensions and, and so on.

Paul McCarty: VS Code.

Ashish Kurmi: Yeah.

John Amaral: Yeah.

Paul McCarty: That is, like, the number one thing.

John Amaral: Another great. Yeah.

Paul McCarty: Yeah.

Mackenzie Jackson: Let's start a new podcast on VS Code. Yeah, yeah, yeah. All right, we're going to leave it there, but this was awesome. Thanks so much for all agreeing to come here and sit down.

Paul McCarty: We need to do more of this. That question you asked, we need to do more of this.

Ahmad Nassri: Yes. Same time next year.

Mackenzie Jackson: Bigger room.

John Amaral: Yeah.

Jenn Gile: More microphones.

Mackenzie Jackson: Thanks so much. We'll, we'll leave it there.

Suggested episodes