OpenJS Security Working Group - August 3, 2026

Hi there. >> Morning. >> Hi. >> Morning. >> Ben is out has a conflict this morning. So Ulysus, he told me you're chairing today. >> Yeah, I will try my best. Yeah. Well, I'll be distracted today. My parents hometown in Spokane, Washington is burning and there's they're evacuated right now and there's still level three evacuation. Their house is still standing, but there's a fire a mile away. So, >> Oh, that's really scary. >> I know. >> Yeah. This year is become crazy with the fires. Yeah. Here also in the area we had like was 3 weeks ago 10 kilometers from here. So it was like scary but yeah we were very lucky with the wind. So but yeah still yeah >> well my entire life my mom has had a suitcase under her bed with the most important papers and photos always and we used to kind of tease her you know and she was able to use it this time you know. >> Morning Steve. >> Hello everybody. Hey, just talking. My parents are in Spokane evacuated. So, I was like glued. >> Yeah, glued to my phone. I'll be a little distracted today. Checking. >> So, I don't know if I've seen Jean. Have you started your new job? >> Yep. Started for the last two months. >> Oh, two months. Wow. >> Yeah, >> that's exciting. >> That's pretty good. >> Time plus. Hey, >> I think we're in a good shape to start or we should wait a little bit more. >> I think we're in a good shape. >> Yeah, there's a big forum today. Okay. Um, let's see. So, yeah, I will chair the meeting today. Uh, yeah, and actually we are recording, so that's nice. Um, so yeah. So, hello everybody. Uh this is the first meeting of August 2026 of the security working group of the OpenGs foundation and yeah we have a lot of items today in the agenda and also we have some demos but uh before we start anything uh do we have any announcements that we want to make. >> Well our conference is coming up very soon. So hopefully we'll have a lot of friends there and we're going to the exciting thing we're going to have a workshop. Um, so if you want to learn how to contribute to Node, there's going to be a code and learn sponsored by Harper. So that'll be great. And I know that's been a big team effort from everyone um in the program committee, the CPC and the Node project. So excited for that. >> I will say aside of that, I think there are a bunch of security releases on the way recently since the last uh catchup. Yeah, this two weeks we have a few releases here and there. So yeah, uh important to check out your dependencies and try to upgrade. Um yeah, what else we have in the agenda? So um I think in terms of big topics, uh we still have in the agenda. Uh let's see if we're interested on discussion around Axios. We have also discussions around the MPM blog post uh followup and also we have some followup uh discussions around the CNA API and yeah I think we have something around escalation policy but no news there. Um so we want to tackle any of those. Yeah, and I can just give an update I on I did submit uh an application for funding from the sovereign tech fund. Um and they were very they responded right away just thank you for you know the application. They're reviewing it and would get back to us shortly. So um so that's good. Thanks everyone for participating in that. So >> yeah, that's good. Yeah. Do you know how time how much time it's going to take for them to do a review? >> Um I'm hoping to hear this week. I know Marcel's on vacation, but he was able to I think weigh in and he copied his team, but he is on vacation not too long, but yeah. So, and I think you know the like I said sometimes the the trick with these applications is you know to put enough in where you feel comfortable that you could execute but give us some flexibility. and we essentially positioned it as a research project to think about how we make a cultural shift on how we address vulnerabilities. So with the title wave of AI reports. So that's good. Um so about the rest of the topics as as we are recording do we want to uh follow up now or in the private part of the meeting about the MPN article and the axis retrospective. Okay I will leave that for the end. Um so then yeah for those who have access to the OpenGS CNA um CNA website repository that now it's private so probably some of you might have access or not we I have been starting porting um some of the PRs that I did in the past if you remember on the PC that I did publicly with all the new interface and the prototype and all of that that I think I showcased like a couple of meetings ago. uh I start to move those pieces like from zero to the to the to the s API. So the idea there is mostly um to start getting reviews and see if we can merge some of these. So it's building gradually. One one the first one is to migrate the stack. So we move from teil um to 11tory. Then from that on we start to build all the new things and most important probably is the connection with mitra directly. So we will not do anymore the publication and reservation piprs issues and stuff like that as we do now. I mean we do on the site against the API and then we update the repo it's going to be auto pull the information from Mitri. So uh also we we will fetch another few additional CVs and stuff that are assigned to us because if we reclaim some CVs also they are going to be assigned for uh to us from there. So that will help us to autoop populate the list a little bit. Yeah, those PR are pending. Um, so yeah, I think uh that was mostly for this. I think I have some stuff to showcase. Um, if we're interested into but I don't know we do want to discuss any other topics because I think in terms of the agenda I have some stuff to showcase. One is regarding the maintenance guidelines that I was the maintenance guide sorry for managing advisories and the other piece is regarding the project atlas that I commented last week but I didn't showcase. There is also an interesting piece for the last part of that which is matching all the missing information that we don't see now at the CNA like advisories and CVs that we don't issue. So I want to showcase this a little bit and then we can move to the private part if we want. So um I think it's a good spot if we want to include any other topic before I jump into the demos and things like that. I see a lot of Monday faces might take as a no. Okay. Um so yeah let me show you um a little bit uh some of the stuff that we have been working on. Um I hope that I can see my screen. Let's see. I want to share desktop one. So I assume you can see a website right maintenance guide to GitHub security advisories. >> Yep. >> Okay. Um so yeah let me show you this a little bit. One of the trends that we have uh right now when we work with uh with advisories and especially with maintainers that they never um did um security release using GitHub advisories is there are like some few limitations on the GitHub um API nowadays that is hard for them to know ahead of that because you cannot do simulations. I mean if you want to for example request a CVE and do all the publication and all of that you can do that simulation. So some pieces are hard to understand. So I was discussing with other CNAs about this and I came up with this more or less guide. So you have like um some few pieces. So if the first time uh you land to this and you're in a panic in how to manage this you have a small check here with all the uh explanation about the mental models the link check clicks on how the process work more or less and some basic gotas that you might face when you are doing this like for example you don't have continuous integration on the private forks on the advisories I mean these kind of things that are not so obvious um at the first moment and then we have also uh the guide itself which is divided into a specific chapter And then we have FAQ which is sometimes if you just want to ask quick question about how do I assign a CB or things that you don't remember by her or things like that. So it's a little bit splitted here. Also here we list the limitations that we have against GitHub. So this is uh against GitHub current platform. So the idea here also is to provide a harmonize or a simplistic way to provide them feedback also as a product and say like look these are the things that right now are affecting us and this is how they are affecting us the problem that they are facing and how we are doing the workarounds and the limitations that we have. So there are workarounds and works but but ideally we should feel fix these kind of things right like for example when you publish um in the advisory you have to delete the all the private forks that you have before doing that publication which is not so obvious and if you don't take that in account for example and you want to you know left some stuff for later you cannot do it and things like that right so we want to we want to cover this as a feedback for them and I think just to show you a little bit the guide is is quite long and explain a little bit on all the process and how to evaluate since a very generic one. I'm also waiting to get more feedback from other CNAs. So also to include a more while ecosystem perspective and not just super JavaScript ecosystem but I think it's like for example in the case of triaging which is probably the one that we invested the most. We explain a lot about what is the editorial criteria for the teams. Uh how important is to have a threat model. uh you have the options to say no and how you can say no with some examples that we redacted and things like that to make it more obvious but the idea more or less is to help maintainers to to see what happened. We tried already this guide against two maintainers within the foundation recently. Uh that the first time they were working on advisories and the feedback was positive but still uh this is super opinionated in the way that I was the only one uh working and contributing to it so far and the idea is to get more views more people more ideas uh more feedback more things into this. So uh the goal in general for this is please help us uh by providing feedback. Uh if you are in the channel in the security channel in the opens foundation I think I sent a message like around the 20 of July or something like that about this with all the links and explanation to more or less what I just show you here so you can get an idea. We are still working on the road map for the final version. I mean we did it for we plan to do for July but probably we are going to do that by August. Um so yeah we I'm gathering with other um cyber security experts uh interested and so on from the from the alpha mega initiative into this. So yeah my idea is to collect more feedback from others basically that's that's the plan. So yeah I don't know questions I know that there are other guides so that's also was one of the questions uh made by others like I know that alphamea has one we as opengs foundation also have one around 10 p.m. secure publication stuff like that. The idea of this guide was more uh to cover pragmatical overview for maintainers. Like first time you deal with advisories, let's go platform specifics around advisories, what you can do and what you should not. But it's true that we can probably enrich this by linking more to existing guides so the people can get more context on the why and reasons and stuff like that. So yeah, I hope this might help. Um, do we want to set like a like a day that you want we should ask for people to provide feedback by ideally? Yeah, ideally if if if the people can provide feedback like in the next two weeks and that will be ideally because uh then we try to make a release for let me update this and we go with try to make a released at the end of August and and they and that way we can fix it uh and we can have something ready by the end of the month ideally but yeah I don't know also maybe some people will be on holidays and stuff like that so I don't know probably we can try I mean the guide is live but the idea is to make like more official in August and make some promo around it also. >> Yeah. So, all right then. Yeah. But maybe we add a comment here and and update the description with something saying you know requesting feedback by the 14th. >> Yep. >> And then hopefully that also gives enough time to resolve anything um you know in the following week I guess uh for anything that comes in at the very end of that period. >> Yeah. Yeah. Um, and yeah, as long as we have like, you know, a few folks that have looked at it and we we've we like what it is, then I think we're good. And then if we can always make updates, you know, later as well. >> Yeah. >> Okay, that sounds good. Yeah. Also, the idea is to do more releases over the time. So, if that something doesn't fit on August, then we can do it September or whatever. So it's going to be more or less like when we have something to ship, we try to ship it once a month more or less. Uh when we have enough for that month basically that's that's pretty much idea until it's become more solid. But yeah, that's good. I will I will put an issue for that and a reminder on the on the Slack channel too so we can get visibility on that. But yeah, even if after the two weeks you have time to do it also that's super welcome feedback at any time. Can you post a note in the security channel as well? >> Yeah, I will I will do it. >> Thanks. >> Okay, I don't see hands because I see just few people on my screen. Uh so yeah, if if someone want to ask or say something, feel free to do it. If not, I can jump to the next topic in the demos. Okay, I will I will jump to the next demo. Um, so I discussed this a little bit in the past. Um, so one of the challenges that we have uh right now as as CNA is like u we have a lot of projects under o over umbrella and it's true that the project can uh ideally use over CNA to issue the CVS. So we we have some control around them but it's true also that they can use others. For example, NodeJS right now um is is using hacker one another and other another project are using um advisory. So they can ask directly for GitHub for the CVS and so on. That's totally fine. The thing is sometimes may happen that someone just go to Mitra or any other CNA plus resource and try to issue a CV against a project without discussing with with the maintainers and is hard for us to get visibility to all of that. Um so my idea um recently was to try to understand like how this happened like if we can have a somehow a list of the CBS advisories that are attached to the projects that are belonging or under the umbrella of the OpenGS Foundation. Um I thought at the beginning that it's going to be a very simple thing to validate but end up being more complex than I anticipated. Um so yeah basically uh I was able to map some of this. It's not perfectly map it. Uh so yeah let me show you the list uh a little bit. So I was working into this idea. So pretty much my idea uh it's not 100% accurate. So so don't worry if the numbers don't totally match or you see something that are not totally matches yet. Um so the idea was to see like for example who are the issues uh the issue of the CVE. Sometimes some projects do advisories but don't do CVE. I mean this can happen as well. So the idea was to try to collect all these kind of artifacts around vulnerabilities on the project so we can list them. Obviously we can list the ones that we issue. I mean this is dated from yesterday I think. So uh there are some stuff missing from today but basically you can see for example the ones for NodeJS from the hacker one and so on. So you don't see an advisory because they doing hacker one. So they do a CVS list. So you can pretty much see what's going on. um in order to build this list which the idea probably at the end when this uh when we build a dictionary one to one with the CDs and advisories and so on is to include it or not in our CNI website if not this can leave here uh I started to work in this project called Atlas the idea of atlas basically is to start mapping like all the GitHub organizations that are under our umbrella then all the repositories I mean all of the public information obviously and then from those we try to build and understand how many mpm packages and antifact publish and from those we also try to track versions and things like that and then from those we start to understand how many CBS advisories and stuff like that are related. So uh in order to build this list I needed to collect all the additional data around. So that give us the opportunity also to get some visibility around the project. So um let me show you a little bit some of the cases here. Um so yeah this is basically the project aslas uh what we are collecting right now for example. So we have the mpm organizations I mean the github organizations that right now it's around 40 then all the repositories that are public which is almost 2,000 and then from those the mpm packages those are not all of them and this is almost uh 1,500 but there are a little bit more because for example in the case of fastify we are not tracking here the legacy ones that are deprecated that is in the fastify name not with the grouping alias on npm. So yeah, we lost some um some definition there and also the advisories and I'm trying to collect some alerts which are super basic but might be important. So for example some of these alerts as we are tracking a snapshot of what's going on on everything via the GitHub API then we can see for example if one repository become archive if there are new repositories if they are publishing a new advisories these kind of things become like the alert so you can get more less understanding what happened from one moment to another in the organization and also we have some errors which are things that I not yet capable of understanding so all of this is a little bit of u in pilot let's say as a PC very PC. Um, so yeah, basically under the hood on this I I have a lot of scripts that I'm tracking for the GitHub advisories and the repos and everything. So that's also the way how I track what's going on with advisories. So I have my own Postgress databases with all of this information. I mix a lot of different databases including meat recipes and a lot of stuff. So basically from that I'm doing queries and I'm and I build this. So there is a lot of room for opportunities and stuff and also this is running locally on my home lab. So this is a little bit tricky but just to show you what kind of information we have. So for example for the moment organization uh that you may remember you from here you can see all the security advisories that we have and CVS and stuff. So you can also link to them and see what's going on. You can see all the mpm packages that we have and the latest versions and the amount of downloads for example. So you can get an understanding right now like for example which one is the most popular things like that right also you can get an idea of the public repositories if they arrived not archive it blast push and so on. And I mean all of this information is public anyway right on GitHub. But the idea is to have everything aggregated here like in a markdown. Obviously you also have this data um JSONs here which is massive uh files but you can get all of this information also on JSON and you can get normally additional information not the only things that you see in the tables you can see more. So you can also uh be more accurate around this. So if you go into details like for example into mpm packages so you can see for example who are the maintainers that actually are listed on the mpm page with the rights to publication which not doesn't mean it's all of them but you can get some ideas you can see also the amount of um last week downloads and you can get some information for example if they have some installed scripts if they are deprecated not deprecated amount of dependencies and things like that so you can get an idea a little bit on how that works. Uh what else we can see here? Let me see. Like for example, for CVS, you can see a list of all the CVs that are associated that I commented before but as a separated pieces. You can see also all the advisories as I mentioned before, the ones that are public and around here. So you can also have a markdown and see the details of all of those. And this was also the idea of the alerts that they say before like for example if you have a new CVE or also if an advisory has changed the content the description and also when a CVE that we publish get edited by someone else because this happened quite often like for example we publish a CBE and after a few days uh there are some editorial corrections around that and we don't get not notified somehow around this unless you check Mitra database manually. So with here we can we can get an idea of what happened and so we can go very very in detail into the divs and things like that and get an idea how it's going on. Um yeah that was pretty much the I mean all of this is a secondary um you know visualization info that I just have uh in order to build this idea of uh you know CBS and advisories attached to the project that we own right I mean they're under the umbrella. So all of this is a totally secondary thing but I think it might be important uh for us to understand and visualize what's going on in terms of projects around the the foundation and also uh how this works in terms of information. If you see for example comets let me show you this one uh yeah this second two weeks update. So here you can see I need to change a little bit because I think right now on the on the martm files you can see um like for example um yeah you can see like when was edited. So we we modify all the files. So this is a little bit tricky to see but this is two weeks work. So you can see like for example if there are new advisories what happened um and so on like if there are new repositories um things that change I mean uh you can get a lot of visibility here. So also you can get an idea of differences between snapset. I mean we can work on this. Um so I didn't know if this is some interesting or not. If it's I don't know. I mean this is a side thing that I was working uh just because I wanted to build the JSON basically to to match all but but yeah I don't know this is something that might be helpful not helpful. How do you think about how do you feel about this? >> This is this would be public. Yes. >> This can be public or this can be private. I mean uh so far all the information here listed is public. I mean it's the one that you can get I mean with a lot of effort but you can get this information from the GitHub API hitting the limits everywhere and stuff like that. But yeah is all of this is public even the downloads per week of mpm packages that pis all of this is public info. >> I'm wondering if we can plug this into the Linux Foundation LFX tool on project insights or just to make sure that we're not you know that we're all aligned. >> Yeah, probably. Oh, we can fetch data from them or the other way around. >> Yes, exactly. Yeah. >> Yeah, that's what >> connected to that team. I think that would be a good thing to do and also kind of gives you some backup if you're not there that there's Right. >> Yeah. Because right now this this run because I have like an small home lab. So I have a machine like running 247 for the security stuff. >> Yeah. So if I'm on holidays, this is not going to be updates and stuff like that. So yeah, obviously we can move this to somewhere else. Uh but yeah, I don't know. Uh so yeah, probably get in touch with them and see what they have. Uh you >> okay? Okay. So, uh I think yeah, we still have like half an hour. Uh sounds good. If we move to the private part of the of the meeting today and we discuss about the other things we want to discuss a last thing in public. So >> let me stop the recording. >> Yes, please.