From 70d9d037c3ba5e915f24b27a2b36dce07b933a97 Mon Sep 17 00:00:00 2001 From: Benjamin Sternthal Date: Tue, 28 Oct 2025 09:20:14 -0700 Subject: [PATCH] Add contributors section to README Added contributors section with committers, security triage, and publishers. Co-authored-by: Benjamin Sternthal Co-authored-by: Jon Church Co-authored-by: Tobie Langel --- GOVERNANCE.md | 25 +++++++++++++++++++++++++ README.md | 6 ++++++ incident_response_plan.md | 22 ++++++++++++---------- 3 files changed, 43 insertions(+), 10 deletions(-) create mode 100644 GOVERNANCE.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 000000000..bdcffff82 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,25 @@ +> [!IMPORTANT] +> As announced on the [OpenJS Foundation blog](https://openjsf.org/blog/sta-supports-lodash), Lodash has received support from the Sovereign Tech Agency and will transition to the Feature-Complete maturity stage so that it remains stable, secure, and sustainable long-term. As part of this effort, Lodash is rebooting its governance. A draft charter will be published shortly. The upcoming Technical Steering Committee (TSC) is already at work. For transparency, its members are listed below. + +# Lodash Governance + +## Technical Steering Committee Members + +The current Technical Steering Committee (TSC) members are: + +- John-David Dalton ([@jdalton](https://github.com/jdalton)), _(Lodash creator)_ +- Jon Church ([@jonchurch](https://github.com/jonchurch)) +- Jordan Harband ([@ljharb](https://github.com/ljharb)) +- Michał Lipiński ([@falsyvalues](https://github.com/falsyvalues)) +- Tobie Langel ([@tobie](https://github.com/tobie)) +- Ulises Gascón ([@ulisesgascon](https://github.com/UlisesGascon)) + +## Security Triage Team + +The Security Triage Team is responsible for assessing and managing vulnerability and incident reports. Security triaging is currently handled by the [TSC](#technical-steering-committee-members). + +## Release Team + +The Release Team is solely responsible for publishing new versions of Lodash to npm. Its current member is: + +- John-David Dalton ([@jdalton](https://github.com/jdalton)) diff --git a/README.md b/README.md index 9d2ce70cb..10be884b2 100644 --- a/README.md +++ b/README.md @@ -6,9 +6,13 @@ [Contributing](https://github.com/lodash/lodash/blob/master/.github/CONTRIBUTING.md) | [Wiki](https://github.com/lodash/lodash/wiki "Changelog, Roadmap, etc.") | [Code of Conduct](https://js.foundation/conduct/) | +[Governance](https://github.com/lodash/lodash/blob/HEAD/GOVERNANCE.md) | [Twitter](https://twitter.com/bestiejs) | [Chat](https://gitter.im/lodash/lodash) +> [!IMPORTANT] +> As announced on the [OpenJS Foundation blog](https://openjsf.org/blog/sta-supports-lodash), Lodash has received support from the Sovereign Tech Agency and will transition to the Feature-Complete maturity stage so that it remains stable, secure, and sustainable long-term. As part of this effort, Lodash is rebooting its governance. A draft charter will be published shortly. The upcoming Technical Steering Committee (TSC) is already at work. For transparency, its members are listed in [GOVERNANCE.md](https://github.com/lodash/lodash/blob/HEAD/GOVERNANCE.md). + The [Lodash](https://lodash.com/) library exported as a [UMD](https://github.com/umdjs/umd) module. Generated using [lodash-cli](https://www.npmjs.com/package/lodash-cli): @@ -78,3 +82,5 @@ Lodash is available in a [variety of builds](https://lodash.com/custom-builds) & * [lodash-es](https://www.npmjs.com/package/lodash-es), [babel-plugin-lodash](https://www.npmjs.com/package/babel-plugin-lodash), & [lodash-webpack-plugin](https://www.npmjs.com/package/lodash-webpack-plugin) * [lodash/fp](https://github.com/lodash/lodash/tree/npm/fp) * [lodash-amd](https://www.npmjs.com/package/lodash-amd) + + diff --git a/incident_response_plan.md b/incident_response_plan.md index 800123b50..d56b81001 100644 --- a/incident_response_plan.md +++ b/incident_response_plan.md @@ -1,11 +1,11 @@ # Incident Response Plan ## Introduction -Security is a top priority for Lodash team. This document outlines the **formal process** for handling **security reports**, including how to **triage**, **assess**, and **disclose** vulnerabilities responsibly. +Security is a top priority for Lodash. This document outlines the **formal process** for handling **security reports**, including how to **triage**, **assess**, and **disclose** vulnerabilities responsibly. ## Scope -The Security Triage Team will use this document as a process guide when a security vulnerability is reported, from triage to resolution. This process must align with the project's [SECURITY policy](SECURITY.md) and cannot diverge significantly. +The [Security Triage Team][] will use this document as a process guide when a security vulnerability is reported, from triage to resolution. This process must align with the project's [SECURITY policy](SECURITY.md) and cannot diverge significantly. ## Security Report Handling Flowchart @@ -76,7 +76,7 @@ This person submits a security report to the Security Triage Team and provides d **Expectations** - Provide detailed information about the suspected vulnerability. - Follow responsible disclosure guidelines (report privately before public disclosure). -- Cooperate with the security team by providing additional details when needed. +- Cooperate with the Security Triage Team by providing additional details when needed. - Test and verify patches (when applicable). - Respect security timelines and avoid premature public disclosure. @@ -120,7 +120,7 @@ This person acts as the focal point for a specific security report and ensures t ## Runbook -The following sections outline the **step-by-step process**, explaining each decision, scenario, and possible actions. In this guide we also include links that are private (limited to the security triage team), a general overview of the process in flowchart format can be found [here](#security-report-handling-flowchart). +The following sections outline the **step-by-step process**, explaining each decision, scenario, and possible actions. In this guide we also include links that are private (limited to the Security Triage Team), a general overview of the process in flowchart format can be found [here](#security-report-handling-flowchart). ### Step 0: Security Report Received @@ -135,9 +135,9 @@ Ideally, the report must contain **clear and detailed information** like (Affect > [!Note] > While this document refers to a single SRC for simplicity, in practice, having two coordinators is acceptable and often beneficial. A second coordinator can assist with tasks such as reviewing the advisory content before it is published, ensuring accuracy and completeness. -1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information ASAP in the private slack channel `#lodash-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. +1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information ASAP in the private slack channel `#lodash-security-triage` so the Security Triage Team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. -1.2.1 In the case of a report made public in a Pull request or issue under the Lodash organization the following process will be followed (by a Lodash TC member): +1.2.1 In the case of a report made public in a Pull request or issue under the Lodash GitHub organization the following process will be followed (by a Lodash TSC Member): * Move the issue to the private repository called [lodash/security-triage](https://github.com/lodash/security-triage). * For any related pull requests, create an associated issue in [lodash/security-triage](https://github.com/lodash/security-triage) repository. Add a copy of the patch for the pull request to the issue. Add screenshots of discussion from the pull request to the issue. @@ -149,7 +149,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect > FYI @xxxx we asked GitHub to delete your pull request while we work on releases in private. * Update the team in the slack channel #lodash-security-triage`. -1.2.2 In the case that the report is made public in a different channel that we don't own/control, the TC team will attempt to mitigate this by trying to remove the report from public view (reporting to support, asking the reporter to remove the report, etc...). +1.2.2 In the case that the report is made public in a different channel that we don't own/control, the Lodash TSC will attempt to mitigate this by trying to remove the report from public view (reporting to support, asking the reporter to remove the report, etc...). 1.3 At this stage the Security Report Coordinator (SRC) will create a (private) issue in [lodash/security-triage](https://github.com/lodash/security-triage) repository with the existing information from the security report unless it already exists (step 1.2.1). This issue will serve as the central discussion point for this particular report. At this stage is expected from the Security Report Coordinator (SRC) to acknowledge receipt of the security report to the reporter. @@ -171,12 +171,14 @@ Ideally, the report must contain **clear and detailed information** like (Affect 3.2 The mitigation team (remediation developer(s), analyst(s), reporter(s)) will work on the patch(es), re-evaluate the report once the patch is ready and include regression tests (when possible). -3.3 The Lodash TC will announce publicly on a public issue that there is security patch available and the plan to do a release with an specific date (ideally) and the versions affected without providing additional information to prevent early disclosure. +3.3 The Lodash TSC will announce publicly on a public issue that there is security patch available and the plan to do a release with an specific date (ideally) and the versions affected without providing additional information to prevent early disclosure. -3.4 The TC team will create the releases and publish them to npm. +3.4 The Lodash TSC will create the releases and publish them to npm. ### Step 4: Public disclosure 4.1 At this stage the Security Report Coordinator (SRC) will make the advisory public and close the coordination issue (opened in step 1). -4.2 The Security Report Coordinator (SRC) can ask the TC team to coordinate blog post or social media announcements using the OpenJS Foundation channels. \ No newline at end of file +4.2 The Security Report Coordinator (SRC) can ask the Lodash TSC to coordinate blog post or social media announcements using the OpenJS Foundation channels. + +[Security Triage Team]: GOVERNANCE.md#security-triage-team