The OpenJS Foundation Explained: Node.js Governance, Projects, Security

The OpenJS Foundation is a US non-profit, formed in 2019 when the Node.js Foundation and the JS Foundation merged, that gives JavaScript projects such as Node.js, Electron, Express, jQuery, webpack, ESLint and Lodash a neutral legal home. A Board of Directors drawn from member companies and the community handles business matters, while a Cross Project Council (CPC) handles technical policy, admits projects and moves them through stages. Each project, Node.js included, keeps its own technical leadership, release process and security team, and the foundation adds shared security staff, guidance and its own CVE Numbering Authority.

This guide goes one level deeper than our posts on open source foundation governance models and Linux Foundation and Apache governance, and is a companion to our explainers on the Python Software Foundation and the Eclipse Foundation. Every rule, number and date below comes from the OpenJS bylaws (9 January 2026 version), the CPC repository, the Node.js governance, security and release documents, CVE Program records and the OpenJS and Node.js blogs, unless we say otherwise.

Key takeaways

• The OpenJS Foundation is a non-stock, not-for-profit membership corporation organised under Delaware law and operated as a 501(c)(6) organisation, according to its bylaws. It was announced on 12 March 2019 as the merger of the Node.js Foundation and the JS Foundation, with 31 projects at launch.
• Governance is split in two. The Board of Directors sets mission, scope and budget; member companies appoint or elect most directors, and the CPC designates community directors. The CPC is the technical governing body and approves new projects, project charters and stage changes.
• Projects sit in one of six stages: Incubating, At Large, Impact, Feature-Complete, Sunsetting or Archived. Impact projects must show production use by at least two independent end users and have a governing body of at least five people in which no more than a third share an employer.
• As of the CPC project list we read on 23 October 2026, six projects are at Impact stage: Appium, Electron, Express, jQuery, Node.js and webpack. ESLint, Fastify, Jest, Lodash, Mocha and Node-RED are among the 20 At Large projects.
• Node.js is run by its collaborators and a Technical Steering Committee (TSC), not by the foundation board. Its Release Working Group publishes the LTS schedule. From Node.js 27, there is one major release a year and every release line becomes LTS, with 36 months from first Current release to end of life.
• Node.js has its own CVE Numbering Authority (CNA) record dating from 2017. The OpenJS Foundation became a CNA in 2025, with a scope covering all projects listed on its projects page, and Node.js and Electron policies name it as the escalation path when a report gets no answer.
• Foundation security work is funded by grants and members: Alpha-Omega and the Sovereign Tech Agency fund the security working group, and the Security Stewardship Program, launched on 25 September 2026, pools member money for bug bounties and maintainer patching after Node.js ended its own bug bounty.

What is the OpenJS Foundation?

The foundation's about page states its purpose plainly: it is "working to make the web safe and modern" for the websites that rely on JavaScript. The bylaws list the formal purposes. In summary, they are to promote adoption and development of key JavaScript technologies, to help the JavaScript and web community collaborate, to be a center of gravity that guides projects "toward open governance and diverse collaborator bases", to host infrastructure for hosted projects, and to support an open and accessible web.

For a hosted project that means a legal home (trademarks and domains move to the foundation during onboarding), process templates (a charter, a code of conduct, an IP policy with a choice of contributor licence agreement or Developer Certificate of Origin, and minimum security reporting rules), shared services such as marketing, legal help, infrastructure and security staff time, and neutrality, which the about page says "ensures that no one company controls" a project many people depend on.

The about page says the foundation hosts "over 30 projects" and is supported by "nearly 30 member companies". Membership is not required to take part in technical work: the FAQ says any member of the community can get involved, and anyone may attend CPC meetings.

How did the Node.js Foundation and the JS Foundation merge?

Before 2019 the Node.js runtime had its own foundation and a second body, the JS Foundation, hosted other JavaScript projects. The Linux Foundation's press release of 12 March 2019 says the two had "coexisted independently for a number of years" and had drawn closer through a joint conference, Node+JS Interactive, from 2018. The merger process started six months before the announcement, with community consensus gathering and work with the Linux Foundation and both boards. The stated reasons were to remove duplicated operations, give companies one membership through which to fund the ecosystem, and coordinate with standards bodies. At launch the combined foundation listed 31 projects, including Appium, Dojo, jQuery, Node.js and webpack, and 30 corporate and end user members.

How does it sit within the Linux Foundation?

The OpenJS Foundation is its own Delaware corporation with its own bylaws, board and membership classes, and it operates with Linux Foundation support. Its documents show this in several places: the merger was announced by the Linux Foundation, the CPC repository routes infrastructure questions to "LF IT supported infrastructure", the Ecosystem Sustainability Program document refers to a "Linux Foundation General and Administrative (G&A) fee" on foundation funds, and program contacts use linuxfoundation.org addresses. In practice the Linux Foundation provides back office, legal and infrastructure services, while project decisions stay with the OpenJS CPC and each project's own leaders.

Timeline

How is the OpenJS Foundation governed?

The CPC charter describes the split in one line: the CPC is "OpenJS Foundation's technical leadership" and the Board of Directors is its "business leadership". The governance page adds that the CPC is a delegate body of the board, but that the design aims for "a clear separation of responsibilities between the two".

The Board of Directors

The bylaws define four initial membership classes: Platinum, Gold, Silver and Associated Entity members. Board seats follow from those classes.

The 2026 board announcement of 22 July 2026 summarises it: Platinum members appoint, Gold and Silver members vote among themselves, and the CPC elects "three Community Directors". The governance page says the board sets "overall technical policy through our bylaws, mission and vision statements". It owns budget, membership and scope; it does not run projects.

The Cross Project Council

The governance page calls the CPC "the top-level technical governance organization within the OpenJS Foundation". Observers can attend and join consensus seeking. Regular members commit to ongoing work; anyone active in the foundation can join by pull request, and members inactive for three months may be removed. Voting members carry formal decisions.

Voting membership changes in the Fall 2026 election cycle. Until then, each Impact project nominates up to two voting members, non-Impact projects together nominate up to two, and regular members up to two. From that cycle, Impact projects keep two seats each and the rest become up to five elected Community Voting Members. Either way, "No more than one-fourth of the Voting CPC members may be affiliated with the same employer", and a breach must be fixed straight away.

Under the charter, voting members approve new projects within the board's scope, make final decisions on aligning, removing or archiving projects, approve each project's charter, approve project budgets and the yearly CPC budget, and approve or remove working groups. The CPC also mediates conflicts between projects and is the foundation's technical liaison with standards bodies.

Who decides what

How do projects join and move through stages?

The Project Progression policy in the CPC repository governs this, and the process is the same for existing projects and new ones. A project emails an application to the new projects list (staff acknowledge within 48 hours). A confidential silent period follows; a rejected applicant is told privately. Before anything is public, CPC members get a private email with the application, a fit checklist, the names of the application manager and an application champion (a CPC member who must not be the applicant), and confirmation that the board has had an FYI with no objections. With consensus, the project enters incubation, works through an onboarding checklist and a two week charter review, and graduates when a pull request adds it to the CPC README at its stage.

The fit checklist asks about willingness to adopt open governance and the OpenJS code of conduct, licence compatibility, which trademarks and domains will transfer, and how existing IP was licensed. Security appears in onboarding: a project must publish a security policy that meets the foundation's minimum reporting rules and adopt an option from the GitHub continuity policy, which keeps the foundation able to act on a repository if maintainers disappear.

The stages

The policy defines one temporary stage, three graduated stages and two end of life stages.

Two lines matter when choosing dependencies. The policy tells end users to "evaluate At Large projects with care": the stage says a project fits the foundation, not that it is production grade. And the CPC may move a project to Feature-Complete, Sunsetting or Archived without maintainer approval if maintainers stop responding, so a stage change can signal that a project's people have gone quiet.

What Impact stage requires

To reach Impact stage, a project must show production use by at least two independent end users; have a governing body of at least five members with no more than a third from one employer (two of five may share one); publish its governance, contribution and release processes, preferably in GOVERNANCE.md; show a substantial ongoing flow of merged contributions; have committers from at least two organisations; adopt the foundation code of conduct; and "accept security reports and publicly disclose them after the fix has been made available". Impact projects get a binding CPC vote and ongoing financial and marketing support. At Large projects aiming for Impact agree a growth plan, "generally expected" to be met within two years. Every May, the CPC also runs a project health survey to keep maintainer contacts current.

A note on stage names

Older OpenJS material uses other names. The Security Compliance Guide, still a v1.0 draft, talks about "Retiring Projects (eg: Emeritus Projects)". The current policy and project list use Feature-Complete, Sunsetting and Archived and define no growth or emeritus stage. The CPC README is the record of a project's current stage.

Which projects does the OpenJS Foundation host?

The CPC README is the authoritative list. This is the list as we read it on 23 October 2026.

For dependency owners: Moment is Feature-Complete, so it still gets security and bug fixes but no features, which is a reason to plan a migration rather than start new code on it. jQuery UI and jQuery Mobile are Archived and will get no further fixes of any kind. ESLint, Jest, Lodash and Mocha are At Large, which reflects their governance and resourcing profile under the policy, not their popularity. The CPC also runs seven working groups, including Security, Package Vulnerability Management and Reporting, and Sustainability.

How does Node.js govern itself and its releases?

Node.js is the foundation's largest project, and its governance is defined in its own repository, not by the foundation board.

Collaborators and the Technical Steering Committee

The Node.js GOVERNANCE.md describes three layers. Triagers label, close and reopen issues. Collaborators have commit and CI access and land pull requests: two collaborators who did not write a change must approve it (one, if it has been open more than seven days), and any collaborator's objection blocks it unless the TSC votes otherwise. Collaborators with no authored or approved landed commit for 12 months become emeritus automatically.

The TSC, a subset of collaborators, has "final authority over this project": technical direction, governance, contribution policy, repository hosting, conduct guidelines and the collaborator list. It seeks consensus, elects a chair yearly and streams its meetings, with a private portion for sensitive topics including security vulnerabilities. Changes to the TSC charter need OpenJS CPC approval, one of the few direct links between Node.js and foundation governance.

The Release Working Group

The nodejs/Release repository defines who ships Node.js and when. The working group owns the release process, release content, testing, the release branches and backport policy. Its Releasers team holds the secrets and CI access to build and sign releases, and additions "must be approved by the TSC". The Backporters team alone lands commits on each LTS line's staging branch. The CITGM team maintains Canary in the Gold Mine, which runs major open source packages' test suites against upcoming builds. Changes generally live in a Current or Alpha release for at least two weeks before backport.

The LTS schedule, old and new

Up to Node.js 26, there were two majors a year: even numbers in April, odd in October. Even lines became LTS in October for 12 months Active then 18 months Maintenance ("critical bug fixes and security updates"); odd lines never became LTS and ended after about eight months. On 10 March 2026 the release team announced a new model from Node.js 27, citing volunteer workload: "Managing security releases across four or five active release lines has become difficult to sustain."

Version numbers will track the year of the first Current release (27.0.0 in 2027). Here is where the lines stand on 23 October 2026, from schedule.json in the Release repository:

How does the Node.js security team handle reports and publish security releases?

Node.js keeps its security process in SECURITY.md in the nodejs/node repository, and it is worth reading in full if Node.js is in your production path.

How reports come in

Reports go through the hosted reporting platform linked from SECURITY.md. The project aims to acknowledge within 5 days and respond with next steps within 10, noting that "these timelines may extend" when volunteers are away. With no acknowledgement in 6 business days, or silence for 14 days after one, reporters may escalate to the OpenJS Foundation CNA at security@lists.openjsf.org. Electron's SECURITY.md uses the same rule and address and takes reports through GitHub's private "Report a Vulnerability" flow. Bugs in third party modules go to their maintainers, and "The Node.js project no longer has a bug bounty program."

What counts as a vulnerability

SECURITY.md includes a threat model. Elements such as the operating system are trusted, and bugs that need a trusted element compromised first are out of scope. It lists many non-vulnerabilities, including malicious third party modules, prototype pollution in application code, same process self harm and attacks that need control of the build environment. It is the reference the security team uses when deciding whether a report is valid.

The disclosure process

The written disclosure policy runs like this:

1. A report is assigned a primary handler who coordinates the fix and the release.
2. The problem is checked against every supported release line, affected versions are listed, and the code is audited for similar problems.
3. Fixes are prepared for all supported lines and held privately.
4. An embargo date is chosen and a CVE is requested. Typically the embargo is set 72 hours after the CVE is issued.
5. On the embargo date the announcement goes to the nodejs-sec mailing list, fixes are pushed, builds go to nodejs.org, and within 6 hours a copy of the advisory appears on the Node.js blog.

A pre-announcement gives the affected lines and highest severity per line so operators can plan. CVE records can lag: the reporter is asked to disclose on the reporting platform, disclosure is forced after a day, then the platform approves it, so CVEs "will typically be disclosed within a few days of the release".

The process is still changing. The OpenJS second quarter 2026 security update says Node.js "no longer requires a public security embargo for most patches". CI used to be locked to the TSC during release preparation, so early fixes could only be tested in a crunch; with CI read access now limited to collaborators, a fix can be tested the day a report arrives. The same update describes beta release tooling with LLM assisted report validation.

Who sees private reports and patches

All TSC members see private reports and patches; releasers see private patches so they can build releases; the TSC can invite others when their expertise is needed. Everyone with access must keep undisclosed issues private.

Two CNAs: Node.js and the OpenJS Foundation

The CVE Program's partner list has two relevant records:

The OpenJS CNA sits under an open source root CNA. Its maintainer guide says it assigns CVE IDs for hosted projects, helps write records and advisories, and steps in when another CNA publishes an uncoordinated CVE about an OpenJS project: it asks for corrections, or for an invalid record to be rejected or marked DISPUTED. Since 2025, per the foundation's 2025 security report, the Node.js team has issued CVEs that name end of life versions and, with MITRE and the OpenSSF, updated older CVEs to list them. Node.js pre-announcements repeat that "End-of-Life versions are always affected when a security release occurs".

What a security release looks like: two dated examples

21 October 2026. The Node.js project published security releases for the 26.x, 24.x and 22.x lines: Node.js 26.12.1, 24.22.1 and 22.23.4. The announcement lists ten CVEs, four rated high, three medium and three low, and the highest severity in each line was high. It also lists bundled dependency updates: c-ares, the bundled CA certificate store (to handle an intermediate CA compromise), OpenSSL on 24.x and 22.x, SQLite on 22.x, and Undici. Node.js 20 received nothing, because it reached end of life on 30 April 2026. The release index at nodejs.org/dist/index.json marks 26.12.1 with "security": true, which is a field you can test in automation.

28 January 2026. When OpenSSL published an advisory with 12 CVEs, the Node.js team checked each against the OpenSSL version on every branch. Three affected Node.js, all in PFX (PKCS#12) parsing and rated low to moderate; the other nine touched APIs Node.js does not call or features it builds disabled. The three fixes went into regular releases, not a dedicated security release. An upstream CVE count tells you little until you check which code paths you ship.

The report volume problem

The second quarter 2026 update says Node.js received 352 reports in the two years before that quarter, and that reports spiked 4.6 times in February 2026 after AI agent assisted scanning arrived. On 11 September 2026 the OpenJS CNA announced a planned pause from 17 September to 6 October 2026, citing a surge in reports "generated or assisted by large language models"; actively exploited issues were still handled, and Express joined the break. On 22 October 2026 the foundation announced a €115,000 Sovereign Tech Agency investment to research whether some vulnerability classes can be fixed in public development: a classification framework, a shadow evaluation of an AI assisted classifier with humans deciding, then a controlled Node.js pilot measuring time from report to fix. Nothing changes today.

What security programs does the foundation run for hosted projects?

The foundation's security page says it works with maintainers "to understand their security baseline and identify opportunities for direct engineering support" and offers runbooks, templates and operational support on request.

Minimum security reporting requirements

Every OpenJS project must publish an easily found security policy, ideally SECURITY.md, that explains how to report confidentially through at least one private channel. It is a floor, not a full process; Impact stage adds public disclosure once a fix ships.

The Security Working Group and its guides

The Security Working Group, run from the security-collab-space repository, meets every two weeks and credits funding from the Sovereign Tech Agency and Alpha-Omega. Its documents include a coordinated disclosure runbook; the Security Compliance Guidelines, a v1.0 draft with 72 guidelines in 11 categories (from user authentication and GitHub workflows to dependency inventory and management) split into 22 priority groups and marked Expected, Recommended, Deferrable or Not Applicable by lifecycle stage; a Secure Releases guide, which recommends publishing from CI only on an explicit human request, never without two factor authentication (it notes an npm automation token "is a single factor"), enabling private vulnerability reporting and auditing dependencies on every commit; and guides on npm security, the CNA and SBOM challenges.

Assessments, threat models and hands on help

The 2025 security report (29 January 2026) says staff supported more than ten projects, completed security assessments for six and threat models for two, and launched the CNA. Express overhauled its vulnerability reporting with GitHub Security Advisories, ESLint and webpack gained escalation paths to OpenJS, Node.js published its first maintainers threat model, and automation cut the Node.js release steps per line from more than 20 to 3.

Funding programs

Three programs move money toward security and support.

The LTS program announcement says "roughly two thirds of Node.js users are running outdated or unsupported versions", which is the strongest argument for the inventory work below.

What about the EU Cyber Resilience Act?

The CRA entered into force on 10 December 2024. Reporting obligations for manufacturers apply from 11 September 2026 and the main obligations from 11 December 2027, according to the European Commission. The regulation creates an "open source software steward" role for foundations that support open source products intended for commercial use. Our Eclipse Foundation explainer covers what that role asks for.

We did not find an OpenJS publication describing a dedicated CRA readiness program, so we do not describe one. Several things the foundation runs line up with what a steward needs: a security policy requirement for every project, a foundation CNA, a disclosure guide and a compliance baseline. If CRA status matters for a dependency, ask the project and the foundation and keep the answer with your supplier records.

How does OpenJS compare with the PSF, Eclipse and Apache?

The table describes structure only. It is not a ranking, and each foundation's own documents are the authority.

The structural difference that matters most for consumers is where security response lives. Apache centralises vulnerability coordination in one team for every project. OpenJS leaves response with each project and puts a foundation CNA and working group behind them as support and escalation.

How should a company check an OpenJS hosted dependency's health?

Foundation membership tells you a project has a legal home and a published security policy, not that it is well staffed this year. These checks take about ten minutes per dependency and mostly script.

Step 1. Find the project's stage

The CPC README is the record. A quick check from a terminal:

curl -s https://raw.githubusercontent.com/openjs-foundation/cross-project-council/main/README.md \
  | grep -E '^#### |alt="logo of (project )?(Express|Moment|Lodash|jQuery UI)' \
  | sed -E 's/.*alt="logo of (project )?([^"]*)".*/  \2/'

It prints each stage heading and the projects under it. At Large means look at the project yourself; Feature-Complete, Sunsetting or Archived means plan a replacement.

Step 2. Check which Node.js line you run and its support status

node -v

# Release schedule for every line, from the Release Working Group
curl -s https://raw.githubusercontent.com/nodejs/Release/main/schedule.json \
  | jq --arg v "v$(node -v | sed -E 's/^v([0-9]+).*/\1/')" '.[$v]'

# Was the newest release on your line a security release?
curl -s https://nodejs.org/dist/index.json \
  | jq --arg m "v$(node -v | sed -E 's/^v([0-9]+).*/\1/')." \
       '[.[] | select(.version | startswith($m))][0] | {version, date, lts, security}'

If the end date has passed, or security is true on a newer release of your line, you are behind.

Step 3. Look at release cadence and maintainers

# Last ten published versions with dates
npm view express time --json | jq 'to_entries | map(select(.key|test("^[0-9]"))) | sort_by(.value) | .[-10:]'

# Who can publish the package
npm view express maintainers

# Governance files in the repository
gh api repos/expressjs/express/contents --jq '.[].name' | grep -iE 'governance|security|contributing|charter'

Quiet periods are fine for a mature library. What matters is whether known vulnerabilities get fixed and whether more than one person can publish.

Step 4. Read the security policy and past advisories

# The rendered policy GitHub shows for a repository
open https://github.com/electron/electron/security/policy

# Published repository security advisories, with severity and dates
gh api repos/electron/electron/security-advisories \
  --jq '.[] | {ghsa_id, severity, published_at, summary}' | head -40

Look for a private channel, a response time and an escalation route, such as the OpenJS CNA.

Step 5. Run an automated hygiene check

OpenSSF Scorecard checks branch protection, code review, pinned CI dependencies and token permissions, the same evidence the OpenJS compliance guidelines draw on.

export GITHUB_AUTH_TOKEN=$(gh auth token)
scorecard --repo=github.com/expressjs/express --format=json \
  | jq '{score, checks: [.checks[] | {name, score}]}'

Step 6. Verify what you install

# In a project with a lockfile: verify registry signatures and provenance attestations
npm ci
npm audit signatures

This verifies registry signatures and any provenance attestations: where a tarball came from, not whether its code is safe. For Node.js itself, check downloads against the signed checksum file, using the release keys listed in the nodejs/node README:

VERSION=v24.22.1
curl -sO https://nodejs.org/dist/$VERSION/SHASUMS256.txt.asc
curl -sO https://nodejs.org/dist/$VERSION/node-$VERSION-linux-x64.tar.xz
gpg --verify SHASUMS256.txt.asc
grep "node-$VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc | sha256sum -c -

Step 7. Fail CI when a runtime line reaches end of life

This job fails when the Node.js line in .nvmrc is past its end of life date.

name: node-support-window
on:
  pull_request:
  schedule:
    - cron: "0 6 * * 1"
jobs:
  check-node-eol:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version-file: ".nvmrc"
      - name: Fail if this Node.js line is past end of life
        run: |
          MAJOR="v$(node -v | sed -E 's/^v([0-9]+).*/\1/')"
          END=$(curl -s https://raw.githubusercontent.com/nodejs/Release/main/schedule.json | jq -r --arg v "$MAJOR" '.[$v].end')
          echo "Node.js $MAJOR end of life: $END"
          if [ "$(date -u +%F)" \> "$END" ]; then
            echo "::error::Node.js $MAJOR reached end of life on $END"
            exit 1
          fi

A decision table

Common mistakes

• Treating "OpenJS project" as a quality mark. At Large status "does not set requirements for community size, governance, or production readiness". Check the project.
• Assuming the foundation fixes vulnerabilities. Each project fixes its own code; the CNA and working group support and escalate.
• Running an odd numbered Node.js line in production. Before Node.js 27, odd lines never became LTS. Node.js 25 ended on 1 June 2026.
• Waiting for CVE records before patching. CVEs typically appear days after the release; the blog post and the security flag come first.
• Reading "not listed" as "not affected" for end of life versions. Node.js says they are always affected.
• Ignoring Feature-Complete and Archived libraries. Moment still gets security fixes; jQuery UI and jQuery Mobile do not.
• Counting upstream CVEs instead of checking reachability. Nine of twelve OpenSSL CVEs in January 2026 did not touch Node.js.
• Relying on a single publisher token. An npm automation token is a single factor. Publish from CI on explicit request, with more than one maintainer able to release.
• Pinning CI to lts/* and forgetting it moves. The alias is scheduled to point at Node.js 26 from 28 October 2026. Pin a major and upgrade deliberately.

FAQ

What is the OpenJS Foundation?

A US non-profit membership corporation that hosts open source JavaScript projects such as Node.js, Electron, Express, jQuery, webpack and ESLint. It holds their trademarks and domains, supplies governance and security processes, and funds shared work through memberships and grants.

When was the OpenJS Foundation formed?

The merger of the Node.js Foundation and the JS Foundation was announced on 12 March 2019, with 31 projects and 30 members at launch.

Is the OpenJS Foundation part of the Linux Foundation?

It is a separate Delaware corporation with its own bylaws and board, operating with Linux Foundation support for administration, legal and infrastructure services.

Who controls Node.js?

The Node.js Technical Steering Committee has final authority over technical direction and governance, and collaborators land changes. The CPC approves TSC charter changes, but neither it nor the board sets Node.js technical direction.

What is the Node.js LTS schedule?

Up to Node.js 26, even lines got 30 months of LTS (12 Active, 18 Maintenance). From Node.js 27, every line gets six months Alpha, six months Current and 30 months LTS. Node.js 22 ends on 30 April 2027 and Node.js 24 on 30 April 2028.

How do I report a security vulnerability in Node.js?

Use the channel in Node.js SECURITY.md; expect acknowledgement within 5 days. With no answer in 6 business days, or silence for 14 days, escalate to security@lists.openjsf.org.

Does Node.js pay bug bounties?

Not directly; its own program has ended. The OpenJS Security Stewardship Program, launched on 25 September 2026, splits pooled member money equally between bug bounties and paid maintainer patching, starting with Node.js.

Is the OpenJS Foundation a CVE Numbering Authority?

Yes, since 2025, for all projects on its projects page. Node.js has its own separate CNA record from 2017.

What do the OpenJS project stages mean?

Incubating projects are onboarding; At Large projects fit but carry no readiness requirements; Impact projects are mature and multi-employer governed; Feature-Complete projects get only fixes; Sunsetting projects have an end date; Archived projects get nothing.

How many projects does the OpenJS Foundation host?

The about page says "over 30". The CPC README we read on 23 October 2026 listed 6 Impact, 20 At Large, 5 Incubating and 5 Feature-Complete projects, plus 7 Archived ones.

Where Safeguard fits

The OpenJS Foundation and its projects run the governance, the release trains and the response processes described above. What they cannot do is tell you which of their packages, and which Node.js runtimes, are running in your own services, at which versions, and which of your projects need work when a security release lands. That is the gap Safeguard works in. The Safeguard CLI scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), matches the components it finds against vulnerability databases, and the platform shows which projects contain a given component and version, so an Express or webpack advisory becomes a list of affected projects instead of a search. Reachability analysis ranks the vulnerable code paths your application actually calls, and policies and gates evaluated in the platform can stop a known vulnerable version from shipping.

The fit is indirect for most of this post. Safeguard does not take part in the OpenJS CNA, Node.js embargoes or the Security Stewardship Program, and it does not replace any project's reporting channel. A Node.js binary installed on a host outside the images you build is also outside what an image or repository scan sees, so keep the runtime check in Step 2 in your own process. You can try the CLI from safeguard.sh/download, with setup steps in the CLI documentation.

Dependency hygiene matters here because a typical Node.js service pulls hundreds of npm packages on every fresh install, and a single OpenJS security release can touch the runtime, its bundled libraries such as OpenSSL and Undici, and popular frameworks at the same time. When a project publishes a fix, the remaining risk is the time it takes that fix to reach your builds, and the section below is about closing that gap rather than anything the foundation does.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. Lodash is an OpenJS At Large project, so this is the same flow you would use when Express, webpack or any other OpenJS package publishes a security release: ask for the upgrade, review each step and keep control of what lands.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, then runs a scan from the terminal. For teams that build Node.js services from a private npm mirror or keep source off hosted runners, this is how you scan where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If your team wants to ask an assistant which services still carry a package version named in the latest Node.js or Express advisory, this is how the assistant gets access to your Safeguard data, with the tool list set by you.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• OpenJS Foundation: About
• OpenJS Foundation: Governance
• OpenJS Foundation: Security
• OpenJS Foundation: Projects
• OpenJS Foundation First Amended and Restated Bylaws (9 January 2026)
• Cross Project Council README and project list
• Cross Project Council Charter
• OpenJS Project Progression policy
• Minimum security reporting requirements for OpenJS Foundation projects
• OpenJS Ecosystem Sustainability Program
• OpenJS Security Working Group (security-collab-space)
• OpenJS CNA Guide for OpenJS Maintainers
• OpenJS Security Compliance Guidelines v1.0 draft
• OpenJS Secure Releases and CVE Management guide
• Linux Foundation: Node.js Foundation and JS Foundation Merge to Form OpenJS Foundation (12 March 2019)
• OpenJS blog: 2025 security annual report (29 January 2026)
• OpenJS blog: Node.js LTS Upgrade and Modernization program (4 March 2026)
• OpenJS blog: Security update, Q2 2026 (8 July 2026)
• OpenJS blog: Meet our 2026 Board of Directors (22 July 2026)
• OpenJS blog: The OpenJS Foundation CNA is taking a coordinated break (11 September 2026)
• OpenJS blog: Security Stewardship Program launch (25 September 2026)
• OpenJS blog: Sovereign Tech Agency invests in OpenJS (22 October 2026)
• Node.js GOVERNANCE.md
• Node.js SECURITY.md
• Node.js Release Working Group README
• Node.js release schedule (schedule.json)
• Node.js: Previous releases
• Node.js: Security reporting
• Node.js release index (index.json)
• Node.js blog: Evolving the Node.js Release Schedule (10 March 2026)
• Node.js blog: OpenSSL Security Advisory Assessment, January 2026
• Node.js blog: Wednesday, October 21, 2026 Security Releases
• Node.js blog: vulnerability announcements
• Electron SECURITY.md
• CVE Program: OpenJS Foundation CNA
• CVE Program: Node.js CNA
• CVE Program partner data (CNAsList.json)
• European Commission: Cyber Resilience Act
• Apache Software Foundation: How the ASF works
• Apache Software Foundation: Security Team
• Eclipse Foundation Security Policy
• Python Software Foundation: About

Last reviewed: 23 October 2026. Node.js release dates, OpenJS project stages and CPC voting rules change over time; check the date and status on each linked page before relying on a specific rule.