diff --git a/docs/CNA/cna-guide-for-openjs-maintainers.md b/docs/CNA/cna-guide-for-openjs-maintainers.md index d529558..4048dce 100644 --- a/docs/CNA/cna-guide-for-openjs-maintainers.md +++ b/docs/CNA/cna-guide-for-openjs-maintainers.md @@ -82,14 +82,14 @@ Despite your project being within the scope of the OpenJS CNA, there is a small Thanks to Alpha-Omega funding, the OpenJS Security Working Group can directly support and implement these improvements to your project: -* Improve your create your Vulnerability Disclosure Policy +* Improve or create your Vulnerability Disclosure Policy * Transition to a specialized vulnerability disclosure tool (eg: GitHub Private Vulnerability Reporting) * Improve or create internal vulnerability disclosure and management processes To get started, open an issue in the [Security Working Group repo](https://github.com/openjs-foundation/security-collab-space) and provide the following information: * What you would like support with -* Past successes and challenges you’ve had security researchers +* Past successes and challenges you’ve had with security researchers * Link(s) to your current or draft policy if you have one * Your preferred timelines for when this work should happen * At least two proposed meeting times to answer questions and discuss next steps diff --git a/docs/CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md b/docs/CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md index 28a2b42..ac440c9 100644 --- a/docs/CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md +++ b/docs/CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md @@ -45,12 +45,12 @@ Besides the On Call Role, this runbook uses the roles defined the GitHub Private ### Responsibilities: Reporter * Submits the vulnerability Report -* Adds othe Finder(s) who discovered the security vulnerability as Collaborators +* Adds other Finder(s) who discovered the security vulnerability as Collaborators * Responds to questions and coordination requests from the Project * Validates the remediation patch >[!NOTE] ->In most cases the Reporter likely to also be the Finder. The role of Reporter is used throughout this runbook. +>In most cases, the Reporter is likely to also be the Finder. The Reporter role is used throughout this runbook. ## Introduced in Phase 1: Tier 1 Triage @@ -62,9 +62,9 @@ Besides the On Call Role, this runbook uses the roles defined the GitHub Private ### Responsibilities: Coordinator -* Assist Triage Analyst w Documentation +* Assist Triage Analyst with Documentation * Gather Feedback, Edit and Send NMI Response -* Fasciliate Discussions with Team +* Facilitate Discussions with Team * Organize and Track Fix Action Items * Informs Reporter of Tier 2 Triage Decision * Send Reporter Regular Updates (as appropriate) @@ -73,7 +73,7 @@ Besides the On Call Role, this runbook uses the roles defined the GitHub Private * Propose Updated CWE >[!NOTE] ->It's possible that the Triage Analyst and Coordinator roles will be performed by the same individual during Tier 1 Triage. In some Projects, the Coordinator role may transition to another person dedicated person during the Tier 2 Triage or Fix Phases. +>It's possible that the Triage Analyst and Coordinator roles will be performed by the same individual during Tier 1 Triage. In some Projects, the Coordinator role may transition to another dedicated person during the Tier 2 Triage or Fix Phases. ## Introduced in Phase 2: Tier 2 Triage @@ -94,7 +94,7 @@ Besides the On Call Role, this runbook uses the roles defined the GitHub Private * Draft the Technical Portion of the Short-Term Mitigation Plan (as needed) * Draft the Technical Mitigation/Remediation Plan(s) * Author Code Changes per the Plan(s) -* Test Repro Steps the Against Patch to Verify Fix Efficacy +* Test Repro Steps Against the Patch to Verify Fix Efficacy * Author Documentation Changes (as needed) ### Responsibilities: Remediation Reviewer @@ -135,7 +135,7 @@ This feature cannot be disabled. [Click here](https://docs.github.com/en/code-se # 2. [T1] On Call Performs Tier 1 Triage and Drafts an Initial Acknowledgement -In this Step, it is the On Call's responsibility to to determine which of the following criteria are relevant to the Report in order to determine the best way to proceed with an Initial Acknowledgement. +In this Step, it is the On Call's responsibility to determine which of the following criteria are relevant to the Report in order to determine the best way to proceed with an Initial Acknowledgement. - 2a. Contains any of the Security Escalation Criteria - 2b. Is missing data to understand or reproduce the vulnerability @@ -153,7 +153,7 @@ Remember, it's not necessary during Tier 1 to have a full understanding of the v | **Already Publicly Disclosed (0day)** | The vulnerability has been disclosed publicly regardless of intent, context, or whether it has since been taken down. | | **Active Exploitation** | The vulnerability has a functional exploit and there is evidence it has been weaponized by a malicious actor. | | **Critical Severity** | Obviously critical or CVSS Score => 9.0. Be sure to validate using the CVSS Calculator and/or phone a friend first. | -| **Disclosure Threats** | Threats of uncoordinated public disclosure not within our [VDP] without implied exortion. | +| **Disclosure Threats** | Threats of uncoordinated public disclosure not within our [VDP] without implied extortion. | > If the Report passes the Step 2 checks, draft your response using the [Initial Acknowledgement: Security Escalation Template]. @@ -161,7 +161,7 @@ Remember, it's not necessary during Tier 1 to have a full understanding of the v Our [Vulnerability Disclosure Policy] describes what fields and information we need to independently triage and reproduce potential security vulnerabilities. -Be sure to read the entire report for any obviously information that would be needed during later triage. It's ok if you miss something subtle and we have to go back and ask for more information latter. While all information is important, key points to focus on are: +Be sure to read the entire report for any obvious information that would be needed during later triage. It's ok if you miss something subtle and we have to go back and ask for more information later. While all information is important, key points to focus on are: - Steps to Reproduce - Proposed Impact @@ -171,7 +171,7 @@ Be sure to read the entire report for any obviously information that would be ne ## 2c. Not a security vulnerability report? -Our initial acknowledgement should demonstrate that the Report was at least read for comprehension and that a templated response just not just blindly sent to meet a published SLAs. Be sure to check for: +Our initial acknowledgement should demonstrate that the Report was at least read for comprehension and that a templated response was not just blindly sent to meet a published SLAs. Be sure to check for: - Spam - Feature Requests @@ -202,7 +202,6 @@ Our initial acknowledgement should demonstrate that the Report was at least read | Send the appropriate initial acknowledgement to the Reporter | | Summarize the vulnerability and next steps for others on the team | - # 3. [T1] On Call Begins Organizing Internal Discussion by Creating a Tracking Discussion for the Vulnerability If the Report appears to contain a valid security vulnerability or meets an escalation criteria, the On Call begins documenting the Report and their Tier 1 Triage by creating a new GitHub Discussion in the [Private SecurityWG Repo]. @@ -237,8 +236,6 @@ This Step comes before sending the Initial Acknowledgement to the Reporter so th # 5. [T1] On Call Sends the Reporter an Initial Acknowledgement of Receipt - - This Initial Acknowledgement is probably the first time you have ever communicated with this Reporter/Security Researcher. The first few days after submitting a vulnerability report to a Bug Bounty or CVD Program are the most uncertain for a security researcher, especially if this is the first time they've submitted a vulnerability to your Program. The most important thing your Initial Acknowledgement should do is: @@ -313,14 +310,14 @@ During this Step, the Triage Analyst's primary responsibility is to reproduce th ### Document More Detailed Reproduction Steps -While attempting reproduction, it is common to find omissions and errors in the Reporter's Repro Steps. Using the original Report as a base, the Triage Analyst should - as needed - clean up and more thoroughly document the their environment, tools, and steps that were not captured by the Reporter for use by others on the team. +While attempting reproduction, it is common to find omissions and errors in the Reporter's Repro Steps. Using the original Report as a base, the Triage Analyst should - as needed - clean up and more thoroughly document their environment, tools, and steps that were not captured by the Reporter for use by others on the team. #### Success: Two Person Verification This runbook recommends that once the vulnerability is successfully reproduced by the Triage Analyst, a second team member should validate this using the updated Repro Steps. > [!IMPORTANT] -> The Reporter should be notified using the [guidance in Step 8b] as soon as the vulnerability in their Report is repeatedly reproducable. The additional root cause and impact analysis work described below in [Step 9] **should not block** this notification. +> The Reporter should be notified using the [guidance in Step 8b] as soon as the vulnerability in their Report is repeatedly reproducible. The additional root cause and impact analysis work described below in [Step 9] **should not block** this notification. ### Unable to Reproduce: Need More Information (NMI) @@ -330,7 +327,7 @@ Despite the inability to reproduce and validate the vulnerability, at this Step #### NMI: Two Person Verification -This runbook recommends that if the Triage Analyst is unable to reproduce the vulnerability, another member of the team should make an independent attempt in order to control for environmental factors and natural human error. Te Reporter be notified of this only once two team members have independently failed to reproduce the vulnerability. +This runbook recommends that if the Triage Analyst is unable to reproduce the vulnerability, another member of the team should make an independent attempt in order to control for environmental factors and natural human error. The Reporter be notified of this only once two team members have independently failed to reproduce the vulnerability. > [!TIP] > Guidance on how to optimize for comms success when requesting more information from the Reporter is discussed in [Step 8a]. @@ -381,17 +378,17 @@ Specific information that should be captured during root cause analysis also inc ## 9b. Assess and Document Impact and Exploitability -Once the true root cause(s) are known, for each root cause the Triage Analyst should independently assess and document the impact and exploitability of the the actual vulnerability (which may differ from the Report) in **detail** and in a **brief summary**. +Once the true root cause(s) are known, for each root cause the Triage Analyst should independently assess and document the impact and exploitability of the actual vulnerability (which may differ from the Report) in **detail** and in a **brief summary**. ### Important Details to Capture -- **Problem:** The flaw/software defect of the root cause.. +- **Problem:** The flaw/software defect of the root cause. - **Attack:** What would a real world attack using this vulnerability look like? Be sure to include the target conditions needed for success. - **Impact:** When successfully exploited, what are the direct and indirect impacts? ### Assess the Reporter's Assertions -As part of this, the Triage Analyst should also explicitly identify and any unsupported or erroneous assertions in the original Report in a fact-based, dispassionate tone to to ensure the team and Reporter have a shared understanding of the actual vulnerability. +As part of this, the Triage Analyst should also explicitly identify and any unsupported or erroneous assertions in the original Report in a fact-based, dispassionate tone to ensure the team and Reporter have a shared understanding of the actual vulnerability. ### Brief Security Advisory Description @@ -450,9 +447,9 @@ It is not necessary for there to be consensus on the initial, brief Tier 2 Triag ## 10b. Agree to Completely Remediate the Vulnerability -In a perfect world all known security vulnerabilities would be completely remediated. +In a perfect world, all known security vulnerabilities would be completely remediated. -However, in practice there are scenarios where it may not be appropriate or possible to immediately prioritize a code change that completely remediates the reported behavior. +However, in practice, there are scenarios where it may not be appropriate or possible to immediately prioritize a code change that completely remediates the reported behavior. This runbook assumes that the [SecurityWG] will choose to completely remediate the vulnerability whenever possible, even if this choice requires negotiating a longer disclosure timeline with the Reporter due to the effort required for remediation. diff --git a/docs/SBOM/OpenJS-SBOM-CSCRM-Challenges-Recommendations.md b/docs/SBOM/OpenJS-SBOM-CSCRM-Challenges-Recommendations.md index 81e2fd9..ac8eaa0 100644 --- a/docs/SBOM/OpenJS-SBOM-CSCRM-Challenges-Recommendations.md +++ b/docs/SBOM/OpenJS-SBOM-CSCRM-Challenges-Recommendations.md @@ -28,7 +28,7 @@ The OpenJS Foundation supports the intent of the regulatory regime governments a * **SBOMs in the Node.js ecosystem** * Should only be generated for end-user facing JavaScript applications and never for individual Javascript libraries that do not provide functionality for end users. This is due to npm’s dependency resolution algorithm, which produces dependency trees for isolated libraries that should not be expected to represent the dependencies of that library when resolved in the context of a JavaScript application. Thus, only JavaScript applications should generate SBOMs. * **npm Package Provenance** - * I not recommended for JavaScript libraries and applications as currently implemented as it does not provide the real world security value that many assume it does. We’ve recommended several substantial improvements to npm and GitHub to resolve these gaps so that the sometimes substantial effort needed to implement package provenance can be justified. + * Is not recommended for JavaScript libraries and applications as currently implemented as it does not provide the real world security value that many assume it does. We’ve recommended several substantial improvements to npm and GitHub to resolve these gaps so that the sometimes substantial effort needed to implement package provenance can be justified. Below is a detailed analysis of the relevant features and real world scenarios that explain how we came to these conclusions. We look forward to hearing feedback and engaging with open source advocates, regulators, and GitHub on our recommendations so that we can help make the Internet a safer place. @@ -184,7 +184,7 @@ Unfortunately, this does not appear to be the case. Below is a review of the gap * Lack of support for MFA prompts in GitHub Actions requires maintainers to use single factor access tokens and stop using credentials that support MFA * Use of GitHub Actions increases the attack surface for package hijacking by: - * Likely increasing the number users able to publish a given package + * Likely increasing the number of users able to publish a given package * Inserting other attack vectors, such as takeover of other GH Actions used during the build process * Requiring manual log analysis to validate that only code in the source repository is included in the published package * Short maximum and configurable log retention limits the timeframe for when this manual log analysis can happen @@ -289,7 +289,6 @@ The unfortunate real world impact of this means that connection intended to prov ## **npm Package Provenance Conclusion and Recommendations** - In its current state, npm’s package provenance functionality does not appear to provide sufficient real world security value to justify the potentially substantial effort required to implement it. For this reason, the OpenJS Foundation’s Security Working Group removed all initially proposed provenance related entries from its v1 Security Compliance Guidelines for OpenJS projects. We recommend that OpenJS projects focus their security improvement efforts on higher impact guidelines. @@ -319,7 +318,7 @@ It is not possible to publish the package-lock.json to the npm Registry in its * #### **npm-shrinkwrap.json** -This file’s syntax and contents are identical to package-lock.json but it is able to be published to the npm Registry. However, it is rarely used and only published to the npm Registry when the package maintainer wishes to prescriptively enforce their package dependency tree on downstream users. npm-shrinkwrap.json files, though rarely used, are most typically found in freestanding JavaScript application packages rather than library packages. +This file’s syntax and contents are identical to package-lock.json, but it can be published to the npm Registry. However, it is rarely used and only published to the npm Registry when the package maintainer wishes to prescriptively enforce their package dependency tree on downstream users. npm-shrinkwrap.json files, though rarely used, are most typically found in freestanding JavaScript application packages rather than library packages. * #### **package.json** @@ -329,7 +328,7 @@ Since the package.json dependency list only contains direct package dependencies ### **SBOM Tooling for npm** -The npm sbom command generates a SBOM describing the package and its dependencies in either [CycloneDX](https://cyclonedx.org/specification/overview/) or [SPDX](https://spdx.dev/learn/overview/) format. Maintainers have the choice of generating an SBOM based on the observed contents of the node\_modules folder (default) or only based on the contents of the package-lock.json file. +The `npm sbom` command generates a SBOM describing the package and its dependencies in either [CycloneDX](https://cyclonedx.org/specification/overview/) or [SPDX](https://spdx.dev/learn/overview/) format. Maintainers have the choice of generating an SBOM based on the observed contents of the node\_modules folder (default) or only based on the contents of the package-lock.json file. [image1]: https://github.com/user-attachments/assets/0ae907d3-b2e5-47ca-a28c-f57605957567 [image2]: https://github.com/user-attachments/assets/c9bd9d1d-37ed-41de-9a24-585466d1b037