forked from opensearch-project/OpenSearch-Dashboards
-
Notifications
You must be signed in to change notification settings - Fork 58
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Co-authored-by: Antonio <[email protected]> Co-authored-by: Chantal Belén kelm <[email protected]> Co-authored-by: JuanGarriuz <[email protected]> Co-authored-by: Federico Rodriguez <[email protected]>
- Loading branch information
5 people
authored
Oct 17, 2024
1 parent
162c0ca
commit 7e654e2
Showing
8 changed files
with
111 additions
and
79 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,67 +1,45 @@ | ||
| ## Reporting a Vulnerability | ||
| # Wazuh Open Source Project Security Policy | ||
|
|
||
| If you discover a potential security issue in this project we ask that you notify OpenSearch Security directly via email to [email protected]. Please do **not** create a public GitHub issue. | ||
| Version: 2023-06-12 | ||
|
|
||
| ## Fixing a Vulnerability | ||
| ## Introduction | ||
| This document outlines the Security Policy for Wazuh's open source projects. It emphasizes our commitment to maintain a secure environment for our users and contributors, and reflects our belief in the power of collaboration to identify and resolve security vulnerabilities. | ||
|
|
||
| - For direct dependencies (listed explicitly in `package.json`) - After identifying a version of the package that is both compatible with OpenSearch Dashboards and includes a fix for the vulnerability, update the dependency in `package.json` and run `yarn osd bootstrap` to build the project and update the `yarn.lock` file. | ||
| ## Scope | ||
| This policy applies to all open source projects developed, maintained, or hosted by Wazuh. | ||
|
|
||
| - For nested dependencies (sub-dependencies) | ||
| ## Reporting Security Vulnerabilities | ||
| If you believe you've discovered a potential security vulnerability in one of our open source projects, we strongly encourage you to report it to us responsibly. | ||
|
|
||
| - Check the package range in package.json: Open the `package.json` file and locate the dependency entry for the package you're interested in. The version range is specified after the package name, using a combination of version numbers and symbols. Examples of version ranges are ^1.0.0, ~1.0.0, or >=1.0.0 <2.0.0. Ensure that the desired version falls within the specified range. | ||
| Please submit your findings as security advisories under the "Security" tab in the relevant GitHub repository. Alternatively, you may send the details of your findings to [[email protected]](mailto:[email protected]). | ||
|
|
||
| - Check the desired version in `yarn.lock`: Open the `yarn.lock` file and search for the package name. If the package is listed, check the version number specified for the package. Compare this version number with the desired version. | ||
| ## Vulnerability Disclosure Policy | ||
| Upon receiving a report of a potential vulnerability, our team will initiate an investigation. If the reported issue is confirmed as a vulnerability, we will take the following steps: | ||
|
|
||
| - If the package range is suitable but `yarn.lock` does not include the desired version, edit the `yarn.lock` file and remove the lines corresponding to the package. Then, run `yarn osd bootstrap` to have the latest version of the package, that satisfies the range from `package.json`, added to `yarn.lock`. | ||
| 1. Acknowledgment: We will acknowledge the receipt of your vulnerability report and begin our investigation. | ||
| 2. Validation: We will validate the issue and work on reproducing it in our environment. | ||
| 3. Remediation: We will work on a fix and thoroughly test it | ||
| 4. Release & Disclosure: After 90 days from the discovery of the vulnerability, or as soon as a fix is ready and thoroughly tested (whichever comes first), we will release a security update for the affected project. We will also publicly disclose the vulnerability by publishing a CVE (Common Vulnerabilities and Exposures) and acknowledging the discovering party. | ||
| 5. Exceptions: In order to preserve the security of the Wazuh community at large, we might extend the disclosure period to allow users to patch their deployments. | ||
|
|
||
| - If the package range is not suitable and there is no resolutions or the package range in the resolutions is not correct, we can add or update version in the resolutions for all the package sub-deps or specific package sub-dep. For more on version updates please see [Why](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/#toc-why-would-you-want-to-do-this) and [How](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/#toc-how-to-use-it) to upgrade. | ||
| This 90-day period allows for end-users to update their systems and minimizes the risk of widespread exploitation of the vulnerability. | ||
|
|
||
| ``` | ||
| Example: If [email protected] exists for subdeps in yarn.lock file. But [email protected] is the target version. | ||
| ## Automatic Scanning | ||
| We leverage GitHub Actions to perform automated scans of our supply chain. These scans assist us in identifying vulnerabilities and outdated dependencies in a proactive and timely manner. | ||
|
|
||
| Step 1: remove the entry from lockfile and bootstrap; if a suitable version was installed, you can stop. | ||
| Step 2: use resolutions to require a specific range for the nested dependency in package.json: | ||
| 'resolutions': { "**/foobar": "^1.y", | ||
| "**/foo": "^2.x" , | ||
| "**/bar": "^3.k"} | ||
| Step 3: repeat step 1 | ||
| ## Credit | ||
| We believe in giving credit where credit is due. If you report a security vulnerability to us, and we determine that it is a valid vulnerability, we will publicly credit you for the discovery when we disclose the vulnerability. If you wish to remain anonymous, please indicate so in your initial report. | ||
|
|
||
| ``` | ||
| We do appreciate and encourage feedback from our community, but currently we do not have a bounty program. We might start bounty programs in the future. | ||
|
|
||
| Please be aware of that fixing nested dependencies can be tricky. Sometimes, bumping a parent package of the nested dependency can upgrade several of the nested dependencies at once to solve multiple security vulnerabilities and provide a more maintainable code base. | ||
| ## Compliance with this Policy | ||
| We consider the discovery and reporting of security vulnerabilities an important public service. We encourage responsible reporting of any vulnerabilities that may be found in our site or applications. | ||
|
|
||
| ## Backport a Vulnerability Fix | ||
| Furthermore, we will not take legal action against or suspend or terminate access to the site or services of those who discover and report security vulnerabilities in accordance with this policy because of the fact. | ||
|
|
||
| To backport a CVE fix to previous versions of OpenSearch Dashboards, add the desired backport labels (e.g., backport 1.x) to the PR. Upon merging the PR, a workflow will attempt to backport it. If this process fails, the PR will be updated with a comment detailing the failure, and you'll need to follow the provided instructions to manually backport the changes in a new PR. Keep in mind that some CVEs may require distinct resolutions for each branch, such as a major version bump in the main branch, a minor version bump in the 2.x branch, and a specific resolution in the 1.x branch. Refer to the following steps for guidance: | ||
| We ask that all users and contributors respect this policy and the security of our community's users by disclosing vulnerabilities to us in accordance with this policy. | ||
|
|
||
| 1. Identify the pull request you want to backport and the target backport version. | ||
| 2. Create a new local branch from the target version. | ||
| 3. Cherry-pick the changes from the pull request into the new branch. To do this, you can use the `git cherry-pick` command followed by the hash of the pull request commit. For example: `git cherry-pick 123456`. | ||
| 4. Resolve any conflicts. This step may require some manual intervention. | ||
| 5. Run `yarn osd bootstrap` in the root directory. This will update the dependencies, install the latest version of the package that satisfies the range from `package.json`, and add the updated package information to the `yarn.lock` file. | ||
| 5. Test the changes thoroughly. | ||
| 6. Push the new branch to the appropriate remote repository. | ||
| 7. Submit a new pull request to the target version for the backported changes. | ||
| ## Changes to this Security Policy | ||
| This policy may be revised from time to time. Each version of the policy will be identified at the top of the page by its effective date. | ||
|
|
||
| ``` | ||
| Example: backport a pull request with hash 123 in main to 1.3 | ||
| * Fetch the latest changes from upstream repo: | ||
| git pull upstream | ||
| * Create a new local branch from the target version: | ||
| git checkout -b backport-cve upstream/1.3 | ||
| * Cherry pick the changes: | ||
| git cherry-pick 123 | ||
| * Resolve any conflicts. | ||
| * Push to your origin forked repo: | ||
| git push -u origin backport-cve | ||
| * Submit a new pull request to 1.3. | ||
| ``` | ||
|
|
||
| It's worth noting that backporting a pull request can be a complex process and depending on the changes involved, additional steps might be required to resolve conflicts. It's important to carefully review and test the changes to ensure they are compatible with the version of OpenSearch Dashboards in the target branch and that the changes are applied correctly. | ||
| If you have any questions about this Security Policy, please contact us at [[email protected]](mailto:[email protected]) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -506,4 +506,4 @@ | |
| "node": ">=14.20.1 <19", | ||
| "yarn": "^1.22.10" | ||
| } | ||
| } | ||
| } | ||
Oops, something went wrong.