Jenn Gile 0:01

Hello, it is June 11th, and all everything in our prep doc is about Microsoft. And so I think this is just going to be the Microsoft episode, right?

Paul McCarty 0:15

Well, I mean a lot of them are the button. We talk about NPM and my and GitHub a lot. So it's I don't know if it's necessarily gonna be any different, but NVS 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.

Jenn Gile 0:33

So oh, I do love your AI images. I can't wait.

Paul McCarty 0:36

Stand by. Uh stoked.

Jenn Gile 0:41

I'm delighted. Okay, let's uh give a high level because unlike most episodes where we jump around topic-wise a lot, these are all like kind of interconnected. 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. Is that about sum it up?

Paul McCarty 1:17

Yeah, yeah, it does.

Jenn Gile 1:20

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 everyday 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. 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 want to start out with?

Paul McCarty 2:05

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 deeply entrenched.

Jenn Gile 2:14

Yeah, you don't live here, so you you haven't lived with the uh the blowback of living in the the Amazon community.

Paul McCarty 2:21

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 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 want to tackle these in? Well, we might as well do the the repos thing first. Um, yeah.

Jenn Gile 2:48

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. 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.

Paul McCarty 3:44

Yeah, so one correction, sorry, it happened on June 5th.

Jenn Gile 3:48

June 5th. Sorry, time is weird.

Paul McCarty 3:50

It's okay. No, this has been you said this last episode too, and it's true. Like, 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 repos for TOS terms of service violations. Now 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 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 the durable task um repo um had been affected uh in May, I think it was May 18th.

Jenn Gile 5:15

I looked it up earlier today, it was like mid-May. I'll drop the threat report while you're chatting.

Paul McCarty 5:22

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 persistent that the the the threat actors maintained persistence via um credentials that yanked in the first May 19 event, which then allowed them to come back on June 5th and do this. Now basically, this is the Myasma worm, which is like uh you know similar or based on Team PCP'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, because 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 yeah, it's very like gives GitHub vibes from when GitHub got done a couple weeks ago, right?

Jenn Gile 6:22

Like very quiet.

Paul McCarty 6:25

You know, listen, Microsoft. If anybody from Microsoft is listening, you probably aren't because you probably know that that I'm 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. 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.

Jenn Gile 7:03

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.

Paul McCarty 7:39

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 of so basically four GitHub organizations were affected, and one of those GitHub organizations was the Azure Functions um uh GitHub repo. And there's specifically GitHub Actions that run for Azure Functions that are housed housed there, and those were taken down, 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 because 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? And 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, 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. Super bad.

Jenn Gile 8:53

Yeah, it's not great. Uh, maybe we'll come back to that. I want to 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 cooldown for um third-party extensions. 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 uh 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. 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 uh 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. 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 100%. 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, uh, anywhere from three to seven days is pretty average for what they want to 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.

Paul McCarty 11:04

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 because let's just let our 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 all 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, I guess in theory, it protects you to some degree, but it doesn't give you much protection. Um, it seems like an 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. So it seems like 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 um extensions, it's because they they do, they they remove things weekly from the VS Code marketplace. Um, I know because 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.

Jenn Gile 13:03

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. 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 anytime a new version was public. 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 open VSX. What they say about Open VSX is that it 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 Open VSX 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. And so that's why you have the time difference. 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 Open VSX, 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 going to be applied to Open VSX also? Uh no indication that that will be the case. And so, you know, 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 cross-organization initiative.

Paul McCarty 15:34

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 I I've actually never disclosed to them, which is it's like well, it sounds like from the NX situation that they did act quickly once they got a hold of these people, and that's good, but you know, there's all there's there's a number of small differences between the way that you publish things in open vs and you do in Microsoft, which actually makes OpenVSX an even sexier target for bad guys. 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 kind of same you know distribution problems that you have with AI skills, which is anybody can write an AI skill, skill.md, put it 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 out an on uh GitHub, you suddenly get this distribution channel, and you don't have to do anything, it's like a zero input distribution channel, it's perfect.

Jenn Gile 16:55

That's interesting. You and I haven't talked about that similarity before. That's that's a lot to think about.

Paul McCarty 17:01

Yeah, well, and and the Go ecosystems 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 feel like this is where more things are moving towards, which means that bad guys have this kind of automatic distribution mechanism whenever they publish stuff there. It's crazy.

Jenn Gile 17:22

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. 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 lifecycle, you know, when it hits um CI. But these lifecycle scripts and install scripts specifically are what makes the malware fire before it's gotten anywhere near your pipeline or production. 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 if you upgrade to this new one. But I want to 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 sort of 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. 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 develop the bad habit of just opt-in, opt-in, opt-in, opt-in. So you've written a whole blog about this. Um I really like what your your thought process is here. So, what do you want to add in?

Paul McCarty 20:02

Yeah, I mean, I think that first, like you said, and 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 they've tripled the they've done they've tripled down here in the sense that not only are they disabling the install lifecycle scripts, 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 uh method. Because when I first heard people talking about this, I was like, well, the first thing that 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 that's 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.

Jenn Gile 20:57

Um, so I think there's yeah, at least it's not a partial fix. That's a good thing.

Paul McCarty 21:01

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 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. And I point out like eight or ten 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 this 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 versions of NPM that people are using in their uh GitHub actions, right? 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 going to 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's a great point.

Jenn Gile 22:40

This will be 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 engine X. 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.

Paul McCarty 23:17

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 one dot zorg 1.109, I think came out in January of this year.

Jenn Gile 23:33

Oh, you're talking about the uh task.json stuff.

Paul McCarty 23:36

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, it would have been a few months ago, it would have been out in March, maybe, but I talked to somebody, I was like, he's like, I'm like, what version of VS Code are you running? Like, oh, you uh some ridiculously old version. I'm like, like, why? And he's oh, I just you know, I got all the stuff built in and I don't want to upgrade. And I'm like, okay, well, they're still that kind of person, too, as well. Yeah, so these, you know, these are good changes. We want to keep saying this, we want to keep qualifying what we're saying as saying these are good changes, all things together, defense and depth, and you know, multiple controls, these are all good things, yeah. This like existential change, like no more malware and npm. I made the the name of my blog post that, right? There's still gonna be heaps of malware and npm for years, even after this change rolls out.

Jenn Gile 24:39

Yes, very true. Okay, we glossed over something that happened uh in the last week, and that was uh the threat actor behind miasma or miasma, however you pronounce it, um, open sourced it.

Paul McCarty 24:55

They did.

Jenn Gile 24:56

Right.

Paul McCarty 24:58

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 team PCP open source, the the assumption, or well, no, it's not the assumption. Basically, the the first if you if you tie this back, and if I get this wrong, Francois, 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 open for the team PCP open source repo was actually on a compromised users account.

Jenn Gile 25:36

Oh, meaning that the threat actor used a compromised user's account to publish it, yeah.

Paul McCarty 25:42

Correct. Um, and that was their that's their model. And then and you know, and North Korea is doing that with Pollen Rider and Glass.

Jenn Gile 25:49

Yeah, it's just easier to you know obfuscate who actually did the thing, right?

Paul McCarty 25:55

Because 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 want to know, and you know, my forensics is all over it. So um yeah, it's just it was an odd thing.

Jenn Gile 26:32

I'm looking forward to seeing how that resolves for sure. 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 every other week, um, an appsec or um, you know, some kind of registry-related vendor launches some kind of package firewall offering. 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. 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 want to talk about with these?

Paul McCarty 28:19

Well, I think it's hilarious because I I was pitching this idea of like EDR for the developer back in 2023 and 2024, and nobody gave a do back then, right? Now suddenly they're very popular. Listen, I think um to your point about us making a um a judgment, I think that you know packaged 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 an endpoint to you know uh not install and have visibility around what is malicious and what's not is an important control.

Jenn Gile 28:59

And to be clear, a proactive control, not a oh shoot, it's there like EDR.

Paul McCarty 29:10

Right. Yeah, EDR ain't helping you here, like standard EDR ain't helping you here. I think the issue there's a lot of issues with these package firewalls because we we lump them all in together. And like listen, uh Liran Tall 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 this other tool, and that tool will then make a call out via API or however it works. Some of them actually cache locally on the machine, which I think is a terrible idea. The problem with an API is that 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 not a good idea. Don't do that across the board, right? The problem with having that first example is that you don't have a process running like in user space thing, 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 a 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, look at all calls out, right? And so this is where you start to excuse me, blend over into this proxy that you've got running. Because many of these tools also run a proxy, they look for calls out to you know, pod hosted or uh npmjs registry and and get in in the stream, right? Um, so there's two kind of categories, and they they these two different kinds of categories have different outcomes. 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 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.

Jenn Gile 31:31

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 want to 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 kind of 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. Um, 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 want to walk around the wall.

Paul McCarty 32:51

Well, yeah, yeah, it's super especially to understand that. 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 is gonna be, I want to install this package, and your firewall comes up and says, Hey, that's a bad package. Or it's that person goes out and and or it's like, yeah, exactly. Good point. It's like, oh, this thing's slow. I just want to install my thing. I just I'm trying to run build, I'm in the process. Oh, and so maybe, maybe some n 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 and think, see, it's wrong, and so they just bypass the process and they just install it, right? It's um it's a very simplistic, and someone explained to me why they were putting so much energy into it, um, saying, Well, this is a trust mechanism with developers. Uh developers are incentivized to build and deploy as quickly as possible. So if something gets in their way, they're gonna buy, 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.

Jenn Gile 34:12

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. Because I think these do get treated a little bit simplistically. And with all that said, I do think it's gonna be still not the majority of organizations choosing to implement these, you know. And the reason I say that is because package, uh, sorry, internal registries still are not a standard in 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, 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 look for malware. Uh, it's not 2023. Good news. Um, it's 2026. Yes, it is. Uh, and so most people understand at least why you want to be looking for these. So, like, if this has been on your wish list, like, yeah, now's 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 uh, you know, go buy it off the shelf. Um, but yeah, go go check it out, go talk to people, agree, see what's possible.

Paul McCarty 36:00

Agreed.

Jenn Gile 36:01

Yeah, one of those puppies talking about this. There's a similar one. Uh, our friends over at Git Guardian developed uh an endpoint solution that lets you see what secrets are deployed on your developer machines, whether you use something from Git Guardian or some other solution, that is the other side of the the puzzle or whatever you know, solution here. 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.

Paul McCarty 36:36

Agreed. I you know it's really interesting because 99.9% of you know npm or or pipie based malware is in 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. And I actually I'm trying to think who it was. Somebody somebody built a tool recently, and I'm just now I'm um 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 and 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. And I was listening to Francois on the open source um security pocket for Josh's pressers pocket. Oh, I missed that episode. I'll have to check it out. 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 I first just mad respect to him for talking about that because it happens to all kinds of organizations, 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 expose what's on the developer's machine. So now you know from an incident response perspective. Oh shoot, oh, I almost did it off shizzle. You know, there's some bad stuff. The the production AWS keys were on this machine and they ran this info stealer, yeah, this NPM info stealer. Oh boy, we need to we need to spend some time dealing with this.

Jenn Gile 38:12

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 I agree. 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 what 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.

Paul McCarty 38:42

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 talk about things like being a silver bullets and they're not, so yeah.

Jenn Gile 38:56

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.

Paul McCarty 39:06

Number eight in the books. See y'all. Thanks for listening, people. Appreciate it.