Security Collab Space Meeting - November 10, 2025

Security Collab Space Meeting - November 10, 2025 🔗 **Source:** [Security Collab Space Meeting - November 10, 2025](https://www.youtube.com/watch?v=75kevtOgKZA) > [!note]+ Document Notes > tags: [openjs, security, collab-space] > author: OpenJS Foundation > source: YouTube > reference: https://www.youtube.com/watch?v=75kevtOgKZA > date created: 2024-11-10 12:00 > > # 🏷️ Title: Security Collab Space Meeting - November 10, 2025 >  ## 🧰 Action Inbox - [H1] Review and approve security response plan PR — merge today/tomorrow #security - [H2] Make command center repository public — audit and move private data #tooling - [H3] Consider VEX adoption for vulnerability documentation — explore Node.js approach #security ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [OpenJS Foundation](https://openjsf.org/) - [Security Working Group](https://github.com/openjs-foundation/security-collab-space) ## 📝 Summary - Weekly OpenJS Foundation security collaboration meeting covering foundation-level security initiatives - Key focus on finalizing security response plan PR and making command center tooling more accessible - Discussion of innovative approaches like VEX adoption for vulnerability documentation - Strong emphasis on transparency while protecting sensitive maintainer contact information - Node.js leading adoption of computational vulnerability assessments through VEX format ## 📖 Main Content The OpenJS Foundation Security Collab Space holds weekly meetings to coordinate security efforts across foundation projects. This meeting focused on three major initiatives: finalizing a foundation-level security incident response plan, increasing visibility of the command center monitoring tool, and exploring VEX (Vulnerability Exploitability eXchange) adoption following Node.js's lead. The response plan differs from typical project-level incident response by focusing on supporting projects rather than directly handling CVE reports. The command center currently remains private due to maintainer contact information but provides valuable project health metrics including security scorecards. Node.js is pioneering VEX adoption to provide computational documentation of vulnerability assessments, helping downstream users understand which CVEs actually affect their deployments. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/75kevtOgKZA?t=0) — [H1] Meeting opening and security response plan discussion - Key idea: Foundation-level incident response plan ready for final approvals - Evidence: "We worked on the incident response plan at the foundation level which is different than the typical incident response plan" #### ⏱️ [02:30](https://youtu.be/75kevtOgKZA?t=150) — [H2] OSF Security Scorecard Monitor integration - Key idea: Scorecard monitoring moved to command center for better integration - Evidence: "We decided to move that to the command center. So basically it's integrated and we already have some filters for projects" #### ⏱️ [04:45](https://youtu.be/75kevtOgKZA?t=285) — [H2] Command center visibility challenges - Key idea: Repository privacy prevents broader community access due to contact information - Evidence: "The repo is private because inside there is contact information for all the maintainers that is super helpful when there is some kind of crisis" #### ⏱️ [06:20](https://youtu.be/75kevtOgKZA?t=380) — [H2] Solutions for making command center public - Key idea: Multiple options proposed for protecting sensitive data while enabling public access - Evidence: "Maybe encrypt that piece using PGP or whatever or something like that and just make it public" #### ⏱️ [08:15](https://youtu.be/75kevtOgKZA?t=495) — [H3] Command center publicity strategy - Key idea: Plans for broader communication once repository becomes public - Evidence: "I'll definitely bring it up in the CPC. We could also email the mailing list" #### ⏱️ [09:30](https://youtu.be/75kevtOgKZA?t=570) — [H3] Alpha Omega security shorts initiative - Key idea: Creating short video content to increase security awareness and engagement - Evidence: "We have been recording some shorts for the alpha omega and I would like to expand that to this group as well" #### ⏱️ [11:00](https://youtu.be/75kevtOgKZA?t=660) — [H1] Node.js VEX adoption introduction - Key idea: Node.js exploring VEX format for computational vulnerability assessments - Evidence: "Marco bring us the idea of using VEX for as a format for others to understand our CVE and potential CVEs in the dependencies" #### ⏱️ [12:30](https://youtu.be/75kevtOgKZA?t=750) — [H1] VEX problem statement for Node.js - Key idea: Static scanners flag false positives that VEX could resolve computationally - Evidence: "Some people using node get complaints on static scanners saying you are injecting this which might be vulnerable and the thing is it's actually not" #### ⏱️ [14:15](https://youtu.be/75kevtOgKZA?t=855) — [H1] VEX implementation approach - Key idea: Building on existing JSON vulnerability tracking with dependency CVE inclusion - Evidence: "We already have a JSON file that we use for the 'is my node vulnerable' tool" #### ⏱️ [16:00](https://youtu.be/75kevtOgKZA?t=960) — [H2] VEX temporal validity concerns - Key idea: VEX records represent point-in-time assessments that could become outdated - Evidence: "When you say that you're not vulnerable, it's like a snapshot. You're not vulnerable today, but tomorrow a pull request could be merged" #### ⏱️ [17:30](https://youtu.be/75kevtOgKZA?t=1050) — [H2] VEX maintenance strategy - Key idea: Regular assessment updates needed when releasing new versions - Evidence: "We need to create a monitor for that particular CVE. Whenever we release a new version of Node.js we need to assess if that VEX is still up to date" #### ⏱️ [19:00](https://youtu.be/75kevtOgKZA?t=1140) — [H3] Meeting wrap-up and action items - Key idea: Clear next steps identified for security response plan and command center - Evidence: "We want to get the security response plan merged. For those of us that are tagged in..." ## 📚 References - [OpenJS Foundation Security Collab Space](https://github.com/openjs-foundation/security-collab-space) - [Node.js Dependency Vulnerability Assessment](https://github.com/nodejs/dependency-vulnerability-assessment) - [VEX Specification](https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf) ## 🗣️ Paraphrase - The OpenJS Foundation maintains a foundation-level security incident response plan focused on supporting member projects rather than directly handling vulnerability reports - A command center tool provides comprehensive project monitoring including security scorecards but requires careful handling of private maintainer contact information before public release - Node.js is pioneering VEX adoption to provide computational vulnerability assessments that help downstream users distinguish between actual threats and false positives from static analysis tools ## 📰 Newsletter The OpenJS Foundation's Security Collab Space continues advancing foundation-wide security initiatives with practical tools and processes. This week's highlights include finalizing a foundation-level incident response plan and preparing to open-source their command center monitoring tool that tracks project health metrics across the ecosystem. Node.js is leading an innovative approach to vulnerability communication through VEX (Vulnerability Exploitability eXchange) adoption, addressing the common problem of false positives from static security scanners. This computational approach to vulnerability assessment could benefit the entire JavaScript ecosystem. The team also launched Alpha Omega security shorts - brief video content designed to increase security awareness in developer communities. These initiatives demonstrate the foundation's commitment to making security more accessible and actionable. Resources: [OpenJS Security](https://github.com/openjs-foundation/security-collab-space), [Alpha Omega](https://alpha-omega.dev/), [Node Security WG](https://github.com/nodejs/security-wg) ## ✅ Action Items #### DevRel - Developer advocacy: Promote VEX adoption through conference talks and workshops - Education: Create tutorials on command center usage and security scorecard interpretation - Developer experience: Improve documentation for security tooling and processes - Community management: Coordinate feedback collection on security initiatives #### OSPO - Policy & Governance: Finalize foundation-level security incident response plan - Security Management: Implement VEX-based vulnerability assessment workflows - Software Inventory: Integrate security scorecard data with SBOM strategies - Community Engagement: Support Alpha Omega security awareness initiatives #### Community - Maintainers: Provide command center access for project health monitoring - Contributors: Enable participation in security working group meetings - Sponsors: Demonstrate security investment impact through transparent reporting #### OpenJS Foundation - Security: Merge security response plan PR and begin implementation - Tooling: Audit and prepare command center repository for public release - Communication: Develop publicity strategy for security initiatives across CPC and mailing lists - Innovation: Monitor Node.js VEX pilot for broader ecosystem adoption ## 🧪 Hypotheses - VEX adoption will significantly reduce false positive security alerts for Node.js downstream users - Making the command center public will increase community engagement with project health metrics - Foundation-level incident response coordination will improve security posture across member projects - Short-form security content will increase developer awareness and adoption of best practices ### 📊 Methodology - Track false positive reduction metrics after VEX implementation in Node.js - Monitor command center repository engagement metrics post-public release - Survey member projects on incident response effectiveness and coordination improvements - Measure security content engagement rates and behavior change indicators ### ❓ Questions - How can VEX records stay current as codebases evolve rapidly? - What governance model will ensure command center data quality and currency? - How will foundation-level incident response coordinate with existing project processes? ### 🔮 Future Research - Standardized VEX implementation patterns across JavaScript ecosystem projects - Automated security scorecard improvement recommendations and tooling - Cross-foundation security collaboration models and shared tooling ### 💡 Implications - Practice: VEX adoption could reshape how JavaScript projects communicate vulnerability status - Policy: Foundation-level incident response may influence industry coordination standards - Security: Command center visibility could drive ecosystem-wide security improvements - Education: Security shorts format may become model for technical community education ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Meeting agenda structure, clear topic transitions - Improve: Command center dashboard screenshots, VEX workflow diagrams #### 🔊 Aural learners - Present: Full audio meeting recording available - Improve: Podcast-style summary highlighting key decisions #### 🗣️ Verbal learners - Present: Technical term explanations, collaborative discussion format - Improve: Glossary of VEX terminology, security concept analogies #### 🧩 Kinesthetic learners - Present: Action-oriented discussion with clear next steps - Improve: VEX implementation checklist, command center setup guide #### 🧠 Logical learners - Present: Structured agenda, cause-effect security discussions - Improve: Decision trees for incident response, VEX assessment flowcharts #### 🧑‍🤝‍🧑 Social learners - Present: Collaborative working group format, open discussion - Improve: Cross-project collaboration templates, peer review processes #### 🧘‍♀️ Solitary learners - Present: Individual action items, self-directed follow-up - Improve: Personal security assessment worksheets, private study materials #### 🌿 Naturalistic learners - Present: Ecosystem-wide perspective on security health - Improve: Security lifecycle analogies, ecosystem impact assessments ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive timestamps - Improve: Alt text for any referenced dashboards or charts #### Keyboard navigation - Present: Standard video player controls - Improve: Transcript with jump-to-timestamp functionality #### Contrast and readability - Present: High contrast meeting notes format - Improve: Ensure any shared screens meet contrast requirements #### Text resizing and reflow - Present: Responsive note format supporting zoom - Improve: Verify command center interface accessibility #### Media and captions - Present: Full transcript available - Improve: Auto-generated captions for video segments #### Forms and interactions - Present: Accessible GitHub PR review processes - Improve: Screen reader testing for command center interface ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global foundation perspective, timezone consideration - Improve: Multi-language security resource development #### Inclusive language - Present: Professional, technical terminology with explanations - Improve: Plain language security communication guidelines #### Neurodiversity support - Present: Structured agenda, clear action items - Improve: Meeting notes with consistent formatting, logical flow #### Representation - Present: Technical leadership from multiple backgrounds - Improve: Diverse security expertise highlighting in communications #### Psychological safety - Present: Open discussion format, supportive feedback culture - Improve: Anonymous security reporting mechanisms, safe escalation ### ✅ Logical Validity #### Strong reasoning - Deductive strength: VEX adoption logical progression from existing vulnerability tracking - Inductive strength: Command center success patterns applied to broader visibility - Causal reasoning: Privacy concerns directly blocking public tool adoption - Analogical strength: Foundation-level response plan compared to project-level approaches #### Fallacies - False dichotomy: Could explore partial privacy solutions beyond full public/private split - Appeal to novelty: VEX adoption justified by utility, not just innovation #### Tone of voice - Overall tone: Collaborative and pragmatic with focus on actionable outcomes and community benefit ### 🛡️ DARVO Analysis - Deny: No denial patterns detected - transparent about challenges and limitations - Attack: No attacking behavior - constructive problem-solving approach - Reverse victim/offender: No reversal patterns - clear accountability for deliverables - Emotional cues and rhetoric: Professional, solution-oriented discussion with genuine concern for community needs ## 🎯 Conclusion The OpenJS Foundation Security Collab Space demonstrates mature security governance through practical tool development and innovative approaches like VEX adoption. Key next steps include finalizing the security response plan, opening the command center for community access, and monitoring Node.js's VEX pilot for broader ecosystem implications. The foundation's focus on transparency, community support, and computational approaches to security assessment positions it well to lead JavaScript ecosystem security initiatives. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Foundation-level security incident response differs from project-level approaches > [!quote] [Security Collab Space Meeting](https://www.youtube.com/watch?v=75kevtOgKZA) by [[OpenJS Foundation]] via [[YouTube]]. Published 2024-11-10. Accessed 2024-11-10. > "Foundation level incident response plan which is different than typical incident response plan to handle directly security reports." Foundation focuses on supporting member projects rather than direct CVE handling, requiring different coordination mechanisms. [view highlight](https://youtu.be/75kevtOgKZA?t=150#H1) #security #governance ID:rw_001 ### [H2] VEX provides computational vulnerability assessment documentation > [!quote] [Security Collab Space Meeting](https://www.youtube.com/watch?v=75kevtOgKZA) > "Using VEX for as a format for others to understand our CVE and potential CVEs in the dependencies." Enables automated tooling to understand maintainer vulnerability assessments beyond simple CVE lists. [view highlight --- ## Full Transcript [00:19] Hey everybody, welcome to the November [00:22] 10th OpenJS uh security collab space [00:25] weekly meeting. Uh let's dive into the [00:27] agenda. Um so Ulyses, uh I think I gave [00:30] you like two-minute warning that I was [00:32] adding some things to the agenda with [00:33] your name on it. So if you're not ready [00:35] to talk about or not comfortable, we can [00:36] totally skip them. Um, but I saw some [00:39] comments around uh trying to get the [00:42] security response plan PR mer emerged. [00:44] So I thought we could discuss that and [00:46] see if we can unblock you on that one. [00:48] >> Yeah, that that would look great. Yeah, [00:50] basically we have the um yeah, we worked [00:52] on a little bit ago on the incident [00:54] response plan at the level the [00:55] foundation level which is a different [00:57] one than the typical incident response [00:59] plan to handle uh directly security uh [01:02] reports in terms of CDs and stuff. It's [01:04] a little bit different. It's more like [01:05] supporting to the project. So we have [01:07] been discussing this uh for a long time [01:09] offline and so on. There is a lot of [01:11] feedback but I think there's already a [01:13] solid version. Uh so the idea is to get [01:15] more approvals just to land this first [01:17] version and then I can start iterating [01:19] over and collecting a little bit more [01:21] feedback when it's like become official. [01:22] So I think uh Jordan already approved [01:24] it. So um if few more of you can approve [01:27] it I think we can we can land it [01:28] probably today tomorrow. That will be [01:30] fantastic. [01:35] You're unmuted, Ben. [01:38] >> Uh, yeah, I noticed I'm on the reviewer [01:40] list, as is Raphael. So, um, we will [01:44] definitely look at that. Awesome. [01:47] Okay, next up was OSF Security Scorecard [01:51] Monitor. This was another PR that had [01:53] kind of been sitting. Um, I'll paste [01:56] this in chat here. [02:01] Uh, this is another um one for you, [02:03] Ulyses. [02:07] So actually maybe this ties in with um [02:12] the command center discussion too. Are [02:16] these related at all? Ulyses. [02:20] >> Oh, you're actually was muted. Yeah. [02:22] Okay. Yeah, actually we we we have been [02:25] working. Yeah, I was was thinking on [02:26] this. I saw the date and I was like what [02:28] sold? But yeah, basically the thing is [02:30] we started on thinking on tracking the [02:32] project like in terms of the scorecard [02:33] reporting and so on uh for us here. Um [02:36] and then we decided to move that to the [02:38] command center. So basically is there [02:40] integrated and we already have some [02:41] filters for projects and stuff. Um well [02:43] the information is not sensitive at all. [02:45] I mean if we are super interested on [02:46] this we can just bring this info back to [02:49] here but I think it's okay at the [02:50] command center because I mean worst case [02:52] scenario you end up having like a huge [02:54] massive markdown uh files that basically [02:56] Raf and I are tracking in case that [02:58] there are some weird issues in the in [03:00] the project or some specific project is [03:02] trying to you know uh write a better [03:04] scoring so we try to help them from [03:06] there and so on but yeah basically it's [03:07] mostly like a maintainers focus rather [03:09] than open to the community but yeah the [03:11] tooling is open so so we can always [03:13] bring this or just generate a super [03:15] summary or something if it's super [03:16] relevant. [03:17] >> So can this be okay? Let me make sure I [03:20] understand. So was this integrated into [03:22] the um command center already and so [03:24] this closed? [03:26] >> Yeah, if if you see the read you have [03:27] like this table and then you have like [03:29] this uh well the only sensitive there is [03:31] the contacts right but but you also have [03:33] like the scorecard link and then if you [03:35] click you can see the reports for every [03:37] project. We don't we run those manually [03:39] because just in the points that we are [03:40] tracking but yeah basically you have [03:42] that info already segmented. [03:44] >> Okay. All right. Um the next one is I [03:48] did want to talk about command center a [03:50] little bit. Um so first question is does [03:53] everyone here know what that is? [03:57] Okay good because I wasn't sure how well [03:59] socialized this was. Um, but I was [04:02] thinking, um, we don't, um, I think it's [04:04] really valuable and so I'd like to to [04:07] integrate it more into some of the work [04:09] that we're doing. Um, and so I just [04:12] wanted to talk about kind of openly what [04:14] folks think the next steps might be on [04:18] increasing its visibility and, uh, like [04:22] the practical application of what we're [04:23] seeing there and how we can help [04:26] projects [04:32] Yep. Ulyses. [04:33] >> Okay, I will go first. Yeah, basically I [04:36] think one of the biggest challenges now [04:38] for this is like visibility literally [04:40] like in terms right now the the repo is [04:42] like kind of private. So even if we like [04:44] you know bring this tool to other forums [04:46] and try to bring other folks like yeah [04:47] you need to be part of at least the [04:48] OpenGS foundation or in order to see [04:50] this. Uh the reason why it's private uh [04:54] it's because inside of this repository [04:56] there is like a contact information uh [04:58] for all the maintainers that is super [05:00] helpful when there is some kind of [05:02] crisis or whatever situation that we [05:04] need to actually bring the security [05:05] contacts by email by Slack whatever. Um [05:08] so yeah that's a great and it's working [05:10] fine. I think most of this info anyway [05:12] is probably uh public like 99% of that [05:16] info but even those is like a really [05:19] great target for people staminas and so [05:21] on. Um so maybe something that we can do [05:24] is just um encrypt that piece you know [05:28] using PTP or whatever or something like [05:31] that and and just make it public. Uh [05:33] that's the only thing that is preventing [05:35] us from going public with this honestly. [05:43] mute. [05:46] >> Sorry. Uh I do think it would be really [05:48] useful to have this um public especially [05:50] if we start to add more things to the to [05:53] the tables. This is really useful. Um [05:56] and I also agree with you that we don't [05:58] want to make people's emails public if [06:00] they haven't given us permission. Um so [06:03] yeah, I think hiding hiding that not [06:05] hiding it but like linking to it in a [06:07] protected way. Maybe it's a Google Drive [06:10] document um that only has certain [06:12] permissions on it or something like [06:13] that. Um but yeah, that would be great [06:15] if this could be public. Uh Chris, [06:19] >> uh yeah. Um [06:22] I think I was going to say something [06:23] pretty much what what Ben already said, [06:25] but I'll expand on a little bit. Um [06:27] yeah, I wouldn't want to like um have to [06:30] make people like have to figure out how [06:32] to decode like the emails. So, like if [06:35] they could be just in a if like that [06:37] stuff could be in somewhere private. Um, [06:40] uh, one idea, you know, obviously it [06:42] could be in a in a private repo, it [06:43] could be in a Google doc or whatever. [06:45] Um, but another option could be, um, I I [06:49] learned that this feature existed in [06:51] GitHub that I did not know about, which [06:53] is, you know, how you have, um, the [06:56] GitHub repo where you have community [06:58] health files, you have like security, [07:00] etc. Um, [07:03] oh, this would be at the org level, but [07:05] maybe it makes sense. Um, anyway, you [07:07] can, um, have a public and a private [07:10] version of it. So, by default, like your [07:13] github or readme would be the public [07:16] one. There's a way you can make a [07:18] private one that's only visible to um, [07:22] people that are actually in your org. [07:25] Um, so I don't know that's just in one [07:29] option as well. Um, but yeah, either [07:33] way, whatever works, whatever's easiest. [07:37] Okay, so I think next steps on this one [07:40] is maybe [07:42] me, Ulyses, and Raphael will talk about [07:44] this this week and decide where to move [07:46] the private information and um then make [07:50] this repository public after we audit [07:52] it, right? [07:55] Okay. [07:56] >> And what once it's public, what sort of [07:58] maintainer communications do we want to [08:00] do? [08:03] >> That's a good point. Um, I'll definitely [08:06] bring it up in the CPC. Um, I think [08:08] that'll be a good a good spot. Um, [08:13] we could also email the mailing list. [08:17] Um, [08:19] >> yeah, anything. I mean, we could do a [08:21] blog post. [08:23] kind of open. I don't know if it's blog [08:24] postw worthy. It might be social worthy, [08:28] >> but yeah, I think at the definite would [08:31] be CPC and mailing list. And then um [08:34] Robin, if you um are if you would like [08:36] this to be more public, we could do so [08:39] in the blog. [08:40] >> Probably worth just doing like a little [08:42] like if we're talking about a mailing [08:44] list, maybe we just do this and then [08:46] reminder, here's some other security [08:48] resources we have. like to see it [08:51] probably be worthwhile. [08:57] >> Yeah, we can also include it in the [08:59] super recap of like the of the full year [09:02] alpha work. So, that also can be a good [09:05] uh part of that report. [09:07] >> That's a good idea. [09:11] >> Okay. [09:13] >> All right. Next up here is ideas for [09:15] Alpha Omega security shorts. [09:18] Raphael [09:22] So, um I'm having some trouble with my [09:26] connection. So, uh if my my voice [09:29] freeze, uh let me know. Um so, we we [09:33] have been recording some shorts for the [09:35] alpha omega and I would like to uh just [09:39] u expand that uh to this group as well. [09:42] like in case you have any idea of topics [09:45] that would be great to be more uh to to [09:48] have more eyes on it or to publicize [09:51] more about that because I know that we [09:54] do a lot of work and uh security is not [09:57] something that people is looking every [10:00] single day for new updates and things [10:02] like that. So the best way to reach out [10:04] uh individuals uh developers is by [10:07] creating content. So uh if you have any [10:10] idea or if you want to record any any [10:14] specific topic uh it's open feel free to [10:17] ping myself or Lis uh we can schedule a [10:20] call and and talk about that. So this is [10:23] just uh this more FYI. [10:26] Uh yeah. Um Ben put a little comment. A [10:29] short is a little short video snippet. [10:33] Um and we have a little bookend with [10:35] some graphics. It's called JavaScript [10:37] security update I believe. And um [10:40] they're one minute kind of max. Um and [10:44] so Kylie's doing a great job of editing. [10:47] So yeah, if anyone has ideas, you could [10:49] also there's um kind of a PR marketing [10:53] channel in Slack you could reach out to. [10:55] Yeah, Kylie as well. [10:58] >> Apologies if I if I missed this, but um [11:00] where where will these be used? [11:02] >> Social. [11:06] >> Cool. [11:09] Okay, last up here is Node.js adoption [11:12] of VEX. [11:17] This is very cool. Yeah, actually uh [11:19] yeah, we have like uh this is like a [11:21] heads up for others. Uh so basically the [11:24] last uh security working group uh that [11:27] we have in the NodeJS project um Marco [11:30] uh bring us the idea of using Wex for as [11:34] a format uh for others to understand our [11:37] CVE and potential CBS in the [11:39] dependencies that we have. So for [11:40] example in the case of node is super [11:43] relevant because we fork some tooling [11:45] and and we do actually a lot of [11:47] vulnerability reviews and so on right. [11:49] So uh while we are clear on if we are [11:52] vulnerable or not there was not like a [11:54] computational way to validate that [11:56] information. So uh some people that are [11:59] using node or building notes from source [12:00] and stuff like that they get some [12:02] complaints on the you know static [12:04] scanners and this kind of things saying [12:05] like you are injecting this which might [12:07] be vulnerable and the thing is is [12:09] actually not but it's hard to you know [12:10] find this documented somehow [12:12] computational. So the idea for us was to [12:15] you know uh it was the first meeting [12:16] honestly it was like a brilliant idea. [12:18] going to see how that will work you know [12:19] in in practical terms and so on but uh [12:22] as we already have like a JSON file with [12:24] all the CVE from the period of the CNA [12:26] of the NodeJS and so on I mean seems [12:29] like an easy win and low hanging fruit [12:31] for us but maybe super learn for other [12:33] projects especially the ones that are [12:35] you know keeping um legacy support for [12:38] NodeJS uh probably talking about express [12:41] and probably on that way where where you [12:43] might not be able to you know just jump [12:45] major versions of your dependencies but [12:47] you are not affected by them. So this is [12:48] a way to document as a maintainer and [12:50] say like look I am aware of this CB but [12:52] it's not affecting because this isn't [12:53] whatever I mean we are exploring this [12:55] tool as a new thing. The idea is just to [12:56] bring this to the forum and see if [12:58] others has experience with this or want [13:00] to adopt this and just came up to the [13:02] security working group meeting and see [13:03] what happened there. Uh Chris [13:08] >> um yeah to what extent would you be [13:12] using it? Um what I mean by that is like [13:15] will active and maintained versions of [13:18] node include [13:21] vex records [13:23] or would this be only end of life node [13:25] versions? [13:27] >> Uh only the active uh versions uh and [13:30] also uh to to be honest we already [13:33] maintain that we already have a JSON [13:35] file that we uh we use for the is my [13:39] node vulnerable. uh the difference is [13:41] that it will now include the CVS for [13:43] Node.js dependencies. So in case uh [13:47] OpenSSL release a new uh new secret [13:50] issue uh a new secret release and uh we [13:53] have an repositor already that is called [13:55] Node.js dependency vulnerability [13:57] assessment where whenever a new uh [14:00] public CV is found in an active version [14:03] of Node.js an issue is open. The [14:05] difference is that the resolution of [14:07] that issue instead of being closed uh [14:10] with or assessment is to put that CV [14:13] into the vax file with or assessment. [14:20] >> Okay. [14:21] Um [14:24] for let me ask this [14:27] uh [14:29] for where you have a vulnerable [14:33] dependency. [14:36] um [14:38] will it ever be the position of the [14:41] project to not patch the component and [14:46] instead say we're not going to patch it [14:49] but we're not affected by this [14:51] vulnerability. [14:52] >> Yes, we we do that. Uh [14:54] >> okay. [14:55] >> Uh it's not it's not common to say that [14:58] we are not we won't patch it. We [15:00] normally say this doesn't affect [15:02] Node.js. So accummit upgrading this [15:05] dependency will follow the regular nojs [15:09] release instead of a secret release. [15:11] >> So the the tricky thing with open vex uh [15:15] or with vex in general not I don't know [15:17] why I said openvex um that's another [15:19] format. Um, the tricky thing with Vex [15:22] and things that do the same thing is [15:25] that when you say that you're not [15:28] vulnerable, um, you're it's really like [15:32] you're saying that it's it's like a [15:34] snapshot. You're not vulnerable right [15:36] now. You're not vulnerable today, but [15:38] tomorrow a pull request could be merged [15:40] that leverages like the vulnerable [15:42] function. like let's say it's a function [15:44] that's vulnerable or something like [15:45] tomorrow some new code can go in some [15:47] new code change and now your um vex data [15:51] is incorrect. Um and so my question is [15:58] what like is this a problem that you've [16:01] that that you've thought about or is [16:03] there I don't know some sort of like [16:05] ongoing review or something of of VEX [16:08] information to make sure it's still [16:10] accurate or [16:11] >> I don't know. we we always patch the [16:13] dependency. So uh I think for for those [16:16] situations like we could create some uh [16:19] in in case of uh maintainers uh release [16:22] line of Node.js that gets uh that will [16:25] uh we decide okay we will not patch [16:27] that. I think we uh need to create a [16:30] monitor uh for that particular CVE. uh [16:34] whenever we release a new version of [16:36] NodeJS we need to assess if that vax is [16:39] still up to date uh that that assessment [16:42] is still up to date but uh usually we [16:45] say it doesn't affect NodeJS but we [16:48] still upgraded the dependency so I [16:50] believe that the vax will be up to date [16:53] most of the time but we need to add like [16:55] a footnote uh to users that things like [16:58] that might happen yes [17:00] >> yeah no that makes sense um yeah so it [17:03] sounds it could be a pretty small window [17:05] of opportunity for anything to slip [17:07] through anyway given all those things. [17:09] Um, [17:11] but aside from, you know, people that [17:12] just won't upgrade. Um, but we can't [17:15] save them from themselves. Um, hopefully [17:17] they upgrade. [17:26] >> Any other questions or feedback on VEX? [17:33] Um [17:34] you said you've you've already you're [17:36] already maintaining [17:38] Cyclone DX vex records. Did I understand [17:42] correctly? [17:43] >> No. Uh as far as I know we don't [17:46] maintain Cyclone DX. We we have our own [17:48] JSON file for Node.js uh uh for Node.js [17:52] JS CVs and we have this repository uh [17:55] that I'm going to send in the chat which [17:58] is uh the automation I I told that uh [18:02] whenever a public CVE is found in one of [18:05] our dependencies one issue is created [18:08] and then we create an assessment. [18:12] >> Okay. Okay. That's what you were [18:13] referring to that you were already [18:14] doing. Okay. Thank you. Yeah. [18:20] >> Well, uh that is the end of our official [18:23] agenda. So, any other topics uh for [18:26] discussion or anything else anyone wants [18:29] to mention? [18:36] Okay, got a couple to-dos. We want to [18:38] get the security response plan merged. [18:40] So, for those of us that are tagged in, [18:43] um, yes, Wes, [18:45] >> uh, just want to quick announcement. I'm [18:46] going to try to go to the Monday or [18:51] sorry, it's not Monday. Today's Monday. [18:52] Uh, I think it's Wednesday. Um, securing [18:55] open source registries call if anybody [18:59] wants to join. Let me just double check. [19:01] I had gotten the calendar from Robin. It [19:03] is on Oh my god, my calendar. [19:06] >> 6 a.m. Pacific on Wednesday. [19:07] >> 6 a.m. Pacific. Yep. Wednesday. Um, so [19:10] they have a they have a calendar um if [19:12] anybody would like to join. I'm going to [19:14] try to get uh an issue put together. I [19:15] was hoping today um to just talk next [19:18] steps on some of the trusted publishing [19:20] stuff. Um might be tomorrow that I open [19:22] the issue, but [19:26] I added it to the to the doc. Yeah, we [19:28] can get anyone added to the invite if [19:29] they want it officially on their [19:30] calendar. [19:32] Okay, on that note, I think we're good. [19:36] Um good to see everyone. reach out if [19:38] you need anything. See you next week.