npm Account Takeovers: Preventing the next Shai-Hulud

Uh, so my name is Jen Guile. Uh, as the slide denotes is what you showed up for. I'm going to be talking about npm malware. I'll tell you a little bit about myself and then I want to know a little bit about who's here today. So, oh, it helps if you turn it on. Did you know that? That's me. In case you're in the back and can't see me over people's heads, it's nice and big and billboard sized. Uh, so I am co-founder of opensourcemalware.com. It is a free communitydriven uh threat intelligence database of malicious open-source packages, repositories, and domains. Uh, talk to me later about that. We're not going to be talking about it today. I'm also an adviser for

Endor Labs. If you haven't seen their AI photo booth over by the check-in, you should go check it out. Uh, I'm the communities lead for Besides Seattle. So, who has been to the village? Okay, go back to the village and go meet all those cool communities that are in there. We've got the EFF, we've got Infregard, we've got tons of people who are looking to both uh offer educational opportunities as well as bring people in as volunteers. So, go meet them. And I'm also a board member member for Second Cycle, which is a community cycling shop in Tacoma. That's enough about me. Uh, show of hands. How many of you work in security right now?

Okay. How many developers do I have? Hey, dev friends. Uh, how many of you are threat hunters of some kind? Researchers? A few. How many of you work in application security? Okay. Cloud security. something else. Awesome. I love the diversity. So, we're going to be kind of talking at a high level about some trends that I've observed over the last six months or so and what it means for the coming weeks, months, years in uh the open source world. Uh I'm not a developer and I'm not a uh security practitioner. where I sit is more at looking at how those things work and then what their impacts are on the business. So, I'm going to go

into several areas around npm malware. If you have questions, we'll get to them at the end. Okay, I want to start out with a definition. We have a diverse group here. I want to make sure that we're using the same vocabulary. Uh we have vulnerabilities, sometimes called CVEEs, and we have intentionally malicious packages. These are two really different things. A vulnerability is just a bug that a developer accidentally put in a product uh you know package that can be exploited. Hypothetical exploitation. Um typically that is going to be application focused. It's exploited wherever that third party library is running and it gets issued a CVE as a permanent record. Now the reason this matters is because that is not what

malware is. Malware was developed by somebody with the intention to harm. So it works differently in that it's targeting the person who downloaded it. It's targeting you as a developer, as a security person and your organization as opposed to having maybe a like, you know, objective to get into your application code. It often also has a short lifespan on public registries. It used to be that malware would stick around for weeks or months, but many registries have gotten a lot better about taking it down quickly. Sometimes it's hours, often it's within a few days. And so the way that we approach these is really important to be different. So if you have a best practice of always upgrading

to the latest version to avoid a vulnerability, what does that mean for you about malware? It's updated just as quickly. >> It's updated just as quickly. And so what bad actors are looking for, what they're counting on is that you're updating as quickly as you can. It is a numbers game and they're here to catch whoever they can in those numbers. So let's look at some numbers. Uh I again continue to advise with Ender Labs. I've been involved with their research and one of the things that we've been looking at is the trends in npm specifically. And so I'm going to be talking about npm because it is the biggest source of malware in the open

source ecosystem. We'll talk about why that is in just a moment, but I want to make sure you understand the scale. So this is from um an OSSF uh repo. Anyone who wants the slides afterwards, connect with me. You can get this link. You can see live data of OSV uh alerts or uh advisories for malware. So it goes all the way way back to 2011 with a single npm package and you'll see npm is this purple line on top that you know they're kind of running parallelish for a while and you know pi comes in here that's the green you've got some maven etc and then uh things start to get real scary here right so what we saw

in 2025 was a 20x increase in malware advisories in npm now there's a very specific reason for that there was very large campaign called Indonesian tea theft or Indonesian foods that drove a lot of that. Um but a very interesting unrelated to the Indonesian foods incident is increases in account takeovers. So an account takeover is when a bad actor gets access to a genuine open-source package. So rather than putting their kind of open- source spam up there on npm, they go and find a reputable package, they infiltrate it and they publish their malware. So we saw a 12 times increase in ATO's last year. With ATOS's, the trust is your your threat vector. You trust that package

already. You are already automatically upgrading to the latest version. And so while they may not do as many ATO's as they will novel malware, the possibility for an ATO to have an outsized impact is tremendous because again you're you're downloading something you already trust. So if you always upgrade to latest, you are the target. We're going to talk a bit more about why thread actors love npm. There's a lot of reasons. I'm going to dive deep into five 2025 malware campaigns where atto was the strategy in all of those. And then I'm going to talk about some tips for open source consumers in terms of if you are personally consuming packages from npm if your organization is what

are some things that you can do to protect yourself. Okay, we'll get here in a second. One of the reasons npm is so tasty is because of JavaScript. JavaScript is one of the most widely used languages and JavaScript loves its dependencies. So it is, you know, you call one library, it calls 12, those 12 call another in number. You've got a ton of dependencies coming in. So they love it for that reason, but they also love it because there are some very specific security issues with npm. So first off, install scripts run by default. So if you download malware and you have these install scripts running, it will automatically uh install the malware rather than a

human having to do it. Provenence is not mandatory in the npm ecosystem and it's not something that everybody looks at. And so it's very easy uh to bypass chains of trust. It's often. We're going to talk a lot about the token program, but historically, npm has had extremely longived tokens that have made it very easy to get access to somebody's account because the tokens are good for a long time, don't get rotated very often. Now, again, we're going to come back to that. Is anyone here uh an npm maintainer out of curiosity? Nobody wants to admit it. That's okay. you can talk to me later. Um, we're going to talk a lot about tokens. So, this is the shortest part of the

talk. The thing to understand is these are inherent security challenges with npm. And while it can be very easy to be an npm hater, I'd encourage you to also have some understanding for why it's this way. When you create a product, you want to drive adoption, right? And so, you lower the barrier to entry. You make it really easy to sign up. And so you get everybody hosting your projects. Who else can sign up really easily? Thread actors. So that's how we got there. It's harder to dig out of a hole like that and bring in more security requirements, not to say they shouldn't, than it is to start secure in the first place. So for the next probably 20 to 30

minutes, I'm going to be talking in depth about five malware campaigns. Now, you might argue that this is fewer than five, and I might agree with you, but the way we experienced them chronologically was as five separate campaigns. So, we're going to start July 18th, and we're going to end November 24th. This was a, you know, for the most part, summer incident. Uh, when I was working at Endor Labs, we had a lot of customers having a lot of bad times because they were worried about if they were popped by this. And so you had a lot of people spending additional cycles thinking about whether they could possibly be affected rather than doing their jobs. How many of you

Let's let me put this in a way that no one will have to out their company who potentially encountered some of this last year. Yeah. So we'll call it probably double who raised their hands. Um, it's a lot a lot of people suffered. So, we're going to start way back on July 18th with uh the Slint Config prettier project. And you know what? I'm going to drag this monitor out because I didn't realize how big the screen is and I can't see to the top of it. So, I'm going to pull this out so I can see while I talk to you. There we go. That's better, right? Okay. So step one, we have a thread actor

getting access to this project. I've gone ahead and put the weekly downloads here. Uh it's pretty staggering how widely used this just one project is and several were compromised. So we're talking in the millions, 38 million weekly downloads. Uh their credentials were stolen via a fishing email. This email looks pretty professional, right? They're getting really smart. You know, the things that we were trained on a couple years ago of look for typos, look for poor alignment. There are now fishing kits available where you can get the font, you can get the logos, you can get the language. It can look very professional. And so what this email says, "Hi Blank, we're reaching out to all users as part of our regular account

maintenance. To ensure your account remains secure and fully functional, we kindly ask that you verify your email address. Please log in here." It's a typo squatted domain. and uh reverify access to your email. I was rereading this yesterday and I want to emphasize the last line. You're receiving this email because we doubt that you still have access to the email provided. Okay. Um you've got urgency here, right? Verify your email or you'll lose access. This is a frequently downloaded package. This person needs to maintain their access. Click scrape. bye-bye token. So, they were able to steal a publishing token because a maintainer clicked the email. They used that publishing token to publish four malicious uh versions. Now,

this was not particularly sophisticated malware. And in this talk, I'm not going to talk in detail about exactly what the malware did in like super granularity, but sufficees to say, it had an install.js JS script that ran and it dropped a malicious DL during npm install. So we've already seen two examples of those flaws I talked about earlier. We've got the token problem and we've got those install scripts, right? And the impact is attackers could get rce on Windows machines. But the key here was that uh it was very scoped in terms of who could actually be impacted. So even though you had oh I don't have it on the slide 38 million weekly downloads not very many people could be

affected by it. And so we all at the time were like that's weird. Okay. One day later we have the is compromised. Now the is package was not used by as many people. It's only 2.8 million weekly downloads. But I don't know about you that's still a lot. Um, Jordan Harban has been pretty uh open about what happened here. Uh, he got a spoofed npm support email. So, in this case, it's a little bit of social engineering to the max. In this email, uh, they told him that, "Hey, oops, we accidentally shut down one of your maintainers accounts. We just need you to verify this so that we can get them their access back." He goes to social

media and he's like, "Grumbble, grumble, grumble. incompetent in PM support and says, "Yeah, yeah, yeah. Go ahead and uh reactivate this person." Well, that was not what he should have done. They were able to publish two malicious versions of the is package directly to the registry. Again, you an install.js script that dropped a DL payload. So, it's looking kind of similar to the package that came out the day before, right? We don't know for sure that it's the same bad actor, but it's probable. This one was interesting because it was um scanning for crypto wallets and cloud credentials and establishing back doors on developer machines. Uh if anyone's been following any of what goes on in

malware, a lot of it does target crypto. Um that is for various reasons, but a lot of it does go to fund state sponsored activities. Okay, we made it through July. It's going to be fine. No, it's not. uh we come to NX and NX is a little bit different from the previous two packages because it's actually maintained by a company and uh it has 9.2 million weekly downloads. It's a pretty sophisticated uh operation that they have. Uh they were not um fished. That is not how the bad actors got access to publishing. the attackers were actually able to exploit a GitHub actions vulnerability. And so maybe you remember a year ago that there was a lot of GitHub actions stuff

little bit of a oh this is a way we could get into their pipelines. They were able to successfully do that and they were able to steal a maintainer's token using this vulnerability. This time they uh compromised eight packages. It had a telemetryjs file and this is where like you got to respect the creativity. It gets really cool. Um the telemetryjs was weaponized uh to use AI against the developers. So it would scan the developer machines and look for locally installed AI tools. Specifically, it was looking for Claude, Gemini, and Amazon Q. And then uh we've all kind of poked at the AI. They poked at the AI by using uh things like dangerously skip permissions and yolo

and trust all tools and they got the AIS to be like oh yes we'll be very helpful to you sir and um used it to find and harvest secrets. Super interesting stuff. Uh this had a lot of conversation as a result more on the business side of like oh my gosh you know how are we scoping AI permissions? How are we making sure that the way we have our um AI code assistants configured can't be abused in this way? So the singularity campaign started by creating a public GitHub repo for each breached organization. The reason it's called Singularity is because each repo was called Singularity-reo or repository. And in just eight hours, even though Jordan uh it wasn't Jordan,

even though Inex realized fairly quickly that they had been compromised, still took about eight hours to shut it down and they had affected 370 companies. So, I'm going to remind you, they used this to scrape secrets. This is the worst day of my life. This is the worst day of your life so far. Two days later, they used those secrets because these people didn't rotate. I see a face. It's horrifying. Uh, the second wave flipped 6,700ish repos to public. Uh, 200,000 files were exfiltrated. So, you start to see the uh economics of what's going on here. They're still using the same tactics. You take over a trusted account. You look for useful data and then you trust

that people are not using good secrets hygiene and you use those secrets to compromise more accounts. So this was in August, late August. We're getting ready to go back for school. You know, it's like I'm on vacation. Labor Day is coming. No, no, no. We're going to deal with Singularity. We got through. But we thought, all right, well, that was done. Then we have Quicks. Quixs is a well-known maintainer, and on September 8th, he was compromised. Again, they go back to more of a fishing uh strategy. And so, they're able to uh use a fake npm support email to reset his TUFA. And so, we have the email up here on the right. And he's actually been on a

podcast. You can Google this. I think it's an Iikido podcast. It's really good. He talks about this experience and what he was going through and that he absolutely knew better. He was tired. He was busy and he was like, I can take care of this right now. Click, click, click. Done. Well, what the email says is, as a part of our ongoing commitment to account security, we are requesting that all users update their two-factor identification authentication credentials. Our records indicate that it has been over 12 months since you last update uh last 2FA update. I mean, this is pretty believable, right? We've just been through three account takeovers where tokens were some kind of an issue. So, if I'm a maintainer, if

I'm paying attention, like this doesn't surprise me that, you know, somebody from npm might say this is a good idea. To maintain the security and integrity of your account, we kindly ask that you complete this update at your earliest convenience. Ready for the threat? Uh, please note that accounts without dated 2FA credentials will be temporarily locked starting September 10th to prevent unauthorized access. So, this is very classic fishing, right? We give you a short time window. It's emergency. You have to react now. We're counting on you to be tired. He was tired. He clicked it and very quickly he realized he'd been pawned. Um he did what he could with npm to try to get it addressed, but you know

once they get in it's often too late. Uh they were able to publish 28 malicious packages injecting a piece of code that was intercepting cyber uh cryptocurrency activity in the browser. Now, what I think is interesting about this attack, because we can see the activity, is only about $1,000 were stolen. Were they just bad at their jobs? Probably not. They probably had some kind of ulterior motive. So, I think what kind of tends to happen when we see these nothing burger exploits of like, oh well, like it was a grand that was stolen. No big deal. There's not a lot of that secondary thinking of okay, the obvious theft is not a big deal. What's

the like hidden agenda going on here? Who knows what came next? Who watches Dune? Yeah, Shy Hulude came next. Um, it was nasty. It was not fun. So, uh, about a week later is when Shy Hollude started. And again, fake npm uh support email allowed the attackers to reset to FA, gain access to the maintainer's account, and lock the maintainer out. I'm not going to talk in depth about the worm or you may call it virus capabilities. You can Google that. The business side of it is definitely the more interesting thing. They were able to publish 187 packages, disguised a color library as uh disguised the malware as a color library. And again, you got to give them some credit. They

did some clever things here. Uh it had a malicious bundle.js file which installed truffle hog. Anyone familiar with truffle hog? Yeah, truffle hog is a fantastic project. It is for looking to see if you have exposed secrets in your work. Well, they would like to know if you have exposed secrets in your work. So, tr they had trouble hog set up to scan everyone who downloaded this for secrets and then it automatically hijacked and republished the infected packages. So, we saw 528 repositories converted to public. Uh they were exfiltrating secrets to a um web hook service which would have kept going except like core tenant of malware threat acting is be cheap. Uh they were

cheap and their quotas were exceeded. >> They were still $1,000. >> Yeah. So uh why do we think they had two different ways of excfiltrating here?

>> It could be which worked better. But think about plausible deniability. If it's all been published on the internet for anybody to use, it's a lot harder to kind of figure out how somebody maybe found out as opposed to, you know, tracking down a web hook service. So, we went through wave one and everyone was like, well, that sucked. And then six weeks later, the second wave came. I think this was the week of Thanksgiving. Thank you. um they used those secrets from wave 1. So I'm going to remind you of a couple things here. There's two important dimensions. First of all, time. Six weeks had passed. Second of all, uh everyone who was breached probably knew

that they were breached and knew what had been breached. So what did those people not do? >> Rotate their secrets. Bummer. Um so they didn't have to rely on, you know, social engineering or fishing this time. They had your keys, so they got in. This time they hijacked 492 packages. Uh there was a little bit of a variation. They used bun instead this time, but it was the same playbook. Uh it they used truffle hog, you know, scrape for secrets, but this time it had just like a little nasty twist, which was um if there was an off failure detected, they would wipe your home directory. Uh so over 20,000 credentials were exposed from this uh well-known brands Postman,

Zapier uh were all published to GitHub. So let's look at some data because one of the things that I think uh there's a failure to accept in the community is this is not a tech problem. So, uh, this company, Entro, looked at, uh, about 30,000 of the packages that were compromised and looked to see what kind of industries those packages were from. What they found is it was just over half were tech companies. They also found that uh, within 3 days there were still valid credentials floating around. So, this was not like a surprise no one's heard of Shy Holude kind of a thing. like this was after this is the fifth incident well sixth

right uh in a row where we haven't quite caught up. So we're dealing with real estate government banking logistics telco media insurance healthcare. We're starting to see the impact of this campaign going well beyond tech companies. Okay, so what can npm maintainers do? First off, there's a thing called uh hardware keys or UB keys, whatever. Anybody use these? Good for you. Uh they've been available uh as an npm feature since about 2015. Um really what it's doing is it's uh protecting the human authentication path. So you can't get fished, right? uh it's not going to sign if the browser's origin doesn't match the registered domain. Now, there's always a con with every security measure. That's why we

talk about defense and depth. Um your CI/CD pipeline tokens are still fully exposed. Okay, that's fine. Uh probably in reaction to the first two at some people involved a bit so I can't say more than that. It trusted publishing came out at the end of July. Now, trusted publishing is not a new concept. This is something that other registries do. Uh they had kind of been experimenting with trusted publishing but this is when uh npm had it available for GA. Now what trusted publishing does is it kind of balances out okay if you've got a hardware key you're protected but your pipeline's not. So we're going to protect the machine path by uh only accepting versions published

from a very specific GitHub actions runner with an OIDC token. uh low adoption is a problem here. There's a lot of friction in setting this up. Uh ecosystem support is not there. For example, it's not supported on Bitbucket. I think it's just GitLab and GitHub today. And there's still some nuance with the permissions where depending on how you configure it, someone can still come in and manually push out a malicious package. And so with trusted publishing, this requires some education on the part of consumers because you really do have to be looking at the metadata to see this package is supposed to go through trust trusted publishing and didn't. So there's a fair number of cons with this

which is again why we have multiple options. And then third at the end of December or sorry the beginning of December and just about nine days before the um or nine days after the second Shy Hallude wave. So some timing there is when they uh went ahead and implemented sessionbased authorization for npm and this is where they're limiting the token exposure window so that you have a shorter token life. This is really good. Happy they did this. Um, this is still fishable. So, understand just because your token is short-lived, it doesn't mean, you know, I just generated a token and then I click on a fishing email and nothing happens. Um, and you can still do 90-day

tokens uh in npm. So, limited. Let's hone in on trusted publishing for a second because there's been a lot of buzz in the news about it about, you know, this being kind of like a silver bullet, best practice, etc. So, we looked at uh everyone all time who's been an ATO victim in NPM and uh looked at the metadata and said, "How many of them are using trusted publishing?" Because if you've been the victim of an ATO, then you probably are going to be a little bit more interested in security. Well, it turned out it's only about 13% of previous ATO victims are using trusted publishing. Now, we looked at Shy Hallude victims specifically. Up or down? What do you think? More

likely or less likely to be using trusted publishing? >> I hope it's up. >> I really wish it was up. It's about 10% 11. Um, this is not a knock on those maintainers because again there's real barriers to being able to implement this technology, but it's to kind of emphasize that yes, these uh protections are there, but they're not all widely accessible and adoptable. And so as consumers of open source, we need to take some responsibility for what we're consuming. It's a team sport. So having worked in application security and now working in threat intelligence, I do tend to see a little bit of a narrative and certainly the vendors do it of if you do this one

thing, you'll be protected from malware and that's simply not the case, right? Um what we see is that the organizations that are much less likely to be victims are treating it across at least four separate areas. your developers, your application security or product security, cloud security, instant response, and CTI. So, this is where I say uh if you do everything I tell you and you still get popped, it's not my fault. So, I'm going to give you some recommendations, like two tips per team. And I would encourage you uh because a lot of you are in one of these teams to maybe go back and talk to your organization. uh maybe form a little malware task force to talk internally

about how can you protect yourselves. Okay, we're going to start with the developers. This makes sense. They're the ones downloading the packages, right? They are closest to boom. Um their, you know, mission should be safe dependency confusion. And uh I've worked with devs long enough. I worked at EngineX for years before going into security. I don't believe the narrative that developers don't care about security. I think that's a dangerous false narrative. There's a good number of developers here. Clearly, you care about security or you wouldn't be here. Uh but you do have to make it a little easy, right? So, we do have a bit of a question for those developers of can you put up with a little little bit more

friction so that you don't have a terrible day in the future. So, here's what the little bit more friction looks like. One thing is using lock files and being cautious about auto upgrading. So using a lock file means that if a new malicious version of a package comes out that you're using that it doesn't automatically pull the new one. Um now the don't autoupgrade thing that could be a real cultural change right because there's a lot of organizations that believe latest is greatest. So this is like a you know not just tech conversation. The second thing to think about, oh, taking a step back, my little bullet, just a reminder, most ATO's are taken down within 3 days or so. So,

we're not saying don't ever upgrade to latest. Just like let it mellow. Um, the second thing is life cycle scripts. So, this is going back to that post install like these things that npm does that make it very easy for malware to be automatically deployed. And the reason I say beware is because I understand that these are useful. They're convenient. They make your job faster and easier. But I would encourage you to think about like how you code with AI. And you're not going to just yolo it and let AI do everything and not approve any of it. Right. Right. Same thing here. Like don't let npm, you know, install scripts just decide what's going to get installed for you. like be

in control. Okay. Product security, application security, your focus is on hardening those pipelines, enforcing guardrails. And so the question I would have for you if you're in prod or appsac is are your guard rails automatic or do they depend on somebody remembering to do the right thing? Um I'm not going to lie and say this is easy. I've talked to a lot of organizations that still are scanning after things shift to production. I realize that's the reality. And so if you're not scanning in CI yet, I understand that this is a change for you. Um, so the first thing you might do, doesn't have anything to do with uh when your scans happen, is search for

unpinned dependencies. If you find unpinned dependencies, you can report them to engineering. You can educate them about the danger of unpinned dependencies. And this is a thing that they can take care of as part of their backlog. The second thing is scanning for malware both in CI and everyone's using AI these days. So using it in whatever your AI IDE of choice is. There's some really interesting experiments out there for how you can actually help uh a you know cursor etc uh pull safe dependencies. But what I am going to warn you of is uh if you're not doing those things, it's highly likely to pull bad stuff. Uh we did research at Ender Labs where we

found that four out of five dependencies pulled by um LLMs were either uh vulnerable or totally hallucinated. We didn't even look at malware at that point, but I have a friend who said that he's had a particularly famous uh AI coding tool try to serve him malware three times. So like as a reminder, these things are not secure by default. So look at the ways that you can help uh these models make responsible decisions about what to pull. Okay, cloud security. Now traditionally you've been about blast defense right but uh I want to draw your attention to 13% of what got stolen from shy hallude cloud keys so start thinking about your role in malware defense a little bit

more actively how often these keys getting rotated uh how are you uh watching what happens with them so the question I would have for cloud security is if your developers AWS keys were stolen today, would you know? What would you do? So, obviously, you know, rotating and scoping credentials, but also monitor for anomalous credential use. And then finally, uh, incident response, uh, cyber threat intelligence. You know, you're looking more about, uh, is your IR playbook ready for a supply chain attack? Uh, I've been doing a lot of talking in the community lately about the problem of malicious open source and it operates differently than classic open source. So, you know, do you have the tools in place to analyze these? Um,

these kinds of open source, they don't detonate. If you put them in a sandbox, they'll realize they're in a sandbox and they'll be quiet. So, uh, keep in mind they play by different rules. So, make sure you're bringing in open-source threat intelligence that is specific, will help you understand the supply chain risk. And then make sure, of course, that you have a supply chain incident response playbook. And I think that brings me to the end. How did I do? Oh, 10:39. Plenty of time for questions. So, first of all, thank you. Uh, if you'd like the slides and resources, this one down here is me. I will accept your requests and I will send you stuff that's not full of

malware. And then, uh, please do the session feedback form. It's useful for the conference. It's useful for me. And yeah, I'll take questions for maybe uh 10 minutes or so and then I want to make sure the room has enough time to turn over. To repeat the question both so people can hear it and to make sure I got it right. Am I aware of uh tools resources out there for open-source supply chain? Uh are you speaking specifically about vendors frameworks? What do you kind of Yeah. Uh so there's a few different ways to approach the code itself. Uh open source malware is a freely available threat database of malicious open source. So you can go in and search it

uh both through UI and API. It's got the largest most comprehensive uh listings of malicious components. So if you want to go in, you can do that with no credit card, no requirements. If you want um something that's like scanning continuously that usually gets approached from two different ways. There's uh several application security vendors that are focused in this space. Endor labs, socket, iikido would be three. So endors here you can talk to them. I know socket's here. Um, and then in the CTI space, uh, it's not really transitioned yet to have a lot of vendors that have a lot of in-depth information about this particular type of threat. So, it's a growing area. So,

his comment is uh, using Koi Security, which just got acquired by PaloAlto Networks. I believe they do like more of a endpoint protection type of thing, blocking at the network level. Yeah. Um, it'll be really interesting to see what happens with them postacquisition. I've seen that movie before. Um, there are companies that are looking at like firewalls and things like that. Uh, you know, I think it's a multi-pronged approach. You need education and why should I care with this? you know, you can set up uh a you know, safe way to consume uh packages, you know, through an artifactory or something like that, but if people have the ability to circumvent it and don't understand why that's not ideal, then

they're going to do it. I see a hand in the back. >> Yeah. So, uh the question is basically like if you're using uh I believe uh so the chain garden, what is it two that you called out? I don't remember if they call them like uh vulnerability free open source something like that. they are focused on vulnerabilities, not malware. Um, certainly what I tend to see is you pick your core packages that are really important and try to curate those in some way. It doesn't honestly matter if it's coming from a vendor versus if your platform operations team is savvy and can curate it themselves. Coincidentally, uh Kyle Quest is over in another room right now talking about how

you can actually hide vulnerabilities in uh packages so that scanners can't see them. So, I don't know. Um it's one of many things that you can do. Okay, I saw a hand here. >> Yeah. So, uh >> asking for clarification on auto upgrades.

>> Yeah. So, uh, this goes back to the beginning where I was talking about vulnerabilities versus open source and how many of our security programs are built around responding to vulnerabilities and this important but also somewhat hypothetical threat where we upgrade to latest to avoid those things. Malware is counting on you upgrading as soon as possible. So, I'm not saying don't upgrade to latest. Uh what I'm saying is uh consider cool down periods and this is something you can enforce by policy where maybe you wait 72 hours before upgrading to latest and so it's not saying you know weeks or months but like as I showed in the cases that we talked about that are fairly famous from last

year most of them were taken down within three days. So, if you can in most cases wait a couple days. Now, where you may run into tradeoffs is if you have customer SLAs's that have a specific requirement and you're going to have to figure out internally how you want to handle that. Do you buy that answer? >> Yeah, you need to weigh it, especially if you're >> Yeah. Okay. I saw here. I saw here. We'll go here. If I were CTO of npm for a day, what would I do? >> Oh, if my co-founder were here, he'd have words. Uh, so npm could be more responsive to reports of malicious packages. Um, the data is not public yet, but some of what

Endor Labs has looked at is packages that are verified malicious, have OSV listings, and are still in npm. Um, this is not a small number of packages. It's thousands and they're not ATOS's. They are novel malware. But um yeah, faster response would be what I would want to see. Okay. I see several hands back here. I'm going to let you police yourselves. >> Sure. >> Okay. Uh I'm going to talk about your sbomb question first. Uh so the question is basically what's the role of sbombs in this? Um correct. There is no mandate for most organizations to use sbombs. And I'm going to argue having an independent sbomb may not be as useful for you. Uh what I've seen as I've gone

through incident response with application security customers is when your scanner that is looking for all of your dependencies can also produce an sbomb, then you can respond extraordinarily quickly. So you can go in and you can say, "Am I using NX version whatever?" Whatever. Nope. Cool. So I'll tell you the difference is you may have an answer within 30 minutes versus weeks. So an ESBOM for compliance purposes, me for response purposes, yes, but only if it's like connected to something that's like live feeding into it. Uh in the interest of time, I'm going to skip your second question because we've had other hands and we can come back. Great question. The question is about are we seeing trends with

regard to threat actors. Uh for ATO's, nothing concrete. There's certainly hypotheses. Uh I believe gosh now I can't remember exactly who it was. I think it was Cassinia's session yesterday. She was talking about how AI makes things cheaper. Um so certainly AI is making it cheaper to make malware and to make a good campaign. And so what used to be more of a professional um you know job is easier. Um that said most nonat stuff a lot of it is state sponsored. Um if you've heard of the contagious interview campaign who's heard of contagious interview do you know who's behind it? Lazarus group. So that's DPRK looking to uh fundra. So there is substantial state sponsored uh

but in terms of the ATO's we don't have a concrete exactly who it is now as you're talking about trends uh back at the beginning the line has stayed a little bit flat since November we haven't seen spikes there could be a couple reasons for that one is they got a ton of credentials last fall and they're probably just going to town on that. Um, but the other is, you know, a little bit of a, okay, if they're being quiet, if they're not publishing new malware, what are they doing? What's their plan? What's coming next? So, this could be a, you know, a lull and we could see a pop again. Yeah. Back here. I'm going to answer a different question

and then I'm going to answer that. Uh, watch out for skills right now. There's a lot of malicious skills. Uh, I'm seeing. So, you're asking about are there extensions? Are there things to help with finding malware in your AI IDE? I would say there are things out there to give you more malware in it. Um, there's not anything that I would say is uh truly production ready to use at scale to be detecting malware as your uh agent is writing. However, there are a lot of vendors working in the space. Endorabs is one of them. They've worked with cursor. Um, it's less of an issue of the vendors being mature enough and it's more of a technology question.

Certainly, you know, MCP servers have challenges around scalability because ultimately if you're going to be detecting malware, what you need is a third-party source of information that informs your LLM of the malware. You have to have a way to connect to that, right? So, skills are kind of going in that direction. Hooks are interesting. So, we've seen some like experiments that are promising. I like your paranoia. So, kind of just to repeat the question like uh with the protections that npm put in place like are atto's impossible now? Am I kind of like paraphrasing that correctly? >> Yeah. >> Uh no. >> Yeah. No. Um certainly they help. Certainly they're better than nothing. But um until we start seeing uh maybe

this is my call to action for you. Until we start seeing security people volunteering with projects and helping them adopt security standards, we're probably not going to see a lot of change. You know, most of these projects don't have security experts helping them maintain and helping them with best practices. So, if you're looking to like build your community involvement or your resume, like volunteering with a project that has a lot of downloads could be a great way to like hit all those marks. Okay, I will be out in the hall. I want to make sure the next speaker has time to prep. So, thank you so much all.