Jenn Gile 0:01

Hello, it is Thursday, July 9th. Uh, I've got my afternoon coffee. I had a little late today. I was running a little slow. How are things with you, Paul?

Paul McCarty 0:14

Yeah, good, good. I'm trying to find the um the LinkedIn um event so I can re-post it saying we're we're live now. I was about to say we're going live, but now we're here. We're here.

Jenn Gile 0:22

We're live. It's happened. Story.

Paul McCarty 0:25

Oh my god, this week has been so freaking busy and it went so quick. Oh my gosh.

Jenn Gile 0:29

You were up uh in Brisbane last night, is that right? At the Wasp chapter meeting. What was your talk on?

Paul McCarty 0:37

Yeah, it was on like hunting threats, adversary threats in in GitHub. Um, and the great thing is that we actually had some people from GitHub there and Microsoft there. So um I did not I did not um uh modulate my comments uh based on their presence. Um but uh yeah it went really well and it's it's basically a teaser. So I tried like the first half of the talk, Jen, was like just introducing people to this idea of the two software you know threats, like the vulnerable you know threats, which OWASP is the OWASP top 10 is there to address. And then this other risk that we're not really talking about that app sec tools don't help you with, which is you know the intentionally malicious threat, right? Um, introducing that, and then I segued eventually into like finding hunting in real time in front of people, actual DPRK threats in GitHub. And I have a lot of those because we found you know 2500 pollen writer, which we'll talk about later, but like, oh my gosh, there's just so much material, so much canvas.

Jenn Gile 1:38

Yeah, well, a little teaser. This is the same topic we're doing a workshop on uh at DEF CON. So if you're gonna be at DEF CON, uh definitely come check it out. I don't think the schedule has been released yet for the adversary village or the appsec village, but we'll be in those uh one really observation about that really quickly.

Paul McCarty 1:56

Somebody drove down from the Sunshine Coast all the way down to the to Brisbane, which is like only like an hour, hour and a half or something, but they couldn't get into the building because you know it's it was at the octopus deploy headquarters. So I really feel bad. John, I'm sorry that happened to you, mate.

Jenn Gile 2:09

Um, you know, we're we're gonna address it for next month's yeah, those are always tricky when you have the host have uh strict security. Um I've definitely listened to that before.

Paul McCarty 2:20

I'm gonna post about it on LinkedIn just as a heads up. Post somebody at the front door, right?

Jenn Gile 2:26

All right. So uh I think we have a couple of quick hits, and then as we've been talking about for a couple weeks now, we're gonna have an extended interview with the head of security, uh, Mikhail Barbaro from OpenVSX. But first are quick hits. So, Paul, we published two pieces of research this week, right? Um, the first is about the Paul and Writer campaign. This is a Lazarus group North Korean uh campaign that you discovered earlier this year that's kind of a a little bit of a spin-off of Contagious Interview that's more focused on taking over GitHub repositories. But what I think is super interesting about the research that you published this week is about how it is jumping to package ecosystems without any additional effort on the part of the um the threat actors. So maybe just talk like a paragraph, right? Real quick. What is it? I know I'm I'm telling you to be brief.

Paul McCarty 3:27

This is the difficult one. Okay. Pollenwriter is basically North Korea, has automated uh when they compromise developer victims, they basically automatically push malicious packages into all the repos that person has access to them locally. Uh initially that was just a GitHub thing. That's what we found earlier this year. But now in the um Go and PHP ecosystems, uh those registries, packages and um the Go registry, they ship packages that are GitHub repos. So now what the jumping the fence is these repos automatically become packages inside those ecosystems, which is crazy. You know, you don't have the same additional authentication that you do in in npm and pipy and some of the other ecosystems.

Jenn Gile 4:12

Nice. I uh am dropping the link to that uh in the chat. And then why don't you talk a little bit about the second piece of research um on a cybersecurity startup that you discovered publishing info steelers to NPM? And like I'm just gonna editorialize for a moment. I get really irritated when vendors do um call it shady, call it borderline, whatever you want to call it. Um things illegal in some places, right?

Paul McCarty 4:48

Sorry, it's illegal in some places, right?

Jenn Gile 4:51

Or illegal things, yeah, to manipulate the market. And we don't necessarily know why this vendor chose to do this, um, but talk a little bit about what you found.

Paul McCarty 5:02

It's funny how many of these come from the same ecosystem. But anyhow, um, the the reality is that this is a common practice we see with certain cybersecurity startups. Basically, what happens is to make a name for themselves, they do a bunch of um, you know, they publish malicious uh VS Code extensions or malicious NPM packages or whatever the case may be, and then they use their publishing of that data to kind of prove the point that you need the solution that they're hawking, right?

Jenn Gile 5:29

Um, and uh like to get a little dramatic, this is like setting fires and then being like, oh, you need my like new sprinkler system.

Paul McCarty 5:38

Yeah. These particular info stealers in these particular seven info stealers are really unusual in the sense that the author went to great lengths to not actually steal. For example, it ganks everything in your.ssh uh uh uh.ssh folder on a Linux box or a Mac box, you know, everything in your.aws folder except the the credentials file or except the actual PEM uh SSH keys. So they're they're going out of their way to not actually gank the, but then they take everything else. Now the problem is that you can actually put credentials in config files in a AWS directories, for example. So it's not it's not a perfect delineation, but the fact that the author went through so much trouble to do that, but then just stole all this stuff, right? Like there's that the amount of data that they these info stealers steal is the point of it is to get seven different data points, it's an absurd amount of data. And when you tie all those things together, 11, not seven. Yeah, yeah, it's a really strong identity graph of who that person is, what they do, what the name of their machine is, all this stuff, which you can then use later on as part of your data set for whatever thing you're trying to hawk. Um, so we called it L.

Jenn Gile 6:45

Very likely this, uh, like you said, violates some laws. I wouldn't be surprised if this had some kind of a GDPR impact, but um, you reported the um publisher and the packages, they have all since been taken down. So the person who did this uh has lost their npm account, which you know what, good. Um I don't like to see this kind of behavior.

Paul McCarty 7:11

Yeah, and oh I was gonna say a second ago, there's something important there that now um God, I'm getting old now, Jen. Um something there about the npm packages. Oh well, I'll remember later on to jump in.

Jenn Gile 7:24

So this kind of segues into um one last thing before we hit on open vs. And that is a lawsuit that we found out about uh recently. It was filed, I think, last week. Um a startup called Meeting TV has uh taken Palo Alto Networks to court over um something KOI Security did. KOI is a company that Palo Alto Networks acquired earlier in the year. This is some actions that happened to KOI before the acquisition happened. But essentially KOI published a blog about a campaign and listed this company meeting TV's domain as at the very top of their C2 infrastructure, like IOCs list. And um, as a result, uh, you know, this company said that they got blocked by a whole bunch of, you know, people who use their product. They lost revenue, you know, lots of lots of issues with this. But the um important takeaways here are first of all, uh it was not a malicious domain, it was a safe domain. Um, so KOI security made a mistake in publishing this domain as an IOC and what this lawsuit is alleging. And I'm gonna be like very interested to see how the um court case goes because it's alleging basically um irresponsible use of AI. That um, you know, they're alleging that COI used AI in their analysis and that it hallucinated the involvement of Meeting TV's uh domain and that they didn't validate it. So KOI has since uh removed that domain from the IOC list in the blog. They updated it back in February or so. Um, but you know, reading between the lines here, probably, you know, Meeting TV initially wanted some kind of a payout for it, didn't get it, and has taken them to court.

Paul McCarty 9:29

Yeah, and I suspect right now, if you were to search Google, sorry, not Google, GitHub for that domain, you would find it in lots and lots of people's block lists still, because this is the problem, right? Once it gets out there, people suck it in. Yeah, Koi can remove it, but then everybody else that's pulled it from Koi, they're not removing it, and that's what's actually blocking you. So this is like a this is a supply chain of in reverse, you know, when you block something, the supply chain of of of hosts that you're allowed to go to, that's a difficult thing to unwind, man. You you know, and it comes back to my metaphor, you know, it's a lot easier to not pour to stop somebody pouring them the poison into the water supply than it is to try to take the poison out of the water supply.

Jenn Gile 10:10

Yeah, and to your exact point, uh, in one of the articles that I read about this, they said both Verizon and Palo Alto networks themselves are still blocking this domain. So yeah, it yeah, it's very hard to unwind it once it happens. That's why we uh really make a serious effort not to publish false positives.

Paul McCarty 10:32

Okay. And but real quick, real quick, real quick. We want to talk about this in a later, we want to talk about this at a later date, but this is evidence of something we're seeing everywhere, which is that people are shipping directly out of AI into their blog posts and into their finding lists and into all kinds of stuff, right? And the problem is that gets out there and that gets disseminated, and then people suck that in, and then you're poisoning these things. So we as an industry have to get better. Everybody thinks that they're an expert now because they got claw and they got codex spitting this stuff out, but you have a responsibility when you generate the stuff with AI to make sure that what it's saying is legit and true. And if it's not, then you are personally well, I'm gonna say it you might be personally liable.

Jenn Gile 11:13

Yeah, and I guess the last part of the rant that I'll add to this is we talk a lot in this industry about the harm false positives cause to a security team's reputation with developers, and that is all legitimate. That is a problem, but this is you know, kind of the uh upstream impact of it of when you publish a false positive, you can ruin someone's life. So, like this is a responsibility we should take really seriously. Okay, and rant. Um, we're gonna do something we have not done before, and that is uh we have our first guest. Um, I pre-recorded this interview because our guest is based in uh France. And the the way that the world is shaped doesn't make that time zone very friendly for when we record this uh podcast. But here's the story of how we ended up getting our first guest. Uh, we did an episode maybe a month ago or even longer where we talked about uh a malicious uh VS Code extension for the Inex console extension that was published in both VS Code and OpenVSX. This is the extension that was consumed by somebody at GitHub and then enabled team PCP to gain access to several thousand of their repositories. Um we actually had someone from Eclipse Foundation reach out uh after that episode aired and said that they would love to have their head of security come and talk with us about what they're doing at OpenVSX so that the community kind of understands how that ecosystem is different and what the security measures are. And uh we jumped at this opportunity because it's not often that we get um the registries you know out talking to us about their security practices. And so what I'm gonna do is I'm gonna go ahead and uh play the interview. Paul and I will be here hiding uh behind the scenes. We'll still be in the chats, and then we'll pop back in and kind of talk about uh the conversation afterwards. All good, Paul?

Paul McCarty 13:20

Yeah, let's do this. I'm gonna go and unmute.

Jenn Gile 13:22

Bear with me, everyone, because I have to hide us and then I have to uh bring the video in, and it's like five clicks. Thank you for taking some time today to talk to the community about what's going on at OpenVSX. But before we get into that, tell everyone who you are. What do you do?

SPEAKER_03 13:46

Thank you first for having me. I'm really glad to chat with you. So I'm Mickael Barbo, I'm head of security at the Eclipse Foundation. I use the team at the foundation that initially the mission was to help our projects to improve their security posture. And we moved to also head the OpenVS X team to secure the registry. And now we are even involved on the AI assisted Vinality Discovery with our recent partnership or participation to the project glass wing from Anthropic.

Jenn Gile 14:11

I saw in your LinkedIn background, you've been with Eclipse for several years. Seems like you came from more of a software engineering DevOps background.

SPEAKER_03 14:21

Yeah, correct. Yeah, I've been with the EQ Foundation for 11 years now, so quite a while, and I changed the role a couple of times. So I started software engineering as my background, so strong focus on supply chain security. And when we started this team to actually focus on supply chain security, that's how I grew up and I should get this role. So that's also one of the reasons why I'm still at the foundation. Is those opportunity to grow. That's a great place to work.

Jenn Gile 14:44

Yeah, that's and I always like seeing people who used to work on the code and the pipelines now responsible for securing them because I think you have a little bit more of an internal understanding of how it works. Why don't we start with telling the audience what is the Eclipse Foundation?

unknown 15:02

Yes.

SPEAKER_03 15:02

So the Eclipse Foundation is an open source software foundation. So we are a nonprofit organization. We hosting open source projects. So we are headquartered in Europe in Brussels. We used to be incorporated in the US, but five years ago we moved entirely to Europe. So we are the home of more than 420 projects. So many of your listeners probably know the well-known Java ID from 25 years ago, but now it's only a minority of our projects. It's 20 to 25 of our projects, and the 300 or 400 others that are in a widely diverse ecosystem. So we have projects on software defined vehicles, we have IoT projects, it is Mosquito, it is PAHO for MQTT runtimes. We have also, of course, still Java developer tooling, sorry, with at least Chick and others. We have many projects in many diverse ecosystems.

Jenn Gile 15:55

Yeah, and certainly not the least of which is OpenVSX. At this point, where does it fall in terms of popularity amongst the Eclipse Foundation projects? Is it on the higher end?

SPEAKER_03 16:08

Yeah, definitely. So OpenVSX started a bit weirdly or a bit as a niche for sure. So OpenVSX started in 2019 from one of our member companies to provide an extension marketplace to their cloud IDE called Etiphtia, because this supports extensions with an NPI compatible with VS Code. And given that the Microsoft Digital CEO marketplace does not allow any other IDE to consume extensions from this marketplace, they have to create something. So that's how OpenVS6 was born now seven years ago. And we started to run it as a bit later in 2020 or late 2020.

Jenn Gile 16:48

It's changed a lot in the last one to two years.

SPEAKER_03 16:52

Yeah, exactly. So the rise of all those VS Code forks. So you think about Curse ID and Project Bob, uh, Google Anti-Gravity, they are all either fork of Microsoft VS Code or VS Code compatible IDs. So they can consume extensions, the same extensions as because of Visual Studio Code. And so they all perform OpenVSX because of course they need a place to consume their extensions. So we switched from a niche project, a niche service for one of our own projects to basically becoming critical infrastructure for the AI assisted development IEs of the world.

Jenn Gile 17:24

Yeah, that's a big change. I want to definitely talk about how your team has been working on OpenVSX security, but just broadly, what has it meant for OpenVSX to become the extension marketplace of choice for AI developers?

SPEAKER_03 17:41

So our first so big community critical infrastructure raised a lot of challenges. The first one being, of course, the infrastructure needs, the number of requests, the bandwidth requirements. So we moved from a couple of thousands of requests per second at peak time to uh exceeding 2,000 or 3,000 million. Now we also have 300 million. Last uh April we were at 300 million downloads per month. We switched to 600 million in May, and we're expecting to pass the billion downloads per month by the end of the year for sure. So we are really on the infrastructure. Exactly. So similarly, the number of extensions that we received, the number of publishers that publish those extensions to the registry just increases exponentially. So managing this exponential growth has been a challenge. We had some hiccups as any infrastructure would expect to have when with similar growth. But yeah, that that has been one of our main focuses stability. But of course, this growth we noticed it, but of course, threat actors also noticed it because we became a good place to be and a good place to distribute malware. So that's where we had also to upper game because initially, when we had only a couple of hundreds of extensions from well-known and um good acting people, that that was not an issue. But now many choice actors are publishing malware.

Jenn Gile 19:01

Yeah, so before we get into that, I I didn't warn you I would ask this question, but it occurred to me while you're talking. Do you know off the top of your head what the average number of extensions getting published are on OpenBSX now?

SPEAKER_03 19:15

We have about 1200. Yeah, 1200 extensions. We may be at 1500 now. I don't know about the latest. Sorry, two 12,000th to 15,000th, one five thousandth extensions right now. That's I don't have the latest number at the end, but and we have more than eight thousand publishers as well.

Jenn Gile 19:33

Yeah. So the Eclipse Foundation is similar to other foundations like OpenSSF and the Linux Foundation, and that the community is driving this growth. You shared with me before that part of the reason that you were able to expand the security function is through investments from the community. Can you talk a little bit about what that, why Eclipse got money?

SPEAKER_03 19:56

Yeah, sure. But before that, maybe I just would like to re-explain when we talk about OpenVSX, we talk about three things. And the funding comes from this Trinity. So we have the open source projects. So we run the open source projects just like any other open source project like the foundation. That's where the code contributions are made and where anybody can actually tell the code and run their own instance. There is OpenGSX, the service that we run, and that we scale to the numbers that I just listed earlier. And then we have the working group that has been funded more recently, uh 2023, to actually uh drive and steer the services. So the initial goal was to have this working group to fund the development and the support of the service, but the scale of the group has been outsizing our hope. That really was really beyond any of our imagination initially. So we had to find other mechanisms to fund the development and the security of the project. So we still have the working group, and many of the vendors that support OpenVSX are members of the working group. We also had support from Anpha Omega, the OpenSS project managed by Google, AWS, and Microsoft to help us improve the security posture of the code base. And finally, we had this new initiative to create what we call OpenVSX manager registry. So it's for all the Google Antigravity, AWS Hero, Project Bob, and cursors of the world to provide them with SLA and the malware detection, I mean malware detection, and various services. Just any company building critical service will to have when they rely on critical infrastructure. And this those combinations of funding and the treaty of uh what is OpenBSX really help us sustain all those entities separately and with evolvement from the community.

Jenn Gile 21:48

That's great. Now that you have some funding and support, what's your team been working on to improve the marketplace?

SPEAKER_03 21:56

Yeah, so of course the first thing was to be Stable, stable keep the light on initially that that was our main focus, and very quickly we focused on security. And the the our priority there was definitely to have a pre-published security scanning. So that's something that has been missing from OpenDSX in day one. But with the numbers of um of publishers and flat actors noticing OpenGSX, we had to add that. So that has been the priority end of 2025, deployed early 2026. Initially, we ran only as a monitoring mode, so we were not flying anything, or we were flighting it only for internal use so that we can trick the knobs until we reach the proper level of findings. And then finally we turn it on. So basically, now for every publication, there is a before it's actually an extension is actually available for download, there is a scan being run. And if there is something suspicious, then it is quarantine and there is a human review, a human in the loop there to review the extension.

Jenn Gile 22:54

Yeah, that sounds very similar to how a lot of people implement tools within their own companies, right? Don't turn it on until you're confident it's not going to spit out a bunch of false positives and break pipelines.

SPEAKER_03 23:06

Yeah, exactly. False positive is really something that's cars. We don't want to re repulse publishers. We want to still accept the good publishers. So tweaking the knobs to reduce the false quality rate is really hard and a big focus of continuous improvement, of course.

Jenn Gile 23:20

Yeah, I think Oh, sorry, go ahead.

SPEAKER_03 23:23

That was our initial focus, but we've also did a couple of other improvements. So for instance, we had a lot of issues with tokens. So initially, we don't have any token expiration. Again, it was really a niche project. So the security posture was aligned with the expectation from such a project, but now we we had to have a game, so we re-overhaul the old security posture of the tokens where there are no limited lifetime exploration. We also have scanning. So many of our publishers initially were including their tokens, their publishing tokens in their extensions. That yeah, it happens.

Jenn Gile 23:56

Hard coded into their, yeah. Yeah.

SPEAKER_03 23:58

So it they were shipping us the their tokens. So of course anybody who was downloading their extension had access to their tokens. So we had to revamp all of this and do token revocation, token identification at publishing time so that we protect our publishers and we protect our continuous from supply chain attack.

Jenn Gile 24:14

Yeah, I want to hear more about how the malware scanning detection works, but this kind of prompts a question. A lot of the ecosystem is dealing with what you're dealing with right now. Um, I'm sure you follow the changes that are getting implemented in places like NPM, um, you know, with uh being able to mass revoke uh, you know, other features that are, you know, to your point, maybe a little overdue. What are the things that you kind of see as like the major uh changes that need to be happening so that these systems are a bit more uh trustworthy?

SPEAKER_03 24:52

So the we don't do that alone. We rely on the Ku ET as one to help us. Again, it's an open source project, and anyone can look at the code and see what we are doing. Of course, we some of the malware scanning, the rules are not necessarily all of available. We don't want to name the recipe to or any malware, any malware creator to to find whether they will pass or fail the detection. But for the detection part, what we created is the security recognition, security researcher recognition program, so that we recognize and we create uh we created badges to recognize security researchers who help us improve the detection and uh to report to us my well that they detect and we didn't detect it yet. And so we work with them to improve our detection on a continuous basis. So that that that's something that is super helpful. And the roadmap for improving the detection is really tied to those contributors. And we have a page on the where we list all the contributors. I can I guess you we can add some links to this podcast.

Jenn Gile 25:49

Yeah, I saw that while I was doing some research. I'll add it to the show notes.

SPEAKER_03 25:53

Excellent, thank you. But we so the the plan for this is uh really tied to contribution from the community, but we also have other plans. So, for instance, we've already started to harden the the namespace and publisher verification. So, of course, that there are still a lot of attacks on the typosquatting or namespace squatting, and uh people who try to copycat popular extensions, not necessarily by typos typosquatting, but still the the revis are very similar. I use the same icon and so on. So all of those detections that they are in the pipe and we are deploying them on a regular basis.

Jenn Gile 26:30

Yeah, so let's start really basic. I want to publish an extension on OpenVSX. What kind of vetting do I have to go through as a publisher so that you can make sure when I publish something, I'm maybe a more credible source? And there's been complaints about other ecosystems that allow for publisher accounts to be very new, to not have a lot of identity validation. What are you looking for when you onboard new publishers?

unknown 26:59

Yeah.

SPEAKER_03 27:00

So the very first thing that we have to do is to sign a publisher agreement with us. So we don't necessarily verify the identity of the signature of the people who signed this agreement, but that's something that set the ground rules. What you can do at OpenBSX and what action can we take if you violate those rules. So that's the first thing. And it's not necessarily something that you have everywhere to have this publisher agreement up front. So we are really really focusing on that. We think it's really important to have that first. Then you if you publish from GitHub, for instance, you are allowed by default to publish in your on your Git in a namespace that matches your GitHub user ID. So that's the basis. Now, if you want to publish to another namespace, you have still non-automated, you have to interact with uh people from the team to to demonstrate that you actually own the namespace. So if it's a domain, then you we do a domain verification, domain ownership and verification and so on. And the some of the plan, of course, in security is to on the security side is to automate this whole pipeline so that we we can provide some trustworthy signal to our consumers when they download an artifact that is badged as verified that everything is in checked.

Jenn Gile 28:06

Okay, so I get my OpenBSX account approved. I go to upload my first extension. What's the scanning look like for that?

SPEAKER_03 28:16

So it will be transparent for you because you will use either the command line tool that we provide to publish to the extensions or just to the registry or the Microsoft tool. They are both compatible. And the the scan happened in the background. So if you everything is green, just get available on the website and you're done.

unknown 28:34

Yes.

SPEAKER_03 28:35

It is quarantine, then you have to wait for final approval, final review. So I think we we have some SLA SLOs on there. It's usually within the day. It can take up to two days to scan and verify. But that's uh that that's basically how it happens.

Jenn Gile 28:49

Yeah, so you're looking, uh it sounds like for things like hard-coded secrets that could create a security issue, but you're also looking for malware. I know you can't share the malware detection rules, but in general, like what kind of behavior are you looking for when you run that scam?

SPEAKER_03 29:06

So we search for payload, non-payload for malware, of course. We use Yara in the background for many of those scans. We also use AI-assisted malware detection, of course, for some behavioral changes. We search for secrets and credentials, not only our own, but also others. We look for signals of impersonation, so as I mentioned, for teleport scrating, brainjacking. We also recently added obfuscation tricks like glassworm, by the way. I'm really amazed and by the ingenuity of the glassworm author.

Jenn Gile 29:41

They're terrible, but they're so good at what they're doing.

SPEAKER_03 29:43

Exactly, exactly. You have to give them that. But those obfuscation tricks we add them on a continuous basis when we discover new techniques. That's that's part of it. The and our plan is to move toward the update path anomalies. So we have detected some skippers, so extensions that are published for a while and that are actually good. Doing nothing malicious and stay there for a while, and the next update is actually the one that will care the that will bear the malicious payload, those patterns and those behaviors, that that's the thing that we're also detecting. So it's not only about the scan at publishing time, it's also the scan of the global behavior or the global lifecycle of the extension. We we've seen also, and we look at some signals like bot inflated download counts, uh new extension that magically get a million downloads, and in a couple of days that's very suspicious. So this kind of stuff that we're adding gradually to our scans and our detection systems.

Jenn Gile 30:41

Yeah, you mentioned sleeper extensions. We certainly see that in every ecosystem where a threat actor will publish something that's benign, and then they'll publish a malicious version later, and then often they'll publish another benign version after that so they can hide it. So you're looking for these sleepers in your extension marketplace. What kind of signals do you look for that tells you that something may become malicious but isn't malicious yet?

SPEAKER_03 31:15

But it's a combination of the size, the the download number. It's very often it behaves. Behavioral. Yeah, behavioral. And yeah, of course the new scan. So something that has been benign initially and marked as okay if all of a sudden the update triggers some even low signals that that's a safe.

Jenn Gile 31:36

Okay. So I'm curious what your team has been seeing in terms of trends with what people are doing with malicious extensions. You've been scanning for a few months now, and I'm sure you have some ideas of what you see more often than not. What's it look like in that world?

SPEAKER_03 31:55

Yeah, Glassworm is really the flagship example. They are all uh or less copycat of that nowadays. So clone and sleep type of campaign. Again, we had the V2 detected by Socket uh back in April. It's really bad, but we are we are getting there at detecting those and getting better at detecting of those, but that's the the trend. But otherwise, it's really just the usual stuff. Credential leaks. So one compromised publisher and then just no more effective.

Jenn Gile 32:26

Just spirals from there.

SPEAKER_03 32:28

Exactly. So it's still it's a common responsibility or global responsibility of all registries to help users and publishers to not destroy those and to or to be able to revoke lead credentials as fast as possible. So yeah, that's the the two main things. That the very advanced, tricky malware like glassworm, and the good old-fashioned lead credentials that end up.

Jenn Gile 32:53

Are you seeing like between the two categories account takeovers where somebody's credentials were stolen and now malware is being published on their account versus something that was always bad, even if it was a sleeper? Are you seeing one versus the other being more common?

SPEAKER_03 33:10

Not necessarily to guess from kind, making more headlines. So we we hear more about them. The blast values is also usually larger because they they go and they take it for a bit longer, but no, we don't necessarily see any anyone taking the other.

Jenn Gile 33:27

Nothing is ticking up. Something you might be familiar with is North Korea's state-sponsored threat actor group has really been favoring delivering malware through the task.json file for through VS Code extensions. Are you seeing anything similar happening in the Open VSX and ecosystem?

SPEAKER_03 33:47

Yes.

Jenn Gile 33:49

Yes, in VS Code, that's a feature that can be managed. What would you say is a best practice for people who are consuming these extensions? Because essentially, I'll take a step back and explain to anybody in the audience who doesn't know the task.json files get used very similarly to an NPM lifecycle script where it auto installs. And the benefit if you're a threat actor is if you download it, it'll auto-install the malware without the user having to do anything. And Nikela, what would you tell an open vs user that they should either be looking out for or change with their settings so that they're not susceptible to that kind of attack?

SPEAKER_03 34:32

That's where I could lead the to understand that basically none of the users of OpenVSX know that they use OpenVSX. They use cursor, they use anti-gravity, they use Kiro, and they don't they install extensions from each of the those clients. So that's where the collaboration and the fact that those companies are actually contributing to OpenVSX and working with us, that that makes the big changes because they have to implement client side on the at the don-up phase or when they auto-update, because they control the auto-update. We don't provide any client for auto-update, we just deliver the extensions. So that's where each of those sometimes they are just forks and clones of the VS Code code-based, but for many they they have their own custom tricks, and we aim at providing them as much information as possible so that they can act and prevent this kind of behavior from happening in their developer tools.

Jenn Gile 35:27

Yeah, so you're fighting like an extra layer of abstraction when you're trying to help people understand the risk here because they're not consuming directly from you the way that perhaps someone might consume directly from NPM.

SPEAKER_03 35:40

Yeah, exactly. So when some let's take Kiro, if someone installed the new Java extensions in Kiro, we have no way to tell them that the last version of the previous version of these same extensions was malicious.

Jenn Gile 35:54

I was gonna ask you what keeps you up at night, but that's gonna keep me up at night, I think.

SPEAKER_03 35:58

Yeah, exactly. That's definitely keeping me up at night and the all the update path, the auto-update path that all those IDs provide. And one extension can turn malicious tomorrow. And all those good ones and the very famous one are.

Jenn Gile 36:15

Yeah, so I that definitely makes it all the more important that OpenVSX is doing proactive scanning. There's a lot of debate in the community right now about the role of a registry. Should they be holding things back before allowing something to publish? And I think the community more and more believes yes, the registry has a responsibility to look for dangerous things. And in your case, you don't have an easy way to notify people. If I am consuming an open vs extension through cursor, is there something that I should be subscribing to so that I know from OpenVSX if there's been some kind of security incident?

SPEAKER_03 36:57

Oh yes, so we're uh we publish advisories and report whenever or in postport and when they whenever there is an incident. We also publish all the extensions that are detected and flagged as malicious so that those platforms can actually consume those lists to warn their users. We we don't have a feed for end users or for users who don't know the that they use OpenVSX because that would be pointless given that they don't know us usually. But we provide as much, as many things as possible to to the I needs so that they can consume this information and warn their user.

Jenn Gile 37:30

I will put a plug in for open source malware. Anybody who wants a feed of the extensions that we know are malicious, you can come get our free feed. Okay, we'll start to wrap up here. You've said this a couple of times already, and I think I have a good idea of your answer, but this is your opportunity to say what you want from the community. The people who listen to this podcast, many are security practitioners, many are engineers themselves. What are you looking for? Whether it's filling open roles, contributions, your security research program. Give us some homework.

SPEAKER_03 38:01

Yeah, definitely. I will. And that's actually what helps me sleep well at night, is that we are not doing that alone anymore. So we were running the service while it was an issue, but still we were running it by ourselves with a very small community, but now we have member companies and the community and security researchers that have interest in OpenVSX. And we have a homework for each of those communities. So if you are a security researcher, you can join the security research program, recognition program. So if you report malware, detection, or even security vulnerabilities on the code base, then you are eligible to be part of this. We also have nice bugs for the highest grade of those researchers. We don't do bug bounty, just to be clear. We just offer some nice work to uh to recognize their work. If you are a developer, software engineer, then you can also look at the codebase, contribute features, contribute your security mechanism. The code is open source and you have nothing to do, just go to uh codebase. And if you're a company that actually builds on top of OpenVSX, so you have an AI assisted tool that is compatible with VS Code Marketplace, then you most certainly consume from OpenVSX. So become a member of the working group so that helps here the service. And you can also, if you want some base level agreement for OpenVSX, we can provide that with the managed registry, the manage open vs registry. So that's how we do that, not all by ourselves, with the help of the community. So that's really the what we're building and what we're aiming for.

Jenn Gile 39:32

That's great. We'll get those links out there. And I'll say I talked to a lot of people in the community who are like looking to change jobs, improve their resumes, looking for things that will set them apart. And I would say making contributions to a project like this is often more meaningful to a potential employer than going out and getting another certification. So yeah, seems like a great place to get involved and build your resume and maybe feel good about what you're doing.

SPEAKER_03 39:59

Exactly. Yeah, there is a seat on the table for everyone. So please get engaged.

Jenn Gile 40:07

We'll stay in touch and anyone in the community who's interested, drop some comments and we can make connections. So thank you.

SPEAKER_03 40:14

Thank you. This was a great discussion. Thank you so much.

SPEAKER_02 40:22

And then we're back.

Jenn Gile 40:25

Do I have your audio called?

Paul McCarty 40:27

It did not auto-unmute me.

Jenn Gile 40:29

It didn't auto-unmute you. I wasn't sure if it would or not. Um all right. Yeah. So um pressed, that works. What are your what are your thoughts on my conversation with Mikkel?

Paul McCarty 40:42

Oh man, a lot of thoughts. I mean, first, good on them for being really proactive with security. Like I was checking out the security contributors um page, and I'm like, I want to be on this. Um uh I also think sometimes, you know, to one of the last things he said, like you'd be part of the working group, is like a security researcher can't go and join all of these security working groups. So we have to my in their choice not to use a bug bounty program to do it in their own kind of way. I'm always I always question that a little bit. Like, is this making it too hard? You got to go too into your world. But all that being said, I'm keen. Like, I'm looking at it right now. I've got the source code repository open. Um, you know, I want to be part of um I want to understand how we, you know, as open source malware can help, but also like how I personally can help that ecosystem. Because he's right, I mean it's growing um tremendously. I've been watching the new packages come in, and um, I think there's a lot of places there we can help.

Jenn Gile 41:40

Yeah, the numbers that he cited are pretty wild in terms of how rapidly it's growing. Uh, a couple of things that I continue to think are really just interesting from that conversation is the volume of people who don't know that they're using Open VSX uh as they're consuming extensions from Open VSX. And I think that presents a really um nuanced problem, right?

Paul McCarty 42:10

It does. Yeah, that's a great point. Like I thought before I really understood the OpenVSX ecosystem, I thought it was much more niche than the Microsoft VS Code. And it turns out it's kind of the opposite that more things use OpenVSX than do um the official Microsoft VS Code marketplace. So that's that's an interesting eye-opening experience for myself.

Jenn Gile 42:31

Yeah, the other thing, um, and it's I guess no surprise that Glassworm is on his mind. Uh, one of the links that I shared in the comments is um a report that came out earlier this year about um a whole bunch of malicious extensions pushed uh through the glassworm campaign onto Open VSX. Um, but you know, him equally seeing that type of behavior versus typosquats, you know, it's always um fascinating to see what the trends are and how they're different in each ecosystem and his you know efforts that they're working on to tie a publisher to some kind of um authority to publish in order to reduce typosquats, you know, looking for signals of impersonation. I thought those were some important actions that they're taking.

Paul McCarty 43:28

Yeah, I think there's two observations I want to say directly to that. The first is that any ecosystem, any registry, you know, and I saw this at GitLab and I've seen this you know from the outside with GitHub and all kind of in npm, is that they want to, sure they want to do the right thing, but they also want to increase the increase the use and in downloads, right? So that's and and he said it himself in that in that interview. So um there's always gonna be this tension between you know, lack of resistance. I remember the conversations, you know, some of the orgs that I've been in where you have this conversation between this tension between marketing, let's open up, let's open up, and then security going, well, if we do that, this is gonna be the problem. And um, and those those conversations have actual cost and both in the in the sense of the secure team, but where you have to pay for to to to um you know make that work, uh, and then counter that with uh uh this idea that you know glassworm is the only thing when he focused on glassworm, I'm thinking to myself, I think he's looking a little too small because VSX i uh vs files are just JavaScript files, right? Like the you can literally take well not literally, but you can take almost exactly the same payload that you use in npm, modify it ever so slightly, and deploy it in their ecosystem. And 98.5% of the world's malicious packages are hosted in npm. And if npm is that similar to open vs, I think he's got a bigger problem than just glassworm, but um, you know, happy to be a part of that solution.

Jenn Gile 44:59

Yeah, for sure. Okay, this I think is on record as our longest episode, but it was worth the time. Anything else you want to talk about before we wrap it up?

Paul McCarty 45:09

No, I just want to say personally, big shout out to both McKell and and the Open Um uh sorry, the Eclipse Foundation, you know, for reaching out and interacting with. I love that. Oh my gosh, if I wish I I wish I could have that with NPM and GitHub, you know, getting them to interact or even look at my tickets when I'm trying to submit thousands of malicious packages is like pulling teeth. And here's an organization that reached out to us proactively. I just think that's amazing. And big shout out to the Eclipse Foundation for doing that. Um, I really appreciate it personally.

Jenn Gile 45:39

Yeah, plus one everything you just said, uh, this is a community and uh maintaining these kind of platforms is a really big responsibility. So, you know, it goes a long way to get to know these people and to understand what they're working on. And yeah, they're not gonna get it perfect every time, but you know, they're never gonna get it right if they're operating in a silo and not telling people what they're doing and not engaging. So huge kudos to the team for for being part of this. They're definitely out there hitting the podcast circuit. Um, I saw that they were on uh open source security, Josh's podcast recently. So yeah, I think we'll be seeing a lot more from uh Eclipse Foundation in the future.

Paul McCarty 46:26

It's part of Mikhail's uh KPIs for the year, right? It's like how many podcasts you can do. How many podcasts can you do? Yeah.

Jenn Gile 46:33

All right, everyone, have a good one and we will see you next week.

Paul McCarty 46:37

Thanks for listening. We appreciate it, guys. Cheers.

unknown 46:39

Bye.