BLOG

The OpenSourceMalware Show #8

MSFT unpublished 73 repos, VS Code extension cooldowns, npm v12, Miasma open-sourced, and package firewalls

By cb482791-4ef1-4762-96ad-b0ca4bdd538e ·

The OpenSourceMalware Show #8

The OpenSourceMalware Show is available on YouTube, LinkedIn, and as a podcast.

In this episode we covered:

Miasma Worm Hits Microsoft — On June 5th, 73 Microsoft GitHub repositories were disabled within 105 seconds after being compromised by the Miasma worm. Four GitHub organizations were affected, including the Azure Functions GitHub org, which meant that production CI jobs calling official Azure Functions GitHub Actions failed immediately around the world. The initial foothold appears to trace back to a May 19th compromise of the Durable Task repo, with threat actors maintaining persistence via stolen credentials before returning to trigger the mass takedown. As of the episode date, Microsoft had not issued any official statement about what happened or the impact it caused. The Miasma worm is based on TeamPCP’s open-sourced MiniShai Hulud worm, and the person who open-sourced this newer version appears to be a quasi-security researcher using a non-compromised account — an unusual wrinkle Paul is still investigating.

VS Code Extension Auto-Update Cooldown — VS Code shipped a two-hour auto-update delay for third-party extensions in response to community requests, citing the frequency of extension compromises. The two-hour window is notably shorter than the three-to-seven-day windows practitioners commonly request for internal policy. The change also applies only to the Microsoft VS Code Marketplace and does not appear to extend to OpenVSX, which the Eclipse Foundation runs separately and which has no equivalent proactive scanning. The NX Console compromise is a useful case study here: NX caught the malicious version themselves via a Marketplace email notification, not through any Microsoft detection. OpenVSX had no comparable notification system and was only pulled manually after NX thought to check.

npm v12 Disables Install Scripts and Dynamic Dependencies — npm announced that version 12 will disable install lifecycle scripts (pre, post, and install), direct Git dependencies, and remote tarball dependencies by default — all three together, not piecemeal. This is a meaningful change, because these mechanisms are what allow malware to execute at install time before it reaches a CI pipeline or production environment. The tradeoff is that a large number of legitimate packages rely on install scripts, including native build tooling that uses node-gyp, and real breakage is expected. The harder problem is adoption: this is a package manager change, not a registry change, which means each developer workstation and CI environment must upgrade to npm 12 before the protection applies. Based on how slowly similar breaking changes have rolled out across other ecosystems, the practical impact will likely take years to materialize.

Miasma Gets Open-Sourced — The threat actor behind Miasma open-sourced the worm, continuing a pattern established when TeamPCP open-sourced MiniShai Hulud. Unlike the TeamPCP release, which originated from what appeared to be a compromised account, the account behind this release does not show signs of compromise. That distinction is worth watching.

Package Firewalls — Package firewalls are getting a lot of attention right now, with new offerings launching frequently from AppSec and registry-adjacent vendors. The core concept is a proactive control at the developer endpoint that blocks installation of known or suspected malicious packages before they reach a pipeline. This is meaningfully different from EDR, which detects post-execution. Two broad categories exist: simpler alias-based tools that intercept package manager calls at install time, and more sophisticated daemon-based tools that proxy outbound calls to registries continuously. The alias approach is easy to bypass by calling the package manager’s absolute path directly. The daemon approach offers stronger coverage but introduces latency and additional complexity. Data freshness matters significantly: tools that cache malicious package lists locally may miss account-takeover events that are only hours old. OSV and GHSA are common data sources for these tools, but coverage gaps exist. Whether a package firewall makes sense for a given organization depends heavily on whether they already have an internal registry, how they manage developer endpoint policy, and how easy bypass is in their environment.

Episode Resources

[00:00:00] Jenn Gile: Hello. It is June 11th, and Paul, everything in our prep doc is about Microsoft. And so I think this is just going to be the Microsoft episode, right?

[00:00:16] Paul McCarty: Well, I mean, a lot of them are. We talk about NPM and my- and GitHub a lot, so it's, I, I don't know- Yeah, fair ... if it's necessarily gonna be any different but...

[00:00:24] And VS Code. Speaking of which, I'm not gonna tease it. Well, I am gonna tease it here, but I won't give it away. I'm working on a great image about this and you'll love it, so-

[00:00:33] Jenn Gile: Oh, I do love your AI images. I can't

[00:00:36] Paul McCarty: wait ... stand, standby. Uh, stoked.

[00:00:41] Jenn Gile: I'm delighted. Okay. Let's, uh, give a high level, 'cause unlike most episodes where we jump around topic-wise a lot, these are all, like, kind of interconnected.

[00:00:52] So broadly, we're gonna talk about three things, and then we may, you know, ramble off into somewhere else. Uh, but we're gonna talk about what appears to have been attack on Microsoft that happened last week. Um, we're gonna talk about the new VS Code cooldown, um, feature, and we're gonna talk about NPM install scripts. Does that about sum it up?

[00:01:17] Paul McCarty: Yeah. Yeah. It does.

[00:01:20] Jenn Gile: Okay. So I'm gonna caveat all this with I live in the Seattle area, and, uh, Microsoft is both, you know, part of my every day on the computer and also part of the community that I live in. And, uh, we're gonna say some good things about Microsoft today. We're probably gonna say some things that are not as complimentary, and I mean, that's just kind of the relationship I think a lot of people locally have, is there's, there's pros and cons and, uh, it's not the only mega tech company in the region.

[00:01:52] There's another one that perhaps is hated more. Um, I'm sure, Paul, you know which one that is, but, uh, it's Amazon. Um, yeah. What do you wanna start out with?

[00:02:06] Paul McCarty: I don't know if I hate Amazon more than I hate Microsoft. I mean, my Microsoft hate goes all the way back to the '90s, so It's

[00:02:13] Jenn Gile: deeply- Um- ... entrenched. Yeah, you don't- Yeah live here, so you, you haven't lived with the, uh, the blowback of living in the, the Amazon community.

[00:02:21] Paul McCarty: Well, as I've mentioned to you before, I used to work for a company that had a headquarters there, and I have actually spent a lot of time. I've actually done training and done all kinds of stuff on the Microsoft- Mm-hmm

[00:02:31] and IBM campuses, and I might have even done something at Sun there years and years and years ago. Um, so I have spent a lot of time in your area. Um, but anyhow, that's beside the point. Uh, what order do we wanna tackle these in? Well, we might as well do the, the repos thing first. Um-

[00:02:48] Jenn Gile: Yeah. So what, June 1st for me, June 2nd for you, uh, I was starting to wrap up my day. It was your Saturday, and all of a sudden, um, you figured out that Microsoft had en masse disabled 73 repositories within 105 seconds. And in looking at the behavior, it was very evident that, uh, something had tripped GitHub safety settings and had, uh, I think it was a TOS, uh, violation is what all the repos said.

[00:03:23] And so because of a TOS violation, they all got shut down. Um, where we first saw this was actually people who realized that their stuff broke because these were some pretty high-impact repositories. So Paul, you lived in it. Uh, talk about what happened last week.

Microsoft Disables 73 Repos in 105 Seconds

[00:03:44] Paul McCarty: Yeah, so one correction. Sorry. It happened on June 5th.

[00:03:49] Jenn Gile: Um- June 5th. Sorry. Time is weird.

[00:03:51] Paul McCarty: It's okay. No, this has been... You said this last episode, too, and it's true. Like, the, you know, it all blurs together now, for God's sakes. Um, yeah, so basically what happened is a total of 73 repositories just went dark on GitHub. Um, and as Jen said, the message that came up was saying, “Hey, we've disabled these re- repos for TOS,” terms of s- of service violations.

[00:04:16] I was asleep when it actually happened, um, but I got up soon thereafter. And a couple of people I know, um, actually grabbed snapshots of one of those repos before it got disabled, and it was pretty clear from the get-go that this was a Miasma worm attack. But there was a lot of people pushing, like, you know, I got some flack from- people about, you know, my blog post intimating- Mm-hmm

[00:04:48] that it's, it was, you know, the Miasma worm. In hindsight, it was, and, you know, I, I probably shouldn't have softened my blog post, but anyhow, I did, you know, to make people happy, which is never something I do normally. Um, but the point is that, um, uh, what happened is that the, the Durable Task, um, repo, um, had been affected, uh, in May, uh, I think it was May 18 even I

[00:05:15] Jenn Gile: looked it up earlier today. It was like mid-May. I'll drop- Uh ... the threat report while you're chatting.

[00:05:22] Paul McCarty: If I were to pull a number out, I think it was May 19 got done, and basically the assumption is that, um, in fact, Step Security goes so far as to say it happened, um, uh, that, um, the threat actors maintain persistence via, um, credentials they yanked in the first May 19 event, which then allowed them to come back on June 5th and do this.

[00:05:49] Now, basically this is Miasma worm, which is like a, you know, similar or based on TeamPCP's open source worm, and now there's a new version of it and, you know, yada, yada, yada. So that's all craziness is, in and of itself, but I think the thing that's more important here, 'cause this is the Microsoft show today, right, is that Microsoft still, I checked this morning right before this, still has not come out and officially said what happened, or even

[00:06:16] Jenn Gile: what- Yeah, it's very, like, gives GitHub vibes from when GitHub got done a couple weeks ago, right? Like, very quiet.

[00:06:25] Paul McCarty: You know, listen, Microsoft, if anybody from Microsoft is listening, you probably aren't, b- 'cause you probably know that, that, um, I'm here. But, you know, you continue to just shovel... I'm trying not to say any naughty words. You know, you're doing the bad thing, and you're making it worse and worse and worse, and I, you know, I don't know.

[00:06:44] I'm, I'm leaving GitHub, straight up. Like, I've already made the decision. We're leaving GitHub. Um, I wasn't using any Microsoft products to begin with. But this is just, this is just a crap show, and, um, I'm really disappointed, you know, with the behavior from the organization. Not that I should be surprised. But yeah, they still haven't come out with any official word about it at all.

[00:07:03] Jenn Gile: No. I saw a couple of quotes in, um, I think it was either TechCrunch or The Hacker News that allegedly came from somebody from Microsoft where they said that they, you know, looked through the repos, that, uh, most of them were unaffected. They say that they reached out to people who were affected, which I'm a little skeptical about, um, just given the way that these things work. I don't know that they necessarily know everyone who might have consumed this stuff, but maybe they do. Maybe they have a secret way.

[00:07:39] Paul McCarty: I, I think you said something earlier on that I need to come back and touch on, which is that this had significant impact. This had real impact because basically what happened is a number- Yeah ... so basically four GitHub organizations were affected, and one of those GitHub organizations was the Azure Functions, um, uh, GitHub repo. And s- there's specifically GitHub actions that run for Azure Functions that are ho- house- housed there, and those were taken down.

[00:08:06] Those were disabled. And so what that meant is if somebody was running a job that called the official Azure Functions, and there was like several of them, uh, GitHub action, it failed immediately. And so I started... 'Cause I was, somehow I was the first person to mention this publicly, and I started getting people immediately pinging me on all my comms channels saying, “Hey, what's going on?”

[00:08:29] You know, like, you know, I've mentioned this to some people I know, and they're like, “Yeah, welcome to tech support.” Yeah, and that's, that's really what it felt like. It felt like I was tech support for Azure Functions GitHub action- Mm ... and I didn't have any data to share. Like, it... Sorry, I have nothing to do with it. But yeah, that... It had real impact, and the fact that Microsoft hasn't said anything about that very real impact to actual CI jobs around the world, that is bad. Mm. Super bad.

VS Code Extension Auto-Update Cooldown

[00:08:53] Jenn Gile: Yeah. It's not great. Uh, maybe we'll come back to that. I wanna talk about miasma, but um, maybe that'll be a thing we tag on later. So the next thing, um, we saw an announcement about VS Code adding a two-hour cool down for, um, third-party extensions.

[00:09:15] So, uh, something that's of note here is third party, so that means it's stuff that's not owned by Microsoft. So little, uh- Area of concern there for me at least, uh, you know, if they get compromised, which we have seen them get compromised multiple times recently. So, uh, I think that there's a bit of a, a insinuation that first party is safe and you can consume it immediately, but third party will give you a two-hour auto-update cool-down period.

[00:09:51] Um, don't get me wrong, I think that this is a good step to have this as an option for people. Uh, I'll share the issue shortly, but it was requested in a VS Code issue by the community. A lot of people wanted it. You know, they cited a lot of the, um, attacks that have happened recently and said, “Hey, we really need this.”

[00:10:14] And like, if we diagnose why it's really needed, that's what also I think causes concern for us, is the reason it's really needed is because there's no real screening for these extensions before they get released into the ecosystem. It is very much buyer beware. Um-

[00:10:32] Paul McCarty: 100%.

[00:10:33] Jenn Gile: Yeah, so, um, it's good that there's a cool-down period. It's weird that it's two hours. That's definitely the shortest cool-down period I've seen. Uh, you know, when I talk to people in the community, anywhere from three to seven days is pretty average for what they wanna be seeing for their own internal practices. So this, like, artificial, uh, you know, choice for two hours is weird. It's not what the community asked for. They didn't specify a time, so questions there

[00:11:04] Paul McCarty: So many questions. Taken as a whole, this is just kind of an odd thing, and when we talk about the next part of this, which is npm, you know, it's the, the difference between the two and the discrepancy is very unusual.

[00:11:16] Because let's just, let... Or so a VS Code extension is really just a JavaScript package, right? It looks and feels exactly like an npm package. It has all the same kit. Um, it also has, in addition to having the dependencies that you typically have for an npm package, it al- also has these extension packs, which is a way to call another extension as a, as a dependency inside it. So it's got two planes of dependencies that you can call on. But it is strange that it's two hours. Um, uh, like I- that feels like, Jen, I'm gonna use another one of my military analogies here, but it feels like you put a helmet on and then you run into a minefield. Like- Mm ... I guess in theory it protects you to some degree, but it doesn't give you much protection.

[00:12:04] Um, it seems like a odd number. Um, I also think that they chose that number because they're doubling down on this idea, this primitive that, you know, velocity is everything for developers. And let's be clear, velocity for developers is the number one reason that we have this problem, right? This is why we're looking at cooldowns and all kinds of other stuff across the board is because we have over-incentivized velocity above everything else when it, you know, developing software.

[00:12:34] So it seems like a, a s- a weird number. I will say this, though. The VS Code Marketplace, um, is the one place where Microsoft seems to be fairly proactive around scanning m- um, extensions. It's... 'Cause they, they do. They, they remove things weekly from the VS Code Marketplace. Um, I know 'cause I track it. Um, and I, it seems strange to me too because, like, are they using the same technology that they use for npm? Because they sure aren't pulling anywhere near the same number of things and I, like, it just seems weird if it was-

[00:13:03] Jenn Gile: Well, and the timing is interesting. So I spent some time, um, I guess it must have been earlier this week, uh, rereading the, um, retrospective by NX on the NX Console VS Code extension, uh, compromise. Mm. Yeah. And I had misunderstood, and I think I misspoke, uh, on a previous version of this podcast that Microsoft had caught the malicious extension. That is not correct. NX caught it. The reason they caught it is, um, they had notification emails set up through VS Code Marketplace to say, to notify them any time a new version was public.

[00:13:46] And so one of the maintainers got an email and said, “Whoa, whoa, whoa, I didn't do this.” Uh, very quickly realized it was malicious, and it took them about 11 minutes to get it pulled down. Um- Interesting, because I wanted to understand the difference between that and OpenVSX. What they say about OpenVSX is that does not have an email notification system. They did not know that it also pushed there, and what they said in their retrospective was, and I'm sure we've all been there, um, the developer had an, “Oh, maybe I should check OpenVSX moment,” after they dealt with the VS Code Marketplace one, saw that it was there, and then manually pulled it down from that one also.

[00:14:33] And so that's why you have the time difference. Mm-hmm. So first off, knowing that this particular scenario happened because the vendor was proactive, not because of, um, any inherent scanning in the platform, but also the, um, dichotomy between VS Code Marketplace and OpenVSX. I did a little bit of poking around this morning because I thought, okay, you know, if this was a problem with that particular situation, you know, are these cooldowns gonna be applied to OpenVSX also? Uh, no indication that that will be the case. And so you know- Yeah ... we find edges with these things. I mean, is it surprising? No. But, um, I wrote a post earlier today that was kind of talking about how all these ecosystems that are sort of under the same umbrella are getting, um, security measures added to them, like, in silos. Like, you can almost see the org chart that's working on these things, rather than it being a- Right ... cross-organization initiative.

[00:15:34] Paul McCarty: Yeah, I mean, just from a purely, from, like, the artifact that you install perspective, you know, you- as you say, we have two different, not competing, but two different big VS Code marketplaces. We've got the Microsoft official one, and they're pretty, you know, proactive about pulling stuff down, and then you've got openVSX, which is run by the Eclipse Foundation, and they're not very proactive about pulling things down. In fact, they're not proactive at all. They do take things down pretty quickly, I think, when you...

[00:16:01] I- I've actually never disclosed to them, which is, it's, like, the only case it's like-

[00:16:05] Jenn Gile: Well, it sounds like from the NX situation that they did act quickly once they got a- Well- ... hold of these people ...

[00:16:09] Paul McCarty: and that's good. But, you know, there's al- there's- there's a number of small differences between the way that you publish things in openVSX and you do in Microsoft, which actually makes openVSX an even sexier target for bad guys.

[00:16:23] Now, what I was getting at here is you can also just host these VSXI files yourself and let people install them, right? So it has, it has a lot of the kinda same, you know, distribution problems that you have with AI skills, which is anybody can write an AI skill, skill.md, put it out on GitHub. People are gonna index looking for those. They're gonna suck it into all these different skills registries. And so suddenly now, you know, just by putting on a, on, on, uh, GitHub, you suddenly get this distribution channel. You don't have to do any- it's like a zero input distribution channel. It's perfect.

[00:16:55] Jenn Gile: Um- That's interesting. You and I haven't talked about that similarity before. That's, that's a lot to think about.

[00:17:01] Paul McCarty: Yeah. Well, and, and the Go ecosystem's like that too as well. Like, everything, every Go package is actually just a GitHub repo, and so, um, and this is actually, this is true in other ecosystems too as well. And I think this is the feeling, I, I feel like this is where more things are moving towards, which means that bad guys- Yeah

[00:17:17] have this kind of automatic distribution mechanism whenever they publish stuff there. It's crazy.

npm v12 Disables Install Scripts and Dynamic Dependencies

[00:17:22] Jenn Gile: Yeah. Okay. Third area on our list is the, um, NPM version 12 breaking changes, uh, notice that they put out, was it yesterday? I think it was yesterday afternoon. Um, they... This is a good thing. Let's not dance around it.

[00:17:42] But again, like everything that we've been talking about, there's, like, teeth Thorns, whatever metaphor you want. There's something pokey in it also. Um, so, you know, we've seen a huge amount of them, open source malware leverages these install scripts in npm. It's effectively an automatic installation method. That is why- RCE by design, right? RCE by design. You know, a lot of AppSec teams think about scanning for malware later in the life cycle, you know, when it hits, um, CI. But these life cycle scri- scripts, and install scripts specifically, are what makes the malware fire before it's gotten anywhere near your pipeline or production.

[00:18:26] Um, and so what they've done is they have disabled these by default, so they are now opt-in, or they will rather. Um, they say that this is gonna be coming in July, that it'll be a major breaking change. Um, they're not kidding. A lot of stuff is gonna break, uh- Mm-hmm ... if you upgrade to this new one. But I wanna talk about a concept that I think is really important in security, and it's certainly not limited to security. I learned about it long before I entered this field, and it is the concept of make the right thing easy, make the wrong thing hard. And they sorta did And didn't do that with this. They made the right thing easy by making it opt-in, which is something you and I have talked about a lot, is if you want people to adopt a security feature, don't make it a choice. Just have it turned on from the beginning. This is why we haven't seen a lot of adoption of capabilities like trusted publishing, because you have to do work to get it to work.

[00:19:31] Paul McCarty: Yeah.

[00:19:31] Jenn Gile: But on the same token, um, developers are going to need to turn, uh, opt in to these install scripts because a lot of the packages that they use simply won't function without them, and they're gonna- Yeah

[00:19:46] develop the bad habit of just opt-in, opt-out, opt-in, opt-in. So you've written a whole blog about this. Um- I have ... I really like what your, your thought process is here. So what do you wanna add in?

[00:20:02] Paul McCarty: Yeah, I mean, I think that first, like you said, I'm just gonna say it again because people see me as a hater, and I'm not a hater. These are all good changes. I first... I, I, like, I love the fact that they've c- they've tripled the, they've do- they've tripled down here in the sense that not only are they disabling the install lifecycle script, so post, pre, and install scripts, they're also disabling the Git, the direct Git, uh, the ability to pull dependencies via Git, and also the remote, um, tarball, um, method.

[00:20:32] Because when I first tr- heard people talking about this, I was like, well, the first thing the bad guys are gonna do is just pull, you know, dynamically from a URL or from a Git repo. And they're, they're, and they're addressing all three together, which is great. That's a very, uh, as, that's something to be commended. I mean, it's coming years, and years, and years, and years too late but, um, you know, the damage has already been done, I guess. But, um, you know, it is, it is a good thing. Um, so I think there's that.

[00:20:59] Jenn Gile: Yeah, at least it's not a partial fix. That's a good thing.

[00:21:01] Paul McCarty: Agreed. Yeah, and I was really surprised to see them tackle all three of those in one change. Uh, I thought that was great, I really, to be commended. So I think, and I say this in my blog post, I think there's this, especially f- in the InfoSec community, which frankly doesn't understand how the software sausage is made, right? They think that lifecycle scripts are only used by bad guys, and that's not true.

[00:21:25] And I point out like eight or 10, you know, popular packages that use install scripts. Um, and then there's also the native kind of, uh, JIP, you know, build that has become very popular as well, that requires that as well. So the reality is this will absolutely break production all around the world But here's the other thing is this re- this is, this is a, this isn't a registry change. This is a package manager change, right? So that means you have to update to version 12, 12.x on your local machine, whether that's your developer workstation or whether that's in your CI, to get, to be able to get this built-in security. And as we all know, just don't take my word for it. Go and look on GitHub and find, um, find the version of NPM that people are using in their, uh, GitHub actions, right?

[00:22:19] All around the world, and see what versions they're using. They're not typically using the most up-to-date versions. So this is gonna take months or years to actually kind of, you know, dribble out. Um, so there's just, you know, this is not gonna be this one-time kind of security existential change that I think people are calling it. It's not gonna be that

[00:22:39] Jenn Gile: at all. That's a great point. This will be a, a years-long slog. I mean, we see this all over the software ecosystem. Kubernetes made some major breaking changes a couple years ago. They recently discontinued Ingress-NGINX. There's a whole bunch of problems around that. Uh, we know that people, uh, choose not to upgrade or miss the message about why they need to upgrade for whatever reason. Um, the human just likes, you know, human brains like status quo, like opting into a change is always a barrier to adopting the change

[00:23:17] Paul McCarty: Yep. I mean, all we have to do, and I point this out in my blog post, is all we have to do is we, we just look at another ecosystem, which we've already talked about today, which is also owned by Microsoft, the VS Code ecosystem, and you look at what they did in VS Code 1 dot z- one, uh, sorry, 1.109, I think, came out in January of this year.

[00:23:33] Jenn Gile: Oh, you're talking about the, uh, task.json stuff?

[00:23:36] Paul McCarty: Yeah, where they disabled by default task.json running, the task files running automatically. Like, heaps of people still aren't running that version of the IDE. Like, so it's like, I, you know, I talked to somebody g- it would've been a few months ago, would've been, uh, in March maybe, but I talked to someone and it's like, he's like... I'm like, “What version of VS Code are you running?” He's like, “Oh, you, uh, some ridiculously old version.” I'm like, “Like, why?” And he's, “Oh, just, you know, I got all this stuff built in and I don't wanna upgrade.” And I'm like, “Okay, well.” There's still that kind of person too as well.

[00:24:13] Yeah, so these, you know, these are good changes. We wanna keep saying this. We wanna keep qualifying what we're saying as saying these are good changes. All things together, defense in depth and, you know, multiple controls, these are all good things. Yeah. But I do not think this is gonna be this like existential change, like no more malware in npm. I made the, the name of my blog post that, right? There's still gonna be heaps of malware in npm for years, even after this change rolls out.

[00:24:39] Jenn Gile: Yes, very true. Okay, we glossed over something that happened in, in the last week, and that was, uh, the threat actor behind Miasma, or Miasma, however you pronounce it, um, open sourced

Miasma Gets Open-Sourced

[00:24:55] Paul McCarty: it. It did.

[00:24:56] Jenn Gile: Right

[00:24:59] Paul McCarty: Well, and the person that open sourced it too, as well, does not appear to be a compromised user, and that's odd too, as well. So, um, with the TeamPCP open source, the, the assumption... Or, well, no, it's not the assumption. Basically the f- the fir- if you, if you tie this back, and if I get this wrong, Francois or somebody else will correct me and, and I'll, I'll come on the next one and say this, but I'm pretty sure the first, uh, event in the GitHub API for, for the o- for the TeamPCP open source repo was actually on a compromised user's account.

[00:25:36] Jenn Gile: Oh. So basically- Meaning the, the threat actor used a compromised user's account to publish it, yeah.

[00:25:42] Paul McCarty: C- correct. Um, and that was their, that's their model. And then, and, you know, and North Korea's doing that with Pollen Rider and GlassMoon as well, so- Yeah, it's

[00:25:50] Jenn Gile: just easier to, you know- Yeah ... obfuscate who actually did the thing.

[00:25:55] Paul McCarty: Right. 'Cause there's a lot of data in the GitHub API. I mean, they're, they're about to make it harder to get at, but there's a lot of data in the GitHub API that me and, you know, a lot of my friends, you know, use. Um, so anyhow, uh, fast-forward to Miasma, it appears that the person that open sourced the source code is not a compromised user. It appears that they're, like, a quasi security researcher. And so that's got me thinking, like, “Okay, what's going on there?” Um, so inquiring minds wanna know, and you know my- Yeah ... forensics is all over it. So, um, yeah, it's just, it was an odd thing.

[00:26:32] Jenn Gile: I'm looking forward to seeing how that resolves, for sure.

[00:26:37] Okay. Uh, I think we have a couple more, uh, miscellaneous topics. We've got a couple time, a couple minutes to talk about them. I think this might be a good time to talk about package firewalls. Um, we're hearing about it a lot from, uh, vendors right now. It seems like- Mm-hmm ... every other week, um, an AppSec or, um, you know, some kind of registry related vendor launches some kind of package firewall offering.

Package Firewalls Explained

[00:27:11] And I thought it would be helpful to people listening to kind of talk about what these are, how they work, how can you decide if you need one, how it's different from EDR. Um, I don't think we're gonna make a judgment here on whether they're good or not. Um, that's up to individuals to decide on. But essentially what it does is it enables you to block consumption from the developer machine of specific packages.

[00:27:41] And where this is, I guess, uh, the problem that it's seeking to close is all right, you don't have, um, an internal registry as your sole way of consuming open source. You've got some other way, you know, people can get around them even if you do have an internal registry. But you are looking to add a layer to make sure that people don't consume known or potential malware So let's start from there. Paul, what do you wanna talk about with these?

[00:28:19] Paul McCarty: Well, I think it's hilarious 'cause I, I was pitching this idea of, like, EDR for the developer back in 2023 and 2024, and nobody gave a doo back then, right? Now suddenly they're, they're all very popular. Listen, I think, to your point about us making a, um, a judgment, I think that, you know, package firewalls, um, are part of a quiver of tools that you would use to protect yourself, right? And so I think that having, um, the ability on a endpoint to, you know, uh, not install and, and have visibility around what is malicious and what's not is an important control. Um-

[00:28:59] Jenn Gile: And to be clear, a proactive control, not a, “Oh, shoot, it's there,” like EDR. Yeah.

[00:29:05] Paul McCarty: Correct.

[00:29:06] Jenn Gile: Would be the difference with EDR. EDR finds it after you've-

[00:29:10] Paul McCarty: Right

[00:29:10] Jenn Gile: invested. Yeah,

[00:29:11] Paul McCarty: EDR ain't helping you here. Like m- and standard EDR ain't helping you here. I think the is- there's a lot of issues with these package firewalls, because we, we lump them all in together. And, like, listen, uh, Lirin Tal wrote one of these things back in 2017, right? NPQ. Um, it's pretty simplistic, but, like, there's lots of examples of these. And, you know, Patrick Dwyer recently wrote something called, uh, Package Ward, which I think is cool. But they're... Basically, these fall into two kind of camps. Um, the first is the more simplistic camp, which all it does is create an alias on your machine that says, “If I call pip, if I call NPM, instead call this other a- this other tool,” and that tool will then make a call out via API or however it works.

[00:29:55] Some of them actually cache locally on the machine, which I think is a terrible idea. The problem with an API is it adds latency, and if you've got a big package manifest, you know, that adds a latency. But caching for malicious packages today, like, I just think is a bad idea- Not a good idea.

[00:30:09] Jenn Gile: Don't do that

[00:30:09] Paul McCarty: across the board, right? The problem with having that first example is that you don't have a process running, like, in user space saying... You know, just kind of running all the time, looking at these things. Instead, what you're doing is you're calling just in, at, at point in time this other app that says, “Hey, can I do this thing?” So you don't have this kind of daemon that's sitting out there checking to see, “Hey, what's calling pip? What's calling NPM?” And that's where the second category comes in. The second category comes in, some of the more advanced tools in this space actually run, effectively, a daemon that look at all calls out, right?

[00:30:43] And so this is where you start to- Excuse me, blend over into this proxy that you've got running. 'Cause many of these tools also run a proxy. They look for calls out to, you know, Pyhosted or, uh, npm JS registry and, and get, get in, in the stream, right? Um, so there's two kinda categories, and they, they, these two different kinda cate- categories have different outcomes.

[00:31:08] Um, a lot of these tools actually just use OSV and GHSA for their malicious package feed, um, which is not enough. I mean, that's the reason that, you know, we built OSM. Uh, we do have open source maintainers that are r- running some of these now, incorporating into OSM's feeds, which is great, but, um, yeah, I mean, you know, it's an important tool to use.

[00:31:31] Jenn Gile: Yeah, and I think there's, uh, a couple things to think about before you pick one. Paul, you've surfaced a couple of those. One is, what's the data source? Um, if you're gonna be paying a vendor to, uh, you know, license one of these things, then you wanna understand where are they getting their malware data, how fresh is it, um, what happens if it's a package that they haven't seen yet. You know, is there some kind of process to investigate that package before approving it? So understand that part of it. Um, the other one that you mentioned was the local caching, which kinda goes back to that freshness part. You know, if you're caching an older, uh, list of, you know, malware, then you're missing the most, I guess, uh, threatening possibility that it's an account takeover that's brand new, and you don't know about it yet, and you're in that short time window.

[00:32:27] Um- Yeah ... the third thing, and this may be... I don't know, you and I, I think, have slightly different opinions about this, but this is, uh, an individual's ability to get around it. Um- These are not, uh, I don't know. I don't know what the right silly security metaphor is. Um, this is a wall you can walk around if you wanna walk around the wall.

[00:32:52] Paul McCarty: Well, yeah. Yeah. Super, especially that- And that's

[00:32:54] Jenn Gile: just to understand that ...

[00:32:55] Paul McCarty: the, the first version where it's just basically what you're doing when you call pip or npm, you're just calling an alias. All you have to do, literally all you have to do to bypass that is just to call the absolute path on your machine where pip or npm actually lives, and you immediately bypass that control. It's that simple. Um, which I think is, you know, too simple because here's what's gonna happen is your developer's gonna be, “I wanna install this package,” and your firewall comes up and says, “Hey, that's a bad package.”

[00:33:23] Jenn Gile: Or

[00:33:23] Paul McCarty: it's slow. That person goes out... And, and... or it's slow. Yeah, exactly. Good point. It's slow. “Ah, this thing's slow. I just wanna install my thing. I just... I'm trying to run build. I'm in the process. Ah.” And so maybe, maybe some end percentage of the time that person gives a crap enough to go out and look up whether that package is malicious or not, and maybe they don't find anything. They see it's wrong, and so they just bypass the process and they just install it, right?

[00:33:47] It's, um, it's a very simplistic... And someone ex- explained to me why they were putting so much energy into it, um, saying, “Well, this is a trust mechanism with developers.” Uh, developers ins- are incentivized to build and deploy as quickly as possible, so if something gets in their way, they're gonna by- especially if it's as easy as just calling an absolute path to bypass something, they're gonna do that, right? Some end percentage of the time they're gonna do that.

[00:34:12] Jenn Gile: Yeah. So going back to if you decide you need one of these, um, you know, look at how easy it is to bypass. Uh, you know, it comes back to you can have a policy that says if you bypass it, there are job-related ramifications. You know, you can have the, the stick instead of the carrot approach, but you know, really just sort of understand it 'cause I think these do get treated a little bit simplistically.

[00:34:40] And with all that said, I do think it's gonna be still not the majority of organizations choosing to implement these, you know? I agree. And the reason I say that is because package... Uh, sorry, internal registries still are not a standard in the- the industry. And if we haven't gotten to the point where an internal registry is not the standard, then I think about the, um, you know, stakeholder engagement that is needed to get something like a package firewall rolled out in your system. You know, if you're having trouble getting a registry done, m- the firewall might be tricky also. All of that said, now's the time to ask, because like Paul said, you know, he had this idea years ago. Uh, when I first started working in the space years ago, nobody cared. Uh, nobody turned on the features that looked for malware.

[00:35:33] Uh, it's not 2023. Good news. Um, it's 2026. Yes, it is. Uh, and so most people understand at least why you wanna be looking for these. So, like, if this has been on your wishlist, like, yeah, now is the time to do it. You don't have to buy one. I know people who are building them, so you could look into building it yourself. It doesn't have to be a- Yeah ... you know, go buy it off the shelf. Um, but yeah. Go, go check it out. Go talk to people.

[00:35:58] Paul McCarty: Agreed.

[00:35:59] Jenn Gile: See what's possible.

[00:36:00] Paul McCarty: Agreed. Yeah,

[00:36:03] Jenn Gile: one of those- And actually, while I- One of those companies- ... am talking about this, there's a similar one. Uh, our friends over at GitGuardian developed, uh, an endpoint solution that lets you see what secrets are deployed on your developer machines. Whether you use something from GitGuardian or some other solution, that is the other side of the, the puzzle or whatever, you know, solution here.

[00:36:24] Paul McCarty: Yeah.

[00:36:24] Jenn Gile: You do need to know what's on those developer machines, both from a package perspective and a credential perspective. If you don't have those two things, then you're gonna be really behind when it comes to dealing with malware

[00:36:36] Paul McCarty: Agreed. I, you know, it's really interesting because 99.9% of, you know, NPM or, or PyPi-based malware is, are info stealers, right? And I don't know if that number is actually true or not, but it's, you know, it's in the, in the zone. Um, but because of that, understanding what credentials are on your developer machine is super important.

[00:36:59] And I actually s- I'm trying to think who it was. Somebody, somebody built a tool recently, and I'm just now, I'm, I'm... It's going out of my head. But basically, the whole intent of the tool... Oh, I know what it was. It's, um, Francois in Boost Security with, um, uh, with Bagel. Bagel basically actually runs on a developer's machine and says, “Hey, these are the credentials, and this is the stuff that's stealable here.”

[00:37:21] And I was listening to Francois on the Open Source, um, Security podcast for Josh, uh, Brussa's podcast where- Oh, I missed that episode.

[00:37:27] Jenn Gile: I'll have to check

[00:37:28] Paul McCarty: it out. Yeah, it's really good. Um, just came out. Um, and on that podcast, they were talking about the fact that, that the org that Francois was working for got popped. And at first, just mad respect to him for talking about that because it happens to all kinds of organizations and nobody talks about it. They actually, not only do they talk about it, but they went and built tools to, like, address it, and I think that's dope. Um, so yeah, Bagel is, the whole idea there is to, like, s- expose what's on the developer's machine.

[00:37:54] So now you know from an incident response perspective, oh, sh- oh, I almost did it. Ah, shizzle. You know, th- there's some bad stuff. The, the production AWS keys were on this machine, and they ran this info stealer, in this NPM info stealer. Oh, boy, we need to, we need to spend some time dealing with this.

[00:38:12] Jenn Gile: Okay. I found the podcast. I just dropped it into the comments. Uh, this is a great point for us to wrap up. We went a tiny bit long, but I think this was a good topic for us to dive into. So-

[00:38:24] Paul McCarty: I agree ...

[00:38:24] Jenn Gile: hope it was useful. Let us know if there's other, like, technologies that you want us to talk about. Um, again, we're not gonna necessarily make total judgments on... Well, I don't know. We might if we think, like, it really is snake oil, but I don't know that there are any that are necessarily that right now.

[00:38:42] Paul McCarty: Yeah, I don't know how much, how much snake oil there is, but there's a lot of things that people are describing overly simplistically, and I won't call out any of those vendors. But, you know, like, they, they talk about things like being silver bullets, and they're not, so.

[00:38:54] Jenn Gile: Yeah. Well, we are a skeptical industry. Uh, I think people do tend to see through that. But anyway, uh, this has been a good one. Uh, tune in next week, and have a good one.

[00:39:06] Paul McCarty: Number eight in the books. See y'all. All right. Thanks for listening, people. Appreciate it.