Security Collab Space Meeting - August 18, 2025

Security Collab Space Meeting - August 18, 2025 🔗 **Source:** [Security Collab Space Meeting - August 18, 2025](https://www.youtube.com/watch?v=CAxNo5OsAHI) > [!note]+ Document Notes > tags: [security, agentic-ai, dependency-management, openjs-foundation, vulnerability-disclosure] > author: OpenJS Foundation Security Collab Space > source: YouTube > reference: https://www.youtube.com/watch?v=CAxNo5OsAHI > date created: 2024-12-19 14:30 > > # 🏷️ Title: Security Collab Space Meeting - August 18, 2025 >  ## 🧰 Action Inbox - [H1] Install FASA bot for dependency analysis — GitHub admin required #security #dependencies - [H2] Create minimal VDP template — Chris volunteering this week #vulnerability-disclosure - [H3] Schedule quarterly town halls starting September — coordination with Kylie #community-outreach ## 🧭 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 - [FASA Agentic Dependency Updater](URL) - [OpenJS Security Policies](URL) ## 📝 Summary - OpenJS Security Collab Space meeting featuring FASA demo of agentic dependency updater - Discussion of incident response planning and vulnerability disclosure policies - Community outreach initiatives including quarterly town halls and blog posts - Focus on improving project onboarding requirements and security policy templates - Collaboration opportunities with enterprise security tooling providers ## 📖 Main Content The meeting covered three main areas: a demonstration of FASA's agentic AI tool for dependency management, development of security incident response procedures, and improvements to project onboarding requirements. FASA's tool uses Anthropic's AI models with enterprise agreements to analyze dependency updates and provide automated fixes, moving beyond simple vulnerability identification to actual code changes. The security team is developing standardized incident response plans and minimal vulnerability disclosure policies to help projects manage security issues more effectively. There's ongoing work to improve community engagement through regular town halls and clearer communication channels. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/CAxNo5OsAHI?t=0) — [H1] Meeting introduction and recording notice - Key idea: Weekly Security Collab Space meeting with special guest Rob from FASA - Evidence: "Morning folks. Welcome to the August 18th Security Collab Space weekly meeting" #### ⏱️ [02:30](https://youtu.be/CAxNo5OsAHI?t=150) — [H2] FASA background and acquisition announcement - Key idea: FASA acquired Edgebit for dependency-specific static analysis technology - Evidence: "I actually joined FASA as part of an acquisition of my company that was called Edgebit" #### ⏱️ [05:15](https://youtu.be/CAxNo5OsAHI?t=315) — [H1] Agentic dependency updater demonstration begins - Key idea: AI tool outperforming human engineers at dependency updates - Evidence: "It pretty rapidly started doing a better job than our human engineers" #### ⏱️ [08:45](https://youtu.be/CAxNo5OsAHI?t=525) — [H2] JavaScript/TypeScript focus with expansion plans - Key idea: Currently limited to JS/TS but expanding to Java and Python - Evidence: "This is JavaScript and TypeScript specific right now which is why this audience is a really great fit" #### ⏱️ [12:20](https://youtu.be/CAxNo5OsAHI?t=740) — [H3] Three categories of dependency analysis - Key idea: Tool handles minor patches, safe breaking changes, and actual breaking changes - Evidence: "We handle these really minor patch bumps. We find safe breaking changes and then we can fix breaking changes" #### ⏱️ [15:30](https://youtu.be/CAxNo5OsAHI?t=930) — [H2] Prettier example - simple upgrade - Key idea: Automated analysis shows no breaking changes for dev dependency upgrade - Evidence: "Not much to see here. There's no breaking changes. This is all good. You should merge this" #### ⏱️ [18:10](https://youtu.be/CAxNo5OsAHI?t=1090) — [H2] Mock upgrade with Node.js compatibility check - Key idea: Tool validates Node.js version compatibility for major releases - Evidence: "This is mostly related to dropping support for NodeJS below 18" #### ⏱️ [22:45](https://youtu.be/CAxNo5OsAHI?t=1365) — [H2] Amazon SDK complex migration example - Key idea: Tool identifies and fixes specific breaking changes affecting codebase - Evidence: "We use Minio to mock out S3 and some of this checksumming that they changed is actually going to break our development flow" #### ⏱️ [26:30](https://youtu.be/CAxNo5OsAHI?t=1590) — [H3] Anthropic enterprise agreement for analysis - Key idea: Uses Anthropic models with no training on customer data - Evidence: "We use Anthropic and have an enterprise agreement with them. So there's no training on the data" #### ⏱️ [30:15](https://youtu.be/CAxNo5OsAHI?t=1815) — [H2] GitHub integration and workflow - Key idea: Simple GitHub bot installation with existing workflow integration - Evidence: "Just logging into there. It's going to bump you over to GitHub to install it and then you can configure which repos" #### ⏱️ [35:20](https://youtu.be/CAxNo5OsAHI?t=2120) — [H1] Incident response plan discussion begins - Key idea: Ulyses presents draft incident response plan for foundation support - Evidence: "I created a small PR which is the 289. It's not officially ready to review. It's more like a first iteration" #### ⏱️ [38:45](https://youtu.be/CAxNo5OsAHI?t=2325) — [H2] Incident categories and scope definition - Key idea: Focus on platform changes, account access issues, supply chain attacks, not CVEs - Evidence: "Anything related to vulnerabilities in the level of CVEs should be done on the project or worst case scenarios will be escalated to the CNA" #### ⏱️ [42:10](https://youtu.be/CAxNo5OsAHI?t=2530) — [H3] Minimal VDP template assignment - Key idea: Chris volunteers to create minimal vulnerability disclosure policy template - Evidence: "I can take a stab at this one. Really you want something that covers how do people submit vulnerabilities" #### ⏱️ [45:30](https://youtu.be/CAxNo5OsAHI?t=2730) — [H2] Community outreach and blog post planning - Key idea: Need better communication about available security support resources - Evidence: "We meet every week and oftentimes we're talking about how difficult it is or how we don't hear from projects" #### ⏱️ [48:15](https://youtu.be/CAxNo5OsAHI?t=2895) — [H1] Quarterly town hall proposal - Key idea: Regular quarterly meetings to update projects and gather feedback - Evidence: "We could think about doing a quarterly town hall. So something a little bit more regular" ## 📚 References - [FASA Enterprise Solutions](https://fossa.com/) - [OpenJS Foundation Security Policies](https://openjs.org/security/) - [GitHub Security Advisory Process](https://docs.github.com/en/code-security/security-advisories) ## 🗣️ Paraphrase - FASA demonstrated an AI-powered tool that automatically analyzes and fixes dependency updates, going beyond vulnerability identification to provide actual code changes and migration assistance - The Security Collab Space is developing standardized incident response procedures to help projects get foundation support for security issues outside of traditional CVE processes - Community engagement efforts focus on quarterly town halls, improved documentation, and clearer communication channels to connect projects with available security resources ## 📰 Newsletter The OpenJS Security Collab Space is making significant strides in automated security tooling and community support. FASA's new agentic dependency updater represents a breakthrough in moving from vulnerability identification to actual remediation, using enterprise-grade AI to analyze complex dependency upgrades and provide working code fixes. This is particularly valuable for JavaScript and TypeScript projects dealing with the constant churn of dependency updates. The team is also strengthening incident response capabilities with new standardized procedures and minimal vulnerability disclosure templates, making it easier for projects to handle security issues effectively. Regular quarterly town halls will improve communication between the foundation and projects, ensuring security resources reach those who need them most. Resources: [OpenJS Security](https://openjs.org/security/), [Security Collab Space](https://github.com/openjs-foundation/security-collab-space), [Vulnerability Disclosure](https://github.com/openjs-foundation/cross-project-council/blob/main/PROJECT_PROGRESSION.md#security-policy) ## ✅ Action Items #### DevRel - Developer advocacy: Present FASA tool benefits at JSConf and other events - Education: Create workshop content on dependency security best practices - Developer experience: Improve onboarding documentation for security tools - Community management: Facilitate quarterly town halls and feedback sessions #### OSPO - Policy & Governance: Review and update project onboarding security requirements - License Compliance: Integrate dependency license scanning into onboarding process - Security Management: Implement incident response procedures and minimal VDP templates - Software Inventory: Track security tool adoption across foundation projects - Developer Support: Provide guidance on vulnerability disclosure and CVE processes - Community Engagement: Coordinate with FASA and other vendors for foundation benefits - Strategic Alignment: Measure security posture improvements across projects #### Community - Maintainers: Provide clear escalation paths for security incidents beyond CVEs - Contributors: Train on security best practices during onboarding - Sponsors: Demonstrate security value through dependency management improvements - Ecosystem: Coordinate cross-project security initiatives and shared tooling #### WordPress - Core: Evaluate applicability of agentic dependency management for WordPress ecosystem - Security: Adapt incident response procedures for WordPress-specific platform issues - Community: Share learnings from OpenJS security initiatives with WordPress security team - Documentation: Create WordPress-specific security policy templates based on minimal VDP work ## 🧪 Hypotheses - Agentic AI tools can reduce dependency update backlog by 60% through automated analysis and code fixes - Standardized incident response procedures will reduce average resolution time for non-CVE security issues - Quarterly town halls will increase project participation in security initiatives by 40% - Minimal VDP templates will improve vulnerability reporting quality and response times ### 📊 Methodology - Study design: Track dependency update metrics before and after FASA tool deployment - Data sources: GitHub PR analysis, maintainer time surveys, security incident logs - Experiments: A/B test different communication approaches for security resource adoption ### ❓ Questions - How can agentic dependency management be adapted for non-JavaScript ecosystems like WordPress? - What metrics best measure the effectiveness of foundation security support services? - How do we balance automation with human oversight in security-critical dependency updates? ### 🔮 Future Research - Integration patterns for AI-powered security tools in open source workflows - Effectiveness of different vulnerability disclosure policy approaches - Community engagement strategies for security initiatives across diverse project types ### 💡 Implications - Practice: Projects can automate routine dependency maintenance while focusing on feature development - Policy: Foundation onboarding requirements may need updates to reflect new security tooling capabilities - Security: Reduced dependency lag times improve overall ecosystem security posture - Education: Need for training maintainers on AI-assisted security workflows - Funding: Budget considerations for enterprise security tooling partnerships ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12-14 (technical content with specialized terminology) #### 👀 Visual learners - Present: GitHub PR screenshots, mermaid diagrams for incident response flow - Improve: Architecture diagrams showing tool integration, security workflow visualizations #### 🔊 Aural learners - Present: Live demo format with verbal explanations - Improve: Audio summary of key takeaways, recorded walkthrough guides #### 🗣️ Verbal learners - Present: Clear definitions of agentic AI, dependency management concepts - Improve: Glossary of security terms, analogy-based explanations #### 🧩 Kinesthetic learners - Present: Interactive GitHub bot installation process - Improve: Hands-on labs for incident response procedures, security policy templates #### 🧠 Logical learners - Present: Step-by-step incident response flowchart, categorized analysis types - Improve: Decision trees for security tool selection, KPI dashboards #### 🧑‍🤝‍🧑 Social learners - Present: Collaborative meeting format, community discussion - Improve: Peer review processes for security policies, mentorship programs #### 🧘‍♀️ Solitary learners - Present: Self-service bot installation, async PR review - Improve: Self-assessment checklists, independent learning paths #### 🌿 Naturalistic learners - Present: Ecosystem thinking about dependency relationships - Improve: Supply chain analogies, sustainability considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in meeting notes - Improve: Alt text for GitHub screenshots, ARIA labels for interactive demos #### Keyboard navigation - Present: GitHub interface keyboard accessibility - Improve: Tab order documentation for security workflows #### Contrast and readability - Present: Standard meeting format with clear speaker identification - Improve: High contrast mode considerations for security dashboards #### Media and captions - Present: Meeting recording with transcript - Improve: Live captions during demos, downloadable transcripts ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global open source project perspective - Improve: Multi-timezone meeting options, regional security considerations #### Inclusive language - Present: Technical terms clearly defined - Improve: Plain language summaries, avoid security jargon #### Representation - Present: Diverse technical perspectives from different projects - Improve: Include perspectives from underrepresented communities in security #### Psychological safety - Present: Collaborative problem-solving approach - Improve: Clear escalation paths, supportive community guidelines ### ✅ Logical Validity #### Strong reasoning - Deductive strength: FASA tool outperforms humans → dependency backlog reduction (strong with evidence) - Inductive strength: Pattern recognition from enterprise use cases → open source applicability (moderate) - Causal reasoning: Better communication → increased security resource adoption (logical but needs validation) #### Fallacies - Appeal to novelty: "New AI tool is better" - needs empirical validation - Hasty generalization: Enterprise success → open source success assumption #### Tone of voice - Overall tone: Collaborative and solution-focused, appropriate technical depth for audience ### 🛡️ DARVO Analysis - Deny: No significant denial patterns observed - Attack: No attacks on accusers present - Reverse victim/offender: Not applicable to this technical discussion - Emotional cues and rhetoric: Professional, collaborative tone throughout ## 🎯 Conclusion The OpenJS Security Collab Space is advancing on multiple fronts: automated dependency management through AI partnerships, standardized incident response procedures, and improved community engagement strategies. The FASA collaboration represents a significant step toward practical security automation that addresses real maintainer pain points. Success will depend on effective integration with existing workflows and continued community feedback to refine these approaches for open source contexts. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Agentic AI outperforms humans at dependency updates > [!quote] [Security Collab Space Meeting](https://www.youtube.com/watch?v=CAxNo5OsAHI) by --- ## Full Transcript [00:11] Hey, Rob. [00:14] >> Hello there. How you doing? [00:16] >> Good. How are you? [00:18] >> Not too bad. Happy Monday. [00:20] >> Yeah. [00:27] Let's see here. [00:29] Just be aware we're we're recording this [00:31] one. [00:31] >> Yeah. [00:32] >> Yeah. Uh we can Are are you okay having [00:35] your presentation uh recorded? Is that [00:38] >> Yeah, that's fine. Yeah. [00:39] >> Oh, perfect. Okay. [00:44] >> Hey, Robin. [00:45] >> Hey there. [00:51] >> Are you looking to stop the recording, [00:54] Ben? [00:55] >> Yeah. [00:58] Morning folks. Welcome to the August [01:00] 18th Security Collab Space weekly [01:02] meeting. Uh today we've got special [01:04] guest Rob who's going to give us a demo. [01:08] So Rob, I will hand it to you. [01:11] >> All right. Um a little preamble first [01:12] before we get to the demo. Um, FASA has [01:16] been working on, you know, we're big in [01:19] um, both the sea space and license [01:21] compliance space um, and have provided [01:24] um, mostly license compliance um, [01:27] services or subscriptions um, to OpenJS [01:30] and a number of other open source [01:31] projects. Um, and so wanted to come here [01:34] today to talk about something new that [01:35] we're working on, which is all right, [01:37] it's great that you can like, you know, [01:38] identify um, vulnerabilities, for [01:40] example, in like the SCA space, but how [01:42] can you actually help me fix them? Um, [01:44] we've been working on an agentic [01:46] dependency updater to actually solve [01:48] that problem. Um, and so, uh, wanted to [01:51] tell you a little bit more about that. [01:52] Um, how we got here, and then I'll show [01:54] you a demo. And what we would like to do [01:56] is um we've been talking with a number [01:58] of enterprises about you know this use [02:00] case inside um but also wanted to engage [02:03] more open source stuff both give back [02:04] and help folks merge uh dependencies [02:07] faster um get you some maintainer time [02:09] back I know that's you there's always a [02:10] time crunch there um but then we would [02:12] love to learn about like kind of oss [02:14] specific use cases in this um I think we [02:16] have a pretty good handle on the [02:17] enterprise side um so a little bit of [02:19] give and take I think it's a pretty [02:20] symbiotic um relationship [02:24] um so I'll give you a a little bit of [02:25] background on how we got here. Um so, uh [02:28] FASA wanted to just address this topic [02:31] internally. Um we have our own software [02:33] just like anybody else. We spend a lot [02:34] of time on dependency updates. We have a [02:36] lot of knowledge about um dependency [02:38] graphs and uh direct and transitives and [02:40] all the stuff that comes along with [02:42] that. Um so we thought we were well set [02:43] up to do this and so we started building [02:45] out this agentic framework. Um it pretty [02:48] rapidly started doing a better job than [02:50] our human engineers. Um and so we said, [02:52] you know, there's actually something [02:53] here. Um and so um then FASA kind of [02:56] turned and got real serious about this [02:58] and you know we wanted to start [02:59] developing it into a product. Um I [03:01] actually joined FAA um as part of an [03:04] acquisition of my company that was uh [03:06] called Edgebit that was working on some [03:07] dependency specific static analysis [03:10] tech. Um and so um that hasn't been [03:13] announced yet but it's fine for this [03:14] recording. Um and so um that was kind of [03:17] proof point one of philos. Number two [03:19] was building out a really big ground [03:21] truth data set um to evaluate ourselves [03:24] against. Um and so we kind of used the [03:28] um static analysis as like a grounding [03:30] point for facts about code bases so that [03:32] the you know the AI is not hallucinating [03:34] all this stuff. Um and we use our [03:36] agentic thing for its kind of um its [03:39] detail oriented uh nature and it's [03:41] really good at researching things. Um [03:43] but we kind of ground it in the ground [03:45] truth and the static analysis results. [03:47] Um so anyways building out that set and [03:49] we want to keep doing that as well. And [03:50] so um as open source projects do major [03:54] uh migrations between things and write [03:56] up migration guides and document [03:58] breaking changes we would love to keep [03:59] adding that to our data sources. Um I [04:02] will admit this is JavaScript and [04:04] Typescript specific right now which is [04:05] why this audience is a really great fit [04:07] for this. We'll expand to Java and [04:09] Python and other stuff over time. Um, [04:11] it's that ground truth data set that [04:12] takes a long time to actually build up. [04:14] Um, and we have that for JavaScript, [04:16] TypeScript. Um, so I'll pause there [04:18] really quick. Does the the premise make [04:20] sense why we're here? And, uh, kind of [04:23] the background, [04:27] head nods. Sounds good. [04:28] >> Yeah. Chris Chris just joined. Chris, uh [04:32] just um a quick summary, we have Rob [04:34] from FASA here who's demoing a new [04:37] product in development [04:39] uh using Agentic AI. [04:42] >> Yeah, this is an AgentIC um dependency [04:44] updater. Um so we want to, you know, [04:46] take either SCA scan results or license [04:49] issues or anything that you have in your [04:50] codebase and actually help you with [04:52] completed work items. I would say maybe [04:54] the an interesting thing for this [04:56] audience is we've kind of found that [04:57] these actually devolve into pretty [04:59] complex engineering tasks basically like [05:02] the first minute you encounter one of [05:03] these upgrades. Um unless it's like a [05:05] very minor um you know bump to a patch [05:08] release or whatever. There's always you [05:09] know uh call site adaptation or a lot of [05:12] research that needs to be done and you [05:13] just basically backlog this stuff [05:15] forever because it's just too much work [05:17] to even do all that work. Um so you [05:19] don't even know what you don't know and [05:20] so you just backlog it. So we want to [05:22] fix that. [05:22] >> Yeah. And you're starting with [05:24] JavaScript, TypeScript, moving to other [05:26] languages later. You've um already [05:28] offered it to a few of our projects as [05:30] well. Um [05:32] >> correct. [05:32] >> Which I've sent some emails out last [05:34] week. [05:35] >> Yes. Um and so the other uh thing to [05:37] know about where we're getting started [05:39] is um we are right now um because of our [05:42] kind of the enterprises have done a lot [05:44] of um uh effort and setting up [05:47] dependabot renovate sneak all these uh [05:49] updators. We're actually piggybacking on [05:51] those PRs right now. We'll move on to [05:53] making our own PRs and and based on our [05:56] better analysis, but um so um I [05:59] identified Appium, Webpack, jQuery as [06:02] folks that are already using these [06:03] updators today, but if there's more, [06:05] we're glad to get everybody involved. Um [06:07] and for folks that don't have those [06:09] tools set up, um you know, we'll be able [06:10] to um address those needs as well. Um so [06:13] I want to show you just three kind of [06:15] interesting um categories of analysis [06:17] that we can do. Um this is a prettier, [06:20] you know, it's a dev dependency of [06:22] course. Um and not a crazy bump here [06:25] from 41 to 42. Um we saw this um PR get [06:29] posted. We did some automatic analysis [06:30] and said, "Hey, not much to see here. [06:32] There's no breaking changes. Um this is [06:34] all good. You should merge this." Um so [06:36] I'm sure we're all familiar with this. [06:38] These are just the waste of time bumps. [06:41] Um something that's a little bit more [06:42] interesting. Um this is a knock upgrade [06:44] from 13 to 14. So um depending on how [06:48] they do semantic versioning pretty major [06:49] release um depend about here [06:52] compatibility unknown not very helpful [06:54] um so I don't know what to do here um [06:56] but uh foss does um so we spent you know [07:00] 37 minutes thinking about this most [07:02] that's doing some of the static analysis [07:04] and and doing research um this is mostly [07:07] related to uh dropping support for um [07:10] NodeJS below 18 um so we went through [07:12] and you know made sure on that safe [07:15] breaking change Here we, you know, we [07:16] always want to show our homework for [07:18] like what we actually did. This is how [07:19] we validated that we're not using those [07:21] deprecated versions of Node.js and [07:23] you've got references to the the code [07:25] and things like that. Um, and so again, [07:29] this is safe to upgrade. You should go [07:31] upgrade this. [07:33] Um, something that's a little more [07:34] exciting, um, this is a a grouped um, [07:36] update of a bunch of Amazon SDKs. Um so [07:39] you know versions to versions um but has [07:43] uh things to do with um this S3 um [07:45] client and this one we actually said hey [07:48] there's actually some significant [07:50] behavioral changes here that are going [07:51] to affect the way that you use this [07:53] dependency not the way everybody uses [07:55] this but this is specific to the [07:56] codebase we're looking at. Um we use [07:58] Minio to uh mock out S3 and for some [08:01] development use cases and some of this [08:04] um check summing that they changed is [08:05] actually going to break our development [08:06] flow. Um and so Fosabot um understood [08:10] that and then said, "Hey, we actually [08:12] need to come up with a migration plan [08:13] here." And what it did is actually go [08:16] and turn off that new checkum [08:17] calculation so that we didn't break our [08:19] dev flow. So it made some commits here [08:22] um that you know end up as part of this [08:23] pull request and then you can you know [08:25] go review and change that. Um again with [08:28] all of the um the homework here for you [08:30] know our eight um fixed breaking [08:32] changes. This is the ones that we [08:33] addressed with these commits. Um, and [08:34] then there were eight others that were [08:36] just safe that we, you know, don't need [08:38] to care about. Um, so that's like kind [08:40] of the broad strokes of like we handle [08:42] these really minor patch bumps. We find [08:44] safe breaking changes and then we can [08:46] fix breaking changes. Um, fourth thing [08:49] will be, hey, an engineer needs to also [08:51] look at this. Um, you know, there's [08:53] something about stylistically that how [08:55] do you want to handle this? Um, and [08:57] we'll get better and better at those [08:58] over time. [09:00] Um, so was there any questions on any of [09:02] these um, PRs? Does it seem like it [09:04] would be useful um to the maintainers on [09:06] all these projects? And um you know, our [09:09] ideal case would be that you're just [09:11] continually merging stuff so that you're [09:13] never falling behind on dependencies. Um [09:15] so it keeps the security posture um just [09:18] that much more fresh and uh close to the [09:20] tip. Um so that you don't have to [09:22] scramble when these big uh issues come [09:24] up. So but I'll pause there. um [09:27] questions. [09:37] >> I'm curious what are you doing the [09:39] analysis with? Like are is it [09:42] >> are you using chat GPT on the back end? [09:44] Are you using anropic where [09:47] >> where are you pulling the stuff from? [09:49] >> Um so we use anthropic um and uh have an [09:53] enterprise agreement with them. So [09:54] there's no uh training on the data. Um, [09:57] and so, um, yeah, so we do our static [10:00] analysis, crunch some things, see what [10:02] the call sites we care about, and then [10:03] we're sending over, you know, snippets [10:05] of code, not like the entire codebase [10:07] obviously, um, over to, um, Anthropic [10:09] right now. And we use a variety of [10:12] models for, you know, depending on, um, [10:14] which step we're in, which is, uh, best [10:16] suited for it. [10:20] And ideally, how do you see yourself [10:22] working best with the like the technical [10:25] steering committees of these projects? [10:28] >> Um, I think we so we would love to like [10:30] help speed up maintainers merging [10:32] dependency updates to keep those [10:33] projects more secure to keep their [10:35] dependency trees fresh, pruned, you [10:37] know, um, as streamlined as they can be. [10:39] Um and so I think what that looks like [10:41] in the immediate term is just um getting [10:44] uh connected to the org and the GitHub [10:46] or and then turning on auto analyze so [10:48] that they just get these analyses [10:50] directly on dependabot PRs hopefully [10:53] help people merge those faster um and [10:55] then over time as we get more [10:56] sophisticated um engaging with those [10:58] more sophisticated updates where we [10:59] would you know potentially roll up a [11:01] bunch of dependency updates that are all [11:03] not breaking into one PR and you know [11:05] kind of things like that. [11:11] Um but yeah, we're pretty excited about [11:12] it. Like we said, um it's been kind of [11:15] outpacing our um human engineers and [11:18] we've previously had things that were on [11:20] the backlog, these major migrations that [11:22] we actually found out look really major, [11:24] but you know, we're touching near a [11:26] bunch of deprecated APIs and all these [11:27] things, but then the bot says, "Hey, [11:29] you're actually using these in forward [11:30] compatible ways. There's nothing to [11:32] worry about here." And so we pulled [11:33] things off the backlog and merged it [11:34] whereas before it would just gone to the [11:36] black hole and never got in touch ever [11:38] again. So I'm sure um these projects [11:41] have those as well and we'd love to help [11:42] out with that. [11:47] >> Um yeah, and so all this is is is live [11:49] and ready to go. Um and so it's just uh [11:52] whoever's a GitHub admin needs to [11:54] install the app and then uh we're off [11:55] for the races. [12:00] any other um like for folks that are [12:03] looking to um to try this out, is there [12:06] anything else in addition to that that [12:07] they need to do or anyone they need to [12:09] reach out to or they just really need to [12:10] install the bot [12:11] >> and that's it? [12:12] >> Yep. Um our web app kind of walks you [12:14] through installing the the bot. So it's [12:16] just logging into there. It's going to [12:18] bump you over to GitHub to install it [12:19] and then you know you can configure [12:21] which repos you want the auto analyze [12:23] on. Um, we can also test it out um, just [12:25] by you can comment at the bot and get [12:27] analysis kind of whenever as well. [12:30] >> Yeah, it's pretty simple designed to be [12:32] um, you know, other than the person that [12:33] sets it up, everybody can just interact [12:35] with it through GitHub. Um, there's no, [12:37] you know, meet you where you are and the [12:39] way that the the workflow is already set [12:41] up and you know all the um, if you need [12:45] to have x number of people um, approve [12:47] stuff before merging and all that stuff [12:48] at all, none of that needs to change. [12:50] So I did send intros to the maintainers [12:53] introducing Rob and Kevin from FASA to [12:56] Webpack, Appium and ESLint [12:59] uh core maintainers. So I guess if [13:01] there's anyone else but you did if you [13:03] join our Slack sometimes that's the [13:06] faster way to probably connect with [13:08] people. [13:08] >> Okay. I did join the Slack. I haven't [13:10] joined any or investigated what channels [13:12] to best join. But I guess maybe my [13:13] question for y'all is how do you [13:15] interact with those technical [13:17] committees? How does this group [13:20] you sort of sometimes meet them where [13:22] they are. That's something we're always [13:24] trying to do better. We sort of do a [13:25] combination [13:27] >> um Slack seems to be more efficient than [13:29] email. Um opening issues sometimes. Um [13:33] but yeah, just knowing that they're uh [13:36] that you've sort of gone and spoken to [13:38] this group is pretty helpful. Uh Rafa [13:41] and Ulysus are um part of our Alpha [13:44] Omega project and they're trying to help [13:46] uh the other projects as well. Uh so [13:49] this is good for them to know. [13:52] >> Cool. Yeah. Well, we're happy to kind of [13:54] um make it happen however folks want to [13:57] uh be engaged with. Um and yeah, just [14:00] with the ultimate goal of saving folks [14:02] time so they can work on more important [14:04] stuff. [14:06] >> Cool. [14:09] Um have there been any other kind of [14:11] security related projects that y'all [14:12] have driven through um in the past like [14:14] six months like in the beginning of this [14:15] year? Anything? I'm just curious to get [14:18] a sense of um surface area and stuff [14:22] like that. [14:24] >> Um what do you mean by security project? [14:26] >> Well, this is just like the the group [14:28] that's interested in security just like [14:30] how have you helped push these um these? [14:33] >> We did launch recently launched a CNA. [14:35] So that's something that's being pushed [14:36] out. We have some security compliance [14:38] guidelines that we're pushing out. Um [14:42] those are the things that are sort of [14:44] originating here and then going into the [14:46] projects. We also launched a security [14:48] training uh that for us and the socket [14:51] our socket friends uh produced for us. [14:53] But uh [14:54] >> those are kind of the big ones. [14:57] >> So it sounds like each group kind of [14:58] gets to do their own thing. You have [15:00] some guidelines but they're not like you [15:02] know prescriptive or in in the way that [15:04] they're mandatory [15:05] >> sort of. So I there's there's a caveat [15:08] there which is um this group works with [15:11] the um the CPC the cross project council [15:15] which is the equivalent of the open js [15:18] tac right so it's made up of um various [15:22] stakeholders from various projects and [15:24] that project does maintain some [15:27] mandatory guidelines um the most [15:30] important is when joining the foundation [15:32] so when when projects join the [15:34] foundation there's a list of things that [15:35] they have to do, right? They have to [15:37] have specific licenses. They have to [15:39] have um code of conduct and there are [15:42] some security things in there and I [15:44] think one output from this group in the [15:47] not too distant future will be u making [15:49] updates to those uh guidelines. [15:52] >> Um so that's another area of influence [15:55] um over the projects. [15:57] >> Cool. Makes sense. [16:00] Any [16:03] other comments, feedback for Rob? [16:08] >> Anything as you list also is on express [16:10] and rafa on node. [16:14] Any project feedback on that? Yeah, I [16:17] think I think it's a it's a useful tool [16:20] uh because yeah, as you said before like [16:21] depend about half of the time is like [16:24] even for trivial changes you need to go [16:26] to the change log and go by detail even [16:28] if the CI is passing it's like maybe [16:30] there is something that can break people [16:32] later on. Um so yeah I think it's going [16:34] to save uh some time uh yeah depending [16:37] on the perspective I think there's also [16:38] an open discussion going on on uh [16:41] artificial intelligence um comments [16:43] generated stuff on PRs and things like [16:45] that like in terms of of how we should [16:47] interact with this tooling there's going [16:48] to be like a new collab space dedicated [16:51] to that um that being said because last [16:53] week we had the demo in the in the [16:55] express uh TC uh working session uh [16:58] regarding code rabbit and it was a [17:00] interesting demo but also we have a lot [17:02] of uh discuss discussing around if if [17:04] these kind of comments are okay or not [17:05] dependent on the on the community that [17:07] are participating and the target and so [17:09] on. So in terms of maintainer as tool [17:11] for maintainer I think it's useful [17:12] because can save you time. I think it's [17:15] not 100% like replacement for the human [17:17] validation. There's going to be some [17:18] validation but I think the information [17:20] there is useful to validate your own you [17:22] know understanding of the tooling and [17:24] stuff especially for the typical dev [17:26] dependencies that you are not 100% align [17:29] of what's going on. For example, my case [17:30] with prettier when we use it, it's like [17:33] h yeah most of the time and I like the [17:35] changes and I go ahead, right? But with [17:37] this uh we might go with a deeper [17:39] detail, right? Um so yeah, I think it's [17:41] a good approach and has a good potential [17:43] for saving time. [17:45] >> Awesome. [17:47] Yeah, I would like to see this in action [17:50] on express and fast 5 first before uh [17:54] checking it on Node.js because uh the [17:56] dependencies uh the way we handle [17:57] dependenc on OJS is like different as [18:00] they are not uh simple uh JavaScript [18:04] uh projects but you know uh C++ we have [18:09] uh tons of them. [18:14] Yeah, I'll admit we were um I I would [18:17] love to be on Node.js the project [18:20] itself, but um wanted to start small. [18:23] I know I know y'all do some tricky [18:25] things in in both of those projects. Um [18:29] >> so maybe I'll add Fastify to your mix if [18:32] that's cool, Rob. [18:33] >> Yeah. Yeah. [18:33] >> Okay. [18:34] >> Yeah, we actually use Fastify [18:35] internally. It's pretty nice. [18:36] >> Awesome. [18:41] Then if folks have questions for for [18:43] you, Rob, or for the project, what's the [18:45] best way for them to reach out to you or [18:47] to get help? [18:49] >> Um, yeah, reach out to me for all the [18:51] above and I can get you connected um [18:53] with whoever needs to be uh looped in. [19:03] All right, cool. Well, um you're more [19:06] than welcome to stick around if you'd [19:07] like the rest of our working group call. [19:10] Um and if not, then we will bid you a [19:13] do. But yeah, um we got a couple of the [19:15] things that we want to cover today. So, [19:17] let's move on to incident response plan. [19:23] So, I think Ulyses. [19:26] >> Yes. [19:29] >> Okay. Yeah. I like uh yeah, I I have a [19:32] small proposal. Okay. So, so here's the [19:34] deal. I I created a small PR uh which is [19:36] the 289. Oh, thank you Ben. It's not [19:40] like um officially jet I mean it's not [19:43] like a final version ready to review. [19:45] It's more like a first iteration. So my [19:47] idea was to um join the meeting today [19:50] explain a little bit how this is going [19:51] to work. Ideally most of the discussion [19:54] should happen as sync. So we can solve a [19:57] lot of questions within the week and [19:58] then if something is requires some like [20:00] sync discussion or something in the [20:02] meeting then we can address this in a [20:04] small five to 10 minutes spot in the [20:06] meeting until we have the final version [20:08] of this document. So um just for give [20:10] you some context the idea of this uh [20:12] incident response plan uh came some uh [20:14] time ago when we faced some challenges [20:17] with the GitHub UI and previous incident [20:19] in the past that we you know have [20:21] several ways to discuss it. The idea [20:22] here is more or less to try to [20:24] materialize an idea of how the [20:27] maintainers can reach out to the [20:29] foundation in the way of I need some [20:31] security support and is is not related [20:33] to CDE or something like that is more [20:35] related to GitHub UA chain something [20:37] that is completely outside of my area of [20:40] influence or something that happened to [20:42] me as as project or as a individual [20:45] maintainer and I need support with right [20:47] um the idea here also is try to see uh [20:51] within the foundation like how we should [20:53] address this kind of in incidents uh who [20:56] should be in charge of this in terms of [20:58] we should have a team or not also what [21:00] is the expectations in this in terms to [21:03] solving problems because as these kind [21:05] of problems can be super weird sometimes [21:08] uh so it's hard to say like yeah we [21:10] cannot I mean we are not going to change [21:12] the GitHub UI probably right but we can [21:14] provide feedback to the right group and [21:16] also we can ensure you other things or [21:17] just connect you to the right person on [21:19] GitHub for example I mean there's a lot [21:21] of networking from a website that I [21:22] think uh might be useful as a resource [21:24] in this kind of situation. So that was [21:27] more or less the idea. So in this PR you [21:29] can see um that there is a lot of [21:32] popcorn emojis. So all the popcorn [21:34] emojis basically are uh super up to [21:37] discussions. Uh everything here is not [21:39] set as a stone at all. I included also a [21:42] small mermaid uh diagram at the bottom [21:44] that might help you guide on the process [21:46] a little bit and also motivate Ben to [21:47] help me with this a little bit. I know [21:50] Ven is a great fan of mermaid uh [21:52] graphics. So yeah um this is the idea [21:54] basically if if you want to spend some [21:56] time um today or something like that [21:59] probably uh working on the incident [22:00] categories uh is the best option to [22:03] define like what we should consider in a [22:05] scope or not for this kind of uh [22:07] incident response plan. probably [22:10] something that we want to move outside [22:11] is obviously anything related to [22:13] vulnerabilities in the level of CVES um [22:16] you know security reporting and stuff [22:18] like that because that should be done on [22:20] the project or worst case scenarios will [22:22] be escalated to the CNA right so that's [22:25] not something expected from this group [22:27] that also reduce a lot the pressure from [22:29] the group in terms of you know uh [22:30] respond on time and things like that [22:32] right um so categories that I thought [22:35] that might be interesting um any [22:37] platform chains that might introduce a [22:40] risk to a project. That can be on [22:42] GitHub, that can be on npm, that can be [22:44] whatever, right? Um any account access [22:47] issue that might be tricky to solve like [22:49] for example npm account take over stuff [22:51] like that that might be tricky to [22:52] escalate just support. So we can just [22:54] you know try to speed up on the [22:55] foundation. any kind of weird supply [22:58] chain attack that may happen to one of [22:59] the projects that because you got [23:01] polluted by other random library that [23:03] you you know depend on stuff like that [23:05] that become a complex situation you know [23:07] this kind of exit uh kind of attacks [23:10] things like that on how to handle these [23:11] kind of things and obviously any kind of [23:14] you know uh legal stuff for example that [23:16] might be in terms of licenses in terms [23:18] of things like that that might be a [23:19] little bit tricky and yeah I don't know [23:22] uh that was more or less the first [23:23] brainstorm me from my own right um so [23:25] yeah this is super open uh to discussion [23:27] to include categories to remove [23:28] categories and I will shut up and let [23:30] you uh start with some feedback and [23:32] ideas uh if you prefer sync let's go now [23:35] if you prefer a sync also the PR will be [23:37] open for a while so [23:43] yeah is there anything folks want to [23:44] discuss while we're um together um or do [23:49] folks want some time to read this at [23:51] their leisure and then we can we can [23:54] review [24:00] Uh I left a comment in the proquest but [24:03] um [24:04] just wondering uh if we could merge the [24:07] the nojs one uh and the fastfly one into [24:12] this uh to make it it's like it's like [24:15] generic so we could uh send it to other [24:19] projects as well. uh but yeah this is uh [24:22] I think this is something we should do [24:23] as synchronously [24:25] uh the discussion because it requires [24:28] more time to evaluate and see if that's [24:30] applicable or not. [24:35] Yeah, I think I think that go to a sync [24:37] discussion because what we have on on [24:39] fastify note I think it's more related [24:41] to CDES and you know security uh [24:44] vulnerabilities directly on the source [24:46] code and stuff like that. uh so that [24:48] maybe we should have something uh [24:50] definitely like a template or something [24:51] that the people can use but the aim of [24:53] this uh response plan is not to cover [24:56] CBS it's going to be like more on [24:58] whatever is not a CB but also can be a [25:00] security incident so maybe we can just [25:03] point to this document on this uh [25:05] security policies later on the project [25:07] security policies later on but yeah we [25:09] can we can continue discussing this uh [25:11] sync 100% [25:14] >> yeah I think it's it's a really good [25:16] draft I think that you're um I like the [25:20] way of um marking things for discussion [25:22] with popcorn. Um because there's um [25:26] there's some important questions in [25:27] here, right? Which is like who should be [25:29] involved in vetting these? Um who are [25:32] the potential folks that could be [25:34] assigned as the um I forgot the term, [25:36] but it like the coordinator. Um so yeah, [25:39] but I think this is like a this is a [25:41] really good start and I think it's it's [25:44] very much on the right track of what we [25:45] need. [25:46] So yeah, this is good work. [25:50] So um I think Ulysi is just a just to [25:53] reiterate. So we want to try and look at [25:54] this async this week and then we can um [25:58] use some time in the next um weekly [26:01] meeting if we need to to maybe resolve a [26:03] couple outstanding issues or anything [26:05] that needs in person discussion. [26:07] >> Yeah, that that sounds fantastic. Just [26:09] one minor thing as well. that is like a [26:11] placeholder for stuff that they use [26:13] capital letter like for example the team [26:15] or you know the report until we have a [26:19] proper name right [26:21] >> um just one one quick comment um [26:24] synchronously here Ben Ben kind of [26:26] struck struck me with it as or came to [26:29] me as Ben mentioned uh the the assigne [26:33] um you probably need a racy chart or [26:35] something like that in in in this that [26:37] dictates the roles and responsibilities [26:39] and who's accountable [26:41] consulted, informed, that kind of thing. [26:43] I think just looking through it real [26:44] quick, there there are defined roles and [26:46] that probably be a helpful [26:49] uh intro matter to have in there that [26:51] kind of outlines [26:53] that, too. [26:55] I'm happy to make that comment. I was [26:57] just thinking it off the top of my head [26:59] as Ben mentioned that. [27:01] >> Yeah, Steve, it sounds like you might [27:03] have experience with defining rules for [27:05] a security incident response plan. So if [27:07] you have [27:09] >> anything that you feel free copy pasting [27:10] in there would be useful. [27:11] >> Yeah, I love it. I love it. [27:14] >> Awesome. Thank you. [27:17] >> All right. Uh anything else related to [27:19] the response plan? [27:21] >> I think Robin was muted [27:24] and trying to speak. [27:25] >> Just unmuting. I also think maybe uh [27:27] linking you know our npm and GitHub [27:30] continuity plan as well [27:33] you know because that could be here. [27:37] That's that's a good one. Yeah. And in [27:39] general continuity, if we have other [27:41] platforms and other stuff, that might be [27:43] also uh something to take in account. [27:44] Yeah. [27:51] >> Okay. Uh next up we have minimal VDP. [28:02] I forgot if that was Ulyses or Raphael. [28:06] Sorry, can you repeat the issue? [28:08] >> Oh, it was uh the next topic we have is [28:10] minimal VDP. [28:12] >> Okay. Oh, no, no, no, that's not me. Uh [28:15] I think [28:16] >> Ulysius, was this one you? This is a [28:19] mental note that now for agenda items I [28:21] need to have names so I know who to call [28:22] on. Yeah, I think I think um [28:27] >> I think that was the one from Rude, [28:29] right? [28:30] >> Yeah. Yeah. And the idea from from us as [28:32] a group was that to go with a um minimum [28:36] over the minimum uh template person if [28:39] I'm not mistaken. [28:42] Yeah. Um probably we should designate a [28:45] champion for this. Um [28:49] I'm happy to volunteer. Unless Rafael [28:52] want to [28:57] uh can someone send me? Okay. Thank you. [29:03] Yeah, I think you're right, Liss. We [29:04] need uh we need someone to take over the [29:07] reigns on this one. I do think it is a [29:10] it is something that we should do. Um [29:13] I think what we have is probably [29:19] it's everything, right? And I think it [29:21] might be hard. Um and so I think this is [29:23] a good idea. Um [29:26] Chris, [29:28] >> yeah. Um, [29:31] I think we talked a lot about this back [29:32] when Rudd was first crafting this. Um, [29:35] and I think he did really good work. Um, [29:37] he did really good work, I should say. I [29:39] think. Um, but, uh, in the way of what [29:42] is minimal, um, it was quite what what [29:45] he's got in there as minimal is quite [29:47] extensive, right? Um, so I can take a [29:50] stab at this one. Um, really you want [29:52] something that covers, you know, how do [29:55] people submit vulnerabilities to a [29:57] project? uh whether that's you know a [29:59] reporting email address or using GitHub [30:02] you know um private vulnerability [30:05] reporting feature [30:07] um and just something really easy that a [30:10] m maintainer that doesn't already have a [30:12] policy or has something that maybe [30:14] doesn't even go that far um can at least [30:16] quickly review and adopt and doesn't [30:18] contain the scary legal things like the [30:21] safe harbor stuff um and all of that so [30:25] I can take a stab at [30:27] Um we we we crafted something very [30:31] minimal for um TC39. Um, of course, uh, [30:38] language specifications are have are [30:41] very different than, um, actual [30:43] projects, but, um, I think we can use [30:46] some of the, um, feedback that we got [30:49] for that, um, because we did have quite [30:52] a lot of for for something that has so [30:56] few words, uh, we spent a significant [30:58] amount of time in iteration review. So, [30:59] I can take a stab at that. Um, so Ben, [31:02] you wanted to put names to things. uh [31:04] you can put my name on that. Um and um [31:07] I'll try to find some time uh this week [31:10] to uh um knock that out and we can [31:15] review. [31:15] >> Great. Yeah, thanks Chris. Yeah, I I [31:17] added your name on the um on the agenda, [31:19] but um yeah, thank you for volunteering. [31:24] >> Sure. [31:25] >> Okay. And I think the ju just to close [31:27] the loop, I think the the other guides [31:30] that we have um the that that RD did, [31:33] the recommended policy and the minimal [31:35] policy um I think those have a lot of [31:38] great content um and we can continue to [31:41] um you know recommend those to projects [31:44] um but maybe we should um take a spend [31:48] some time at some point in the not too [31:50] distant future to just review the [31:52] content of those and make sure that we [31:54] still feel like um everything in there [31:57] is good or if there's something we want [31:59] to change. Um, and then you know I'm [32:02] reminded of like uh the I forget what we [32:06] called them but this you know the [32:08] security guidance that we gave for [32:09] projects had like sort of different [32:10] levels right that ex like the [32:13] recommended versus expected or suggest I [32:15] forget the exact terms that were used [32:17] but um we could sort of do the same [32:20] thing with the the the security policy [32:22] stuff where you have you know whether [32:24] you call it a t-shirt size or whatever [32:25] like here's what you should minimally [32:27] have then consider this thing which [32:30] includes more information. And then then [32:32] you get into things like you know [32:33] documenting your threat model so that um [32:37] you know if there's like a category of [32:38] vulnerabilities that um you don't the [32:40] project does not consider [32:42] vulnerabilities therefore don't report [32:43] them. Um and that sort of guidance um [32:46] for more like advanced level or more [32:49] mature projects. [32:53] >> Yeah, I think that's good feedback. [32:57] >> Okay. All right. Right. So, anything [32:59] else on the [33:01] minimal BDP [33:04] before we move on to CPC? [33:11] Okay. So, I I mentioned this in our [33:12] previous conversation which is that um [33:15] one of the things that this group can [33:16] influence, right, is the uh uh CPC [33:20] onboarding requirements for new [33:22] projects. And so, we've been talking [33:23] about that a little bit. So, I think [33:24] there's two items in here. Uh, I'm just [33:27] opening them up locally so I know what [33:29] they are. I think Raphael, maybe these [33:32] are your topics. [33:35] >> Yes. Uh, [33:38] you you mean the [33:40] the the media, right? [33:45] >> Yeah. There's two in here that are [33:47] linked. One is that and then the other [33:49] is um security policy. [33:51] >> Meanwhile, yeah. Yeah. uh so uh the [33:54] these are topics that we have discussed [33:56] in the last of mega sync uh uh as I've [34:00] mentioned there we created the security [34:03] help channel we are we sent messages uh [34:06] through mail to all the open JS projects [34:10] to join that uh that channel and in case [34:13] they they need some help to to ping me [34:17] or releases but I would like I I feel [34:20] that we could create some media or uh [34:24] either the OpenJS Foundation blog post [34:27] to to mention that again just to make [34:30] sure that the OpenJS projects they they [34:33] are aware that they can ask for help [34:35] whenever they want. So uh uh just to [34:40] make sure that we are delivering the [34:42] right message to all of them. So I wrote [34:44] this issue just to [34:47] uh just to have that on mind uh whenever [34:50] we want to publicize about it. So yeah, [34:54] I want to crisp this up a little bit [34:56] because I think it's a it's important is [34:58] that um and Raphael and Ulissiz correct [35:01] me here um where needed, but we we we [35:04] meet every week and oftentimes we're [35:06] talking about how difficult it is or or [35:07] how we don't hear from projects um that [35:11] uh you know because we we have resources [35:14] that can help them. Um but when we reach [35:16] out to projects oftentimes we don't we [35:18] don't hear back and um so it's a little [35:21] bit of a struggle here and we we kind of [35:23] are assuming that they do need our help. [35:25] Um so this is really about making sure [35:27] that they know and that they have a [35:29] clear path to um working with us or [35:32] requesting help from us or getting [35:33] involved. [35:35] >> Uh Ulyses. [35:37] >> Yeah. Something that happened from um [35:40] last week is um there was an announce [35:42] official announcement finally uh in the [35:44] GitHub blog post about the participation [35:48] of some of the projects on on the [35:50] foundation on the I think the technical [35:53] name was GitHub secure open source found [35:55] which was like three weeks in terms [35:57] learning and stuff. uh we learned a lot [35:59] there and probably we can bring a lot of [36:02] topics from what we have learned there [36:05] to the on boarding process of new [36:08] projects. So probably we can you know [36:09] reshape a little bit uh requirements and [36:12] stuff based on what we have learned [36:14] there and so on and we can also bring [36:16] Greg into the discussion one of the the [36:18] people from the GitHub site running the [36:20] program. So that might be a good option [36:22] and try to bring some resources because [36:23] also one of the ideas um they have on [36:26] this program was uh try to you know um [36:30] like prepare one generation of [36:31] maintainers so we can you know just [36:33] expand this to other maintainers and try [36:34] to make it more digestible right so we [36:36] can try to propagate and evangelize this [36:38] idea a little bit more to others um so [36:41] we can see how to adapt this to our [36:42] ecosystem uh but that might be a good [36:44] option [36:47] >> yeah I like that train the trainer idea [36:49] essentially I think That's good. Um, [36:52] yeah, I don't know if just a general [36:53] blog is the right idea, but again, [36:56] sometimes, again, we we hit them where [36:58] they are, whether they're on Discord [36:59] like Electron or what have you. I still [37:02] feel like our town hall meetings um have [37:05] had the best attendance [37:07] um because we're actually throwing [37:08] something on their calendar. So, uh we [37:11] could do that. I think when RD tried it, [37:13] he did too many and it gave too many [37:15] options. I think we just need to have [37:16] one and then some information go out. [37:20] Um, [37:21] that might be a good way to get the [37:23] information. So, but yeah, I think I [37:27] think if we end up doing like a blog to [37:29] the community, you're going to have lots [37:31] of JavaScript projects who are not [37:33] Open.js hosted projects come for you to [37:36] you for help, which is not a bad thing [37:38] if we point them to resources. So maybe [37:41] we do something more along that lines [37:44] just to push it out to the broader [37:46] audience. Um we do have a security page [37:49] um on OpenJS now. It probably needs to [37:52] be updated as well, but that's another [37:54] spot we can drive people to. [37:59] >> Yeah, I think I think the blog post [38:01] might be also um super helpful in order [38:03] to you know let the braid knows uh what [38:06] they can expect in terms of support [38:08] because there are too many topics in [38:09] different areas, right? But um so also [38:12] I'm starting to trying to reach like [38:14] privately to maintainers that I have [38:15] already a previous relationship because [38:16] they contributed to the projects or [38:18] whatever. So um but but having like a [38:20] blog post something that can be less [38:22] brassive like a private message with a [38:25] >> can be good. [38:26] >> Okay, let's schedule time with Kylie to [38:28] make that happen. [38:30] >> Yep. [38:30] >> Go. [38:32] >> I had an idea. [38:33] >> Yeah. [38:34] >> Um we could think about doing a [38:37] quarterly town hall. So something a [38:39] little bit more regular. [38:41] >> Yeah. [38:41] >> Um and [38:44] that would also be very good to include [38:46] in a blog post as well. [38:49] >> So I think if we have enough content for [38:51] that [38:51] >> but you know it could be a thing where [38:53] we are bringing things to the projects [38:55] we could update them on what we've been [38:57] doing that kind of thing and also have [38:59] maybe some open time in the town hall [39:00] for folks to like put forward their [39:04] problems that they're seeing or things [39:05] that they might need help with and and [39:07] that kind of thing. Um, but I like [39:09] having something regular. Um, [39:13] um, but yeah, I'm open I'm open for [39:15] feedback on that. [39:15] >> I love that idea. [39:22] >> So, we could do [39:25] I mean, I think if we have um an inc I [39:29] mean, there's some really interesting [39:31] stuff here to that we could review. like [39:33] if we have an incident response plan, if [39:35] we've got this minimal VDP, that alone I [39:38] think is um enough for a town hall. Um [39:42] and then then if there's like a section [39:44] about the GitHub secure open source fund [39:46] and sort of what we learned there. Those [39:48] are just some some things that just we [39:49] discussed today. That's a that's a [39:51] really good um idea. So maybe we could [39:54] target um like end of September for the [39:57] first one. I only say that because end [39:59] of August uh is is now and is vacation [40:02] time and then end of September would [40:03] give us enough time to prep. Um Robin, [40:06] does that seem [40:08] >> Yeah. No, I think that's good. And then [40:09] actually I can use that content for my [40:11] JS comp opening keynote, too. [40:14] >> Yeah. [40:16] >> Yay. [40:16] >> With some photos of all the lovely faces [40:18] that we have here. [40:21] >> Okay. All right. We'll work towards an [40:23] end of September town hall. [40:28] Okay. [40:35] Hey, Rick. [40:42] Figured out my camera. Sorry, it's been [40:44] a bit. Had to fix it. [40:45] >> Always good to see you. Uh, okay, that [40:48] all makes sense. And then so the last [40:49] thing on here was the um I kind of split [40:51] up these two things because we have the [40:53] topic of requesting help from this group [40:55] and then um working with the CPC on [40:58] updating onboarding requirements. I [41:00] think those are two different things so [41:01] I just split those up. So um Raphael [41:05] this is the minimum set of security [41:08] policies as part of OpenJS onboarding. [41:11] So right right now if if I recall [41:13] correctly our onboarding requirement is [41:16] that there must be a security policy. I [41:19] I don't think it goes into much more [41:21] depth than that. And so I think the idea [41:24] here is to um [41:26] >> yes [41:27] >> be a little bit more verbose on what [41:28] we're asking products to do. So yeah [41:30] Raphael I'll I'll hand it over to you. [41:33] >> Yeah that's correct. uh I mean uh I [41:35] think we have discussed that in the last [41:36] meeting uh that uh we should define uh [41:39] just a minimal secured MD for the [41:42] projects that uh goes uh on boarded to [41:45] the OpenJS foundation. uh and then I [41:48] have discussed that with in the command [41:51] center repository and this is the result [41:54] we came up uh [41:57] I said it's in the issue uh but I will [42:00] send in the chat uh and we just need [42:04] like an approval or more review from [42:08] from the team and uh once approved we [42:11] can uh organize how to uh make it uh [42:16] global and how to apply that retrobably [42:19] to other projects that doesn't have one. [42:26] >> Yeah, I think that's great. Once once [42:28] this group is ready, the way that we [42:31] would move this forward would be um [42:34] yeah, it would be a PR against the um [42:38] CPC [42:40] uh documentation. I think it's the [42:42] project onboarding. um and it needs to [42:44] have the agenda label um so that it can [42:47] be discussed in the the next CPC call [42:49] where that happens. Um uh so that's the [42:51] way that that works. The the other point [42:54] here is that how to ensure that projects [42:59] that have already been onboarded keep up [43:01] to date. That is something the CPC is [43:03] working on now and does not have a [43:05] solution for. Um so it's timely I would [43:09] say. Um, and this is a really good [43:11] example of like, hey, we've updated our [43:13] security policies based on new [43:14] information, new best practices, all [43:16] this great stuff. Projects that were [43:18] onboarded [43:20] 5 years ago, right? There might be some [43:22] some work that needs to be done. So, how [43:24] do we how do we do that? Um, so that's a [43:26] really good [43:28] um discussion. [43:31] Yeah, I I think we could um uh see how [43:35] we can um uh organize that in the [43:38] command center repository because I [43:40] believe we could set up some automation [43:42] to send message or to receive feedbacks [43:45] from then. Uh but yeah, that's a second [43:48] step of this this idea. So I I wait uh [43:51] for uh until the end of this day uh if [43:55] you if you any of you have any [43:57] suggestion to this document. So I will [43:59] open the request uh and then if you want [44:01] to review that uh that would be great. [44:07] >> Awesome. Thank you Rafael. [44:11] >> Okay. [44:13] Any other um any other business any [44:16] other walk-on topics or anything that [44:19] folks want to discuss while we are here? [44:22] Just looking at the chat real quick to [44:24] see if there's anything. [44:26] Ulyses. Yeah, I think something that um [44:30] might worth uh in as part of the on [44:33] boarding as because it's the peak of uh [44:36] you know motivation of the people when [44:37] when they join uh maybe is to uh give [44:40] them some context uh I mean some content [44:42] related to uh how to issue CVS and stuff [44:47] like that especially using the CNA of [44:49] the of the foundation like uh because [44:52] maybe when they joined the foundation [44:54] they never did a CV before so there's [44:56] like a lot pragmatical questions on how [44:59] that works, how to use the advisories, [45:01] you know, these kind of things. So maybe [45:03] worth to you know have something ready [45:05] to them in order of this is the guide on [45:07] on how you sold this or you know just as [45:10] part of the on boarding do a small you [45:12] know like body on boarding. So we can [45:15] have some people who has experience on [45:17] this that can just you know go with the [45:18] project like a half an hour and [45:20] explaining everything in details and see [45:21] how their technical uh level and skills [45:24] are on this topic. So basically they are [45:26] from from from that moment on they it's [45:29] more easy for them to issue CVS and [45:30] stuff. [45:33] >> That's a really interesting idea. Um [45:38] it made me think of this idea. You know [45:40] we have this we have this long list of [45:42] things that we do for project onboarding [45:44] right which is like have a security [45:45] policy. Um you know make sure your [45:47] license are up to date blah blah blah [45:48] blah blah. But I'm not sure maybe Robin [45:51] you can help help with this one. I'm not [45:53] sure how much we have in terms of like [45:55] welcome to the foundation. Here's a [45:58] checklist of things that are available [46:00] to you now, right? Like here's the um [46:03] the security cloud space meets here. The [46:05] CPC meets here. If you have [46:07] infrastructure requests, you can do [46:09] this. If you need to file a CLA, you can [46:11] do this. Um, I think we we we kind of [46:14] know what all that stuff is, but I don't [46:16] know um if we formally like present that [46:20] in some way or to the to the project so [46:22] that they're aware of like here's all [46:25] the stuff that you now have available to [46:26] you. [46:29] >> Not formally. Usually when it's often [46:31] like a CPC chair and I will meet with a [46:33] prospective project and sort of walk [46:35] through some of those things, but it's [46:37] not like packaged up into a welcome [46:41] packet. [46:42] >> Yeah. So it might be something that we [46:44] can we can sort of maintain. There's [46:45] just benefits of joining the foundation, [46:48] right? Um [46:49] >> Yeah. And we do have a you know a slide [46:51] that lists a number of Yeah, I have a [46:55] couple of slides. [47:00] Okay, that's a good idea. Maybe I'll [47:03] work on that one. [47:06] Uh, okay. Other other topics that folks [47:09] have. [47:14] Uh, small one. Uh, maybe maybe not for [47:18] the boarding. Maybe yes. As we have been [47:20] discussing today about uh licenses [47:22] because of the FOSA uh demo. So maybe [47:25] worth also as part of the onboarding um [47:28] to ensure that the Brit have done some [47:30] kind of um [47:33] machinedriven check on the dependencies [47:36] and dependencies they have on on their [47:38] own depend because sometimes might [47:40] happen like for example if you're m [47:41] project but you have some ATPL or [47:44] whatever as a subsup dependency then you [47:46] have some compliance problems on your [47:47] licenses and that's a hard step to do as [47:51] a maintainer because I mean having a [47:52] clear license for your own project is [47:54] something easy to review but but knowing [47:56] your own dependencies in that li of [47:59] compliance might be a little bit tricky [48:00] and can anticipate us a lot of issues in [48:03] the future but that's a tricky thing [48:05] because not so sure also how well the [48:07] project do that currently so yeah [48:11] >> yes so we had an open issue probably [48:13] five years ago I think Michael Dawson [48:15] had opened it about license scanning and [48:17] we had worked with the LF team and that [48:19] was supposedly under development but I [48:21] know things have changed so Um, again, [48:24] FASA does do a lot of work with CNCF, so [48:27] if that's the path, you know, we want to [48:29] take, but I I think we found it was [48:33] something we couldn't uh we couldn't [48:35] manage 5 years ago, but maybe we can [48:37] today. [48:40] Yeah. [48:48] Okay, [48:52] last call for any other topics. [48:59] Okay, well, always good to see you all. [49:02] Enjoy the rest of your Monday and if I [49:03] don't talk with you, I'll see you next [49:05] week. [49:06] >> Bye, folks. [49:08] >> Bye. Hi everybody.