forked from opensearch-project/OpenSearch-Dashboards
-
Notifications
You must be signed in to change notification settings - Fork 60
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
29 additions
and
47 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,67 +1,49 @@ | ||
| ## 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](https://github.com/wazuh/wazuh/security/advisories) under the "Security" tab in the relevant GitHub repository. Alternatively, you may send the details of your findings to [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. | ||
|
|
||
| - 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. | ||
| 2. Validation: We will validate the issue and work on reproducing it in our environment. | ||
|
|
||
| ``` | ||
| Example: If [email protected] exists for subdeps in yarn.lock file. But [email protected] is the target version. | ||
| 3. Remediation: We will work on a fix and thoroughly test it | ||
|
|
||
| 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 | ||
| 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. | ||
|
|
||
| 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. | ||
| This 90-day period allows for end-users to update their systems and minimizes the risk of widespread exploitation of the vulnerability. | ||
|
|
||
| ## Backport a Vulnerability Fix | ||
| ## 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. | ||
|
|
||
| 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: | ||
| ## 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. | ||
|
|
||
| 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. | ||
| 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. | ||
|
|
||
| ``` | ||
| Example: backport a pull request with hash 123 in main to 1.3 | ||
| ## 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. | ||
|
|
||
| * Fetch the latest changes from upstream repo: | ||
| git pull upstream | ||
| 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. | ||
|
|
||
| * Create a new local branch from the target version: | ||
| git checkout -b backport-cve upstream/1.3 | ||
| 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. | ||
|
|
||
| * Cherry pick the changes: | ||
| git cherry-pick 123 | ||
| ## 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. | ||
|
|
||
| * 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] |