OpenJS Security Working Group - June 22, 2026 ![rw-book-cover](https://i.ytimg.com/vi/HkePMUn0rKs/sddefault.jpg?sqp=-oaymwEmCIAFEOAD8quKqQMa8AEB-AH-CYAC0AWKAgwIABABGBEgbChyMA8=&rs=AOn4CLDu-eFZ_nuzH-LzZGKLAGdGM-u6qg) 🔗 **Source:** [OpenJS Security Working Group - June 22, 2026](https://www.youtube.com/watch?v=HkePMUn0rKs) > [!note]+ Document Notes > tags: [supply-chain-security, open-source-governance, cve-management, javascript-ecosystem, vulnerability-disclosure, nodejs-security] > author: OpenJS Foundation > source: https://www.youtube.com/watch?v=HkePMUn0rKs > reference: https://www.youtube.com/watch?v=HkePMUn0rKs > date created: 2026-06-23 00:00 > > # 🏷️ Title: OpenJS Security Working Group - June 22, 2026 > <!-- deep-read:sections start --> ## 🧭 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 Security Working Group](https://github.com/openjs-foundation/security-collab-space) - [MITRE CVE Program](https://www.cve.org/) - [Node.js Security Releases process](https://nodejs.org/en/security) ## 📝 Summary - The OpenJS Security Working Group met June 22, 2026 and walked through three agenda items: a new CNA (CVE Numbering Authority) API proof-of-concept, a project security escalation policy/workflow, and a carried-over Axios discussion. - It matters because the group is trying to move CVE issuance from a manual, CNA-team-bottlenecked process toward a self-service API that lets member projects reserve, publish, and update their own CVEs without waiting on humans. - Key stakeholders: the OpenJS CNA team, member projects (Node.js, Express, Fastify, webpack), MITRE as the upstream CVE authority, and other CNAs who might fork the tooling. - Risks and tradeoffs: delegating publication authority to projects without gatekeeping raises accidental-publish risk (CVE publish is irreversible except by rejection); the architecture leans on GitHub Actions plus a Cloudflare worker rather than a standing server, trading warm-up latency for lower infra cost and a smaller attack surface. - Bottom line: a single contributor built a working end-to-end POC reducing project CVE work to roughly four CLI commands; the group is deciding whether to pursue it as the official direction, starting with Node.js adoption. ## 📖 Main Content - The core proposal is an OpenJS CNA API that automates CVE lifecycle operations (reserve, publish, update, query, list) so member projects gain ownership and autonomy instead of routing every request through the CNA team. - The CNA team would still own infrastructure (token issuance, rotation), MITRE coordination, dispute handling, technical advice, and rejection workflows — the "interesting" CNA work — while offloading routine issuance. - Architecture: minimal infrastructure by design. A GitHub workflow is the backend; a Cloudflare worker fronts it with credential authentication; everything is tracked in Git for an auditable log. There is no always-on server. - The **bucket model** is the notable addition over MITRE's current capabilities. Buckets scope a project's reservations so projects can't see each other's pending CVEs, and they separate testing from production environments (test bucket → test MITRE site; production bucket → production). This solves a real gap: MITRE today exposes reservations across the org. - Credentials are a hash combining a bucket reference plus a token; revoke/rotate is a JSON edit that redeploys the worker. - An official CLI client (built on Node.js core-utils) adds review tooling: it validates generated CVE JSON against MITRE's official schemas to predict acceptance, applies extra CNA-arbitrary lint rules (e.g. require CWE, require credits — neither forced by MITRE), and can emit an LLM-friendly markdown format. It also handles polling for slow GitHub-dispatch operations. - Term definitions: **CNA** = CVE Numbering Authority, an org authorized to assign CVE IDs. **CVE** = Common Vulnerabilities and Exposures identifier. **CWE** = Common Weakness Enumeration, a vulnerability-type taxonomy. **Vulnogram / CVE Kit** = existing editor tools for authoring CVE records. **GHSA global database** = GitHub's advisory database, which the presenter notes lags publication by days. - Contested/uncertain: the presenter repeatedly flags the design as "opinionated" and built solo, explicitly inviting architecture debate. Node.js is a special case — it uses HackerOne, not GitHub Security Advisories like most projects, so adoption needs project-specific PRs to docs and node-core-utils. - Notably, a participant (Chris) declined to give one piece of feedback on the recording "out of an abundance of caution," and the recording was stopped before that feedback — a signal that some security-process detail was considered sensitive. ### 🗒️ Notes #### ⏱️ [00:00:08](https://www.youtube.com/watch?v=HkePMUn0rKs?t=8) Agenda set - Three items: new CNA API, project security escalation policy/workflow, Axios discussion (carryover). - Group decides to take items in reverse order. #### ⏱️ [00:00:18](https://www.youtube.com/watch?v=HkePMUn0rKs?t=18) Axios discussion → working session - The Axios topic gets parked into a dedicated one-off working session in a future call rather than handled live. #### ⏱️ [00:00:50](https://www.youtube.com/watch?v=HkePMUn0rKs?t=50) Issue 324 — mailing list triage - The security mailing list gets heavy inbound, much of it spam; hard to tell which emails need a human. - Proposed fix: a repo with a JSON state file so the team can see what's been digested/addressed and who's escalating what. - One member is personally tracking it now, but a supporting team and a PR to react against is the long-term goal. #### ⏱️ [00:01:28](https://www.youtube.com/watch?v=HkePMUn0rKs?t=88) Issue 337 — CNA API kickoff - Long-informally-discussed idea: an API to simplify CVE management within the CNA. - Today is manual; tooling like CVE Kit already helps. Goal is to ease others' adoption too, especially getting projects onto the OpenJS CNA so disputes and scope stay in-house. - Decouples "I need help understanding this security issue" from "I just want a CVE." #### ⏱️ [00:02:40](https://www.youtube.com/watch?v=HkePMUn0rKs?t=160) POC scope and infra - Private repo to be made public after the recorded session so it can be referenced in the README. - Forked from the existing CNA website but strips sensitive YAML (reserved/unreleased CVEs). - Stack migrated from Jekyll to Eleventh (11ty); reserved-CVE data pulled live from MITRE instead of manual YAML merges that leave the site stale. - Plan is to cherry-pick changes into the existing site via PRs, not replace it. #### ⏱️ [00:04:20](https://www.youtube.com/watch?v=HkePMUn0rKs?t=260) Worker + bucket architecture - GitHub workflow as backend, Cloudflare worker as authenticated front door, Git as audit log — no standing server, to minimize impact and preserve existing repo-access rules. - Bucket model: scoped reservations per project, plus testing vs production buckets so projects develop/test without touching production. #### ⏱️ [00:05:18](https://www.youtube.com/watch?v=HkePMUn0rKs?t=318) Official CLI client - "Open CNA tools" repo (already public), intended to transfer to the foundation. - `Open CNA reserve` style commands; review JSON before submit (terminal render like Vulnogram), validate against official CVE schemas, enforce extra CNA rules, optional LLM-friendly output. #### ⏱️ [00:08:15](https://www.youtube.com/watch?v=HkePMUn0rKs?t=495) Node.js adoption track - Node.js has well-documented release/security processes and its own node-core-utils (which the new CLI is based on). - Adoption needs project-specific PRs; Node.js uses HackerOne rather than GHSA, so the fit is bespoke. #### ⏱️ [00:08:47](https://www.youtube.com/watch?v=HkePMUn0rKs?t=527) End-to-end delegation model - Projects request/reserve/query/publish/update their own CVEs; API runs 24/7 so projects don't wait on the CNA team. - CNA team retains MITRE coordination credentials, auto-updates the CNA website on publish, and stays on for tokens, rotation, tricky advisories, disputes, rejections — "without gatekeeping." #### ⏱️ [00:09:48](https://www.youtube.com/watch?v=HkePMUn0rKs?t=588) Credential generation demo - Bucket manager registers a project (e.g. webpack), generates a bucket reference and a token; the credential is a hash of bucket-name + token. - Flexible scoping: Express could be one bucket, or split per-library (multer separate); multiple credentials per bucket allowed. - Stored as JSON in-repo (hash, label, created); commit author implies ownership; push redeploys the Cloudflare worker. #### ⏱️ [00:11:10](https://www.youtube.com/watch?v=HkePMUn0rKs?t=670) CVE lifecycle for projects - Health endpoint check (no token needed); CLI also works as a library. - Reserve a CVE (no args), save the output reference for later steps; long GitHub-dispatch warm-ups handled by built-in polling. - On error, the CLI returns a correlation ID and run ID to forward to the coordinator (project can't see the repo run). #### ⏱️ [00:12:30](https://www.youtube.com/watch?v=HkePMUn0rKs?t=750) Convert + review advisory - CLI converts a published advisory (GHSA repo advisory or GitHub global DB — both supported despite the global DB's multi-day lag) into MITRE JSON automatically. - Review step surfaces title, description, affected, versioning, scoring, CWEs, credits, references; flags missing reporter/finder per CNA extra rules (linter analogy). #### ⏱️ [00:13:40](https://www.youtube.com/watch?v=HkePMUn0rKs?t=820) Publish + safeguards - JSON can be hand-tweaked in Vulnogram / CVE Kit before publish — stays integrated with existing tools. - Publish is irreversible (only undo is rejection); API guards against CVE-ID mismatch between advisory and JSON to prevent publishing the wrong record on a busy day. - For projects it's ~four commands: reserve → use ID in advisory → download/convert public advisory JSON → review → publish. No CNA member required in the loop; runs logged via GitHub Actions, retained 3 months, published to MITRE test env in the demo. #### ⏱️ [00:15:10](https://www.youtube.com/watch?v=HkePMUn0rKs?t=910) Next steps and feedback - Next: docs for projects (what a good CVE/advisory looks like), list all project-associated CVEs/advisories (not just CNA-issued), confirm team buy-in, confirm project willingness, deepen Node.js core-utils discussion, open the POC publicly. - Chris withholds one piece of feedback on-recording out of caution. Rafa congratulates the work and notes adoption could replace waiting ~two weeks on HackerOne dates, folding into in-flight automation updates. Recording stopped. ## 📚 References - [OpenJS Foundation](https://openjsf.org/) - [CVE Program (MITRE)](https://www.cve.org/) - [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) - [Node.js Security](https://nodejs.org/en/security) - [node-core-utils](https://github.com/nodejs/node-core-utils) - [GitHub Advisory Database](https://github.com/advisories) - [Vulnogram](https://vulnogram.github.io/) - [Cloudflare Workers](https://workers.cloudflare.com/) - [Eleventy (11ty)](https://www.11ty.dev/) ## 🗣️ Paraphrase - The meeting opened by ordering three agenda items and quickly parking the Axios topic into a separate working session, then turned to a mailing-list triage problem (issue 324) where spam buries real reports — the fix being a JSON-backed repo to track what's been handled and by whom. - The bulk of the session was one contributor demoing a proof-of-concept CNA API (issue 337) that automates CVE reservation and publication via GitHub Actions behind a Cloudflare worker, introduces scoped "buckets" with test/production separation, ships a validating CLI client, and reduces a project's CVE work to about four commands — pitched as a way to give projects ownership while the CNA team keeps the hard coordination work, starting with Node.js. ## 📰 Newsletter - Heads-up for the open-source security crowd: the OpenJS Security Working Group is prototyping a self-service CNA API so member projects can reserve and publish their own CVEs in about four commands instead of waiting on a human. WordPress-adjacent folks watching supply-chain security will recognize the pattern — a foundation centralizing vulnerability tooling while pushing day-to-day ownership out to projects. - The clever bit is the "bucket" model: scoped, environment-separated credentials so projects can't peek at each other's pending CVEs and can test against MITRE's test environment first. The whole thing runs on GitHub Actions plus a Cloudflare worker — no standing server, full Git audit trail. The CLI even validates your CVE JSON against MITRE's schema and lints for missing CWEs and credits before you publish. - Worth following if you maintain plugins or libraries and have ever stared at a CVE form wondering what "good" looks like — docs and adoption guides are on the roadmap. - Helpful links: [CVE Program](https://www.cve.org/) · [CWE](https://cwe.mitre.org/) · [Vulnogram](https://vulnogram.github.io/) · [Node.js Security](https://nodejs.org/en/security) ## ✅ Action Items #### DevRel - Developer advocacy: a walkthrough talk/demo of the four-command CVE flow once the POC is public. - Education: a "what makes a good CVE/advisory" workshop, since the group flagged docs as a gap. - Developer experience: quickstart and CLI reference for the Open CNA tools client; templates for advisory→JSON conversion. - Developer marketing: announce the public POC with a clear adoption funnel for member projects. - Community management: triage rota for the security mailing list tied to issue 324. - Internal/external/cross-project: align the API's CNA extra-rules (CWE, credits) with project expectations before mandating them. #### OSPO - Policy & Governance: ratify a contribution/decision-rights model for delegated CVE publication without gatekeeping. - License Compliance: confirm the public POC repo and forked CNA site carry correct licensing before open-sourcing. - Security Management: formalize the embargo-safe design (strip reserved-CVE YAML), credential rotation policy, and the irreversible-publish safeguard. - Software Inventory: build the planned list of all project-associated CVEs/advisories, not just CNA-issued ones. - Developer Support: stand up consultation hours for tricky advisories, disputes, and rejections that stay with the CNA team. - Community Engagement: coordinate Node.js adoption (HackerOne fit) and Fastify interest. - Strategic Alignment: get explicit CNA-team buy-in on pursuing the API as the official direction. #### Community - Maintainers: provide governance templates so projects can own CVE publication responsibly. - Contributors: onboarding path for projects (webpack/Express examples) to request buckets and credentials. - Sponsors: surface the now-funded security capacity that enabled the POC; report milestones transparently. - Ecosystem: run a coordinated-disclosure drill against the new test-bucket workflow. #### WordPress - Core: watch the bucket/credential model as a reference for any future WP-side CVE self-service. - Core Performance: not applicable to this source — meeting concerns CVE governance, not runtime performance. - Core AI: note the LLM-friendly CVE-JSON export pattern as a responsible-AI tooling example. - **Core Program Team:** track cross-project disclosure coordination rituals relevant to WP security. - Mobile: not applicable to this source — no mobile scope discussed. - Playground: reproduce the CLI validation flow as an education module. - Community: share the "good CVE/advisory" curriculum once OpenJS publishes it. - Training: build a lesson on CNA roles, CVE lifecycle, and CWE basics. - Marketing: not applicable to this source — no WP marketing tie-in. - Support: map vulnerability-intake escalation against the issue-324 triage model. - Design: not applicable to this source — no design artifacts present. - Documentation: mirror the examples-first advisory docs approach. - Photos: not applicable to this source — no media-content scope. - TV: caption and index this meeting recording for the security archive. - Polyglots: not applicable to this source — no localization scope discussed. - Accessibility: caption the recording and provide a transcript (see Accessibility Assessment). - Meta: track API reliability patterns (polling, correlation IDs) as a contributor-tooling reference. - CLI: study the node-core-utils-based CLI as a scaffold pattern. - Hosting: note the Cloudflare-worker + GitHub-Actions no-standing-server pattern for reliability. - Tide: align the schema-validation/lint approach with Tide's scoring transparency. - Openverse: not applicable to this source — no media-ingestion scope. - Themes: not applicable to this source — no theme-review scope. - Plugins: adapt the provenance/credits enforcement idea for plugin security liaisons. #### The WPCC - Programs: consider a maintainer stipend for security-tooling work like this POC. - Projects: a governance clinic on delegated CVE authority. - Funding experiments: note that dedicated funding enabled this contributor's intensive security work. #### FAIR - Technical independence: the local-Git audit log and provenance-by-commit model echo FAIR's local-metadata/provenance goals. - Policies and covenants: codify anti-capture rules for who can issue project credentials. - Productized governance artifacts: operator agreements and scorecards for CNA-delegated projects. ## 🧪 Hypotheses - Reducing project CVE work to ~four commands increases the rate at which member projects issue CVEs through the OpenJS CNA versus the manual baseline. - A bucket model with test/production separation reduces accidental or premature CVE disclosures compared with MITRE's shared-visibility default. - GitHub-Actions-as-backend introduces user-visible latency (cold-start warm-ups) that the CLI's polling mostly masks but does not eliminate. - Mandating extra CNA rules (CWE, credits) raises CVE record quality but lowers project willingness to adopt if perceived as friction. - Node.js adoption (HackerOne path) is materially harder than GHSA-based projects and will lag general adoption. ## 📊 Methodology - Study designs, data sources, and analyses to test the hypotheses: - Adoption-rate test: instrument CVE-issuance counts per project before/after API availability; difference-in-differences against projects still on the manual flow. - Disclosure-safety test: audit the 3-month GitHub-Actions logs and Git history for mismatch/premature-publish events across buckets. - Latency test: measure reserve/publish operation times across cold vs warm GitHub-dispatch states; report distribution, not just means. - Quality test: score published CVE records for CWE/credit completeness against a control set issued without the lint rules. - Adoption-friction survey: poll maintainers on perceived effort and the extra-rules burden. ## ❓ Questions - Who is authorized to grant project credentials, and how is that authority audited to prevent capture? - What is the incident response if the Cloudflare worker or its JSON credential store is compromised? - How does irreversible publish get protected beyond the CVE-ID mismatch check — is there a confirmation/embargo gate? - Will the extra CNA rules (CWE, credits) be mandatory or advisory, and who decides? - How will the planned "all project-associated CVEs" inventory be deduplicated against MITRE and GHSA? ## 🔮 Future Research - A demo of the full project-associated CVE/advisory inventory (deferred to a future session). - Concrete Node.js core-utils integration PRs and how HackerOne maps to the bucket model. - Whether other CNAs actually fork the public POC and what interoperability emerges. - Long-term governance: moving the tooling repos from a personal account to the foundation. ## 💡 Implications - Practice: maintainers gain self-service CVE issuance, shrinking the human bottleneck in vulnerability disclosure. - Policy: foundations can delegate publication authority while retaining coordination and dispute roles — a reusable OSPO governance pattern. - Security: scoped buckets and test environments reduce cross-project leakage and rehearse disclosure safely; irreversible-publish safeguards matter. - Education: a documented "good CVE/advisory" standard plus a validating linter raises ecosystem-wide record quality. - Funding: dedicated security funding directly enabled the POC, evidence that staffed security capacity produces tooling that scales the whole ecosystem. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ~11–12 (spoken-meeting transcript with dense technical jargon: CNA, CVE, CWE, bucket model, GitHub dispatcher). Flesch Reading Ease roughly 45–55. #### 👀 Visual learners - Present: the speaker shared screen with a slide deck and live demos (described, not captured in transcript). - Improve: architecture diagram (worker ↔ GitHub Actions ↔ MITRE), bucket-scoping diagram, before/after CVE-flow comparison, captioned screenshots. #### 🔊 Aural learners - Present: the source is itself a recorded audio/video meeting. - Improve: a 2–5 minute audio summary of the four-command flow and the bucket model. #### 🗣️ Verbal learners - Present: spoken explanations with analogies (the linter/eslint analogy for CNA rules). - Improve: a glossary (CNA, CVE, CWE, GHSA, bucket, dispatcher) and plain-language callouts. #### 🧩 Kinesthetic learners - Present: the public Open CNA tools repo and CLI invite hands-on trial; a health endpoint works without a token. - Improve: a sandbox test bucket walkthrough and a reproducible reserve→publish checklist. #### 🧠 Logical learners - Present: a sequential lifecycle (reserve → use ID → convert → review → publish) and decision points. - Improve: a decision tree for publish safeguards and a RACI for CNA-team vs project responsibilities. #### 🧑‍🤝‍🧑 Social learners - Present: a working-group meeting format with open Q&A and discussion. - Improve: a discussion thread on issue 337 with prompts; cohort guide for projects onboarding together. #### 🧘‍♀️ Solitary learners - Present: self-serve CLI and docs let an individual maintainer proceed alone. - Improve: a self-paced adoption worksheet and self-check on CVE record completeness. #### 🌿 Naturalistic learners - Present: lifecycle framing of a CVE from reservation to publication. - Improve: ecosystem-impact framing — how one project's hygiene affects the dependency graph downstream. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not applicable directly — source is a video, not a web document; this note is the rendered artifact. - Improve: ensure the published README and docs use proper heading hierarchy and landmarks. #### Keyboard navigation - Present: not applicable to this source — no interactive UI under review. - Improve: verify the external-facing API docs site is keyboard navigable. #### Contrast and readability - Present: not applicable to this source — slide-deck contrast not assessable from transcript. - Improve: check the 11ty-rendered site meets 4.5:1 text contrast. #### Text resizing and reflow - Present: not applicable to this source — no layout under review here. - Improve: confirm the docs site reflows at 200% zoom. #### Media and captions - Present: a transcript exists (this source). - Improve: add synchronized captions and a downloadable transcript to the YouTube recording; avoid autoplay. #### Forms and interactions - Present: not applicable to this source — no forms in a meeting recording. - Improve: if the API gains a web form, add labels, inline validation, and adequate target sizes. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.2.2 Captions (Prerecorded), 1.2.8 Media Alternative, 1.4.3 Contrast for the docs site. ### 🌍 DEIB Assessment #### Cultural breadth - Present: an international, distributed contributor group (references to holidays, multiple projects/teams). - Improve: global case studies of CVE adoption; translated docs for non-English-first maintainers. #### Inclusive language - Present: collaborative, non-gatekeeping framing ("give them trust enough so they can operate"). - Improve: define jargon on first use; plain-language summary of the bucket model for newcomers. #### Neurodiversity support - Present: a structured agenda and a stepwise lifecycle aid predictability. - Improve: chunk docs with frequent headings and icon+text labels; predictable command patterns. #### Representation - Present: multiple named contributors across roles (presenter, coordinator, reviewer). - Improve: balanced attribution in published notes; credit-enforcement rules already push toward acknowledging reporters/finders. #### Psychological safety - Present: respectful framing; a participant freely chose to withhold sensitive feedback off-recording and was accommodated. - Improve: a documented embargo/sensitive-topic protocol so contributors know when to pause recording. ### ✅ Logical Validity #### Strong reasoning - Causal: "manual process bottlenecks projects → automate issuance → projects gain autonomy" is a clear, plausible causal chain grounded in the demonstrated four-command flow. - Inductive: the working demo (reserve→convert→review→publish against MITRE's test env) is concrete evidence the design is feasible, not just theoretical. - Analogical: the "linter / eslint" analogy for CNA extra rules is apt and clarifies that the rules are advisory enforcement, not MITRE requirements. - Could clarify further: quantify the current manual bottleneck (time per CVE) to make the autonomy benefit measurable. #### Fallacies - Appeal to caution / unstated premise: Chris's "probably fine, but out of an abundance of caution" withholds a security concern without stating it on-record — reasonable operationally, but it leaves the audience unable to evaluate the risk. Fix: publish a sanitized version of the concern in the issue thread. - Solo-design bias (self-acknowledged): the presenter repeatedly notes the architecture is "opinionated" and built alone, which risks anchoring the group on one design. Fix: present at least one alternative architecture for contrast before deciding. #### Tone of voice - Collaborative, modest, and exploratory ("I talked it too much," "see if we are on the same page"). The presenter consistently frames decisions as open for group input rather than settled. ### 🛡️ DARVO Analysis - Deny: not applicable to this source — no accusation is being denied; this is a collaborative technical meeting. - Attack: not applicable to this source — no attacks on accusers or credibility-undermining present. - Reverse victim/offender: not applicable to this source — no victim/offender dynamic exists in the content. - Emotional cues/rhetoric: the only notable rhetorical move is risk-averse self-deprecation ("paranoid and tinfoil hat") when withholding feedback — caution, not manipulation. ## 🎯 Conclusion - Bottom line: the OpenJS Security Working Group has a working POC for a self-service CNA API that shrinks project CVE work to ~four commands, adds a scoped bucket model MITRE lacks, and keeps the CNA team on coordination/dispute duty without gatekeeping — pending team buy-in and Node.js-first adoption. - Practical next steps for readers: watch for the public Open CNA tools repo and POC; if you maintain an OpenJS project, prepare to request a bucket and try the test environment; if you run another CNA, the tooling is meant to be forkable. Track issue 337 for architecture discussion and issue 324 for mailing-list triage. ## 🔄 Refactor Appendix — OpenJS Security Working Group - June 22, 2026 > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. ### 📚 Literature Atoms (H3) #### [H1] CNA API delegates CVE issuance to projects without gatekeeping > [!quote] ID:rw_manual > "the project will manage or operate their own CVEs, like they can request, reserve, query, publish, update when they make sense" **Context & use**: - Mid-meeting, core thesis of the issue-337 demo. - Matters because it reframes the CNA team from issuer to coordinator — a reusable OSPO delegation pattern. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Bucket model scopes reservations MITRE currently exposes org-wide > [!quote] ID:rw_manual > "if we want to give credentials to anyone any project within the foundation to issue their own CVs, that's going to be challenging because everybody will see other's reservation" **Context & use**: - Architecture section; the bucket model is the key gap-filler over MITRE. - Matters because reservation visibility is a real cross-project disclosure risk. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] No standing server — GitHub Actions plus a Cloudflare worker > [!quote] ID:rw_manual > "instead of having like a full server running all the time and things like that, the idea was to minimize the impact" **Context & use**: - Infra-design rationale; trades warm-up latency for low cost and small attack surface. - Matters as a reusable low-infra security-tooling pattern with a Git audit log. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Delegated authority works when coordination, not issuance, stays central **Claim** (one sentence, Courtney's voice): An open-source foundation scales vulnerability handling by automating routine issuance to projects while keeping dispute resolution, credentials, and upstream coordination centralized. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds when irreversible actions (CVE publish) have safeguards and credential authority is auditable; breaks when delegation outruns the guardrails. **Links**: - [[Open-source governance]] — because extends - [[Supply-chain security]] — because applies-in vulnerability disclosure - [[WordPress plugin security review]] — because contrasts on centralized-vs-delegated review <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Watch for the public Open CNA tools repo + POC README — issue 337 #fleeting #inbox - [F2] Compare the bucket/credential model to WordPress.org plugin-team CVE handling #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Track OpenJS issue 337 for the public POC and architecture decision — security governance #things - [ ] Note the no-standing-server (Workers + Actions) pattern for any WP security tooling — reference #things ``` Processed: OpenJS Security Working Group - June 22, 2026 - Literature atoms: 3 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 2 - Things 3 actions: 2 / 2 cap - Konik tags used: [#xref] - Triage callouts populated: [Cross Reference] - Quality gates: [✓ atomicity, ✓ link annotations, ✓ YAML hygiene, ✓ headings] - Override conditions triggered: none ``` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/OpenJS Security Working Group - June 22, 2026.md|OpenJS Security Working Group - June 22, 2026 by youtube.com]] ## Highlights - something like that. So, instead of having like a full server running all the time and things like that, the idea ([View Highlight](https://read.readwise.io/read/01kvt8d4mhfwkj3kwne4a83cvh)) - Note: No standing server: GitHub Actions + Cloudflare worker. - Tags: atom/literature/h3 - is the project will manage or operate their own CVEs, like they can request, ([View Highlight](https://read.readwise.io/read/01kvt8d2ew2smsa5q02wm0786x)) - Note: Core thesis: delegate CVE issuance to projects. - Tags: atom/literature/h1 ## Links - [[3. Resources/Permanent Notes/Perm · WordPress security is now a supply-chain + dependency risk, not just plugin reviews]] — applies-in: delegated CVE issuance moves vulnerability coordination closer to the dependency owner. - [[3. Resources/Permanent Notes/Point-in-Time Review Cannot Detect an Attack That Unfolds Over Time]] — extends: ongoing project-operated advisories address risks a one-time package review can't see.