[Doc] Modify SECURITY.md nested dependency fix and add backport process

Issue Resolved:
#3494

Signed-off-by: Anan Zhuang <[email protected]>

CHANGELOG.md

@@ -125,6 +125,7 @@ Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 - Updates NOTICE file, adds validation to GitHub CI ([#3051](https://github.com/opensearch-project/OpenSearch-Dashboards/pull/3051))
 - [Doc] Add current plugin persistence implementation readme ([#3081](https://github.com/opensearch-project/OpenSearch-Dashboards/pull/3081))
 - Correct copyright date range of NOTICE file and notice generator ([#3308](https://github.com/opensearch-project/OpenSearch-Dashboards/pull/3308))
+- [Doc] Modify SECURITY.md nested dependency fix and add backport process ([#3497](https://github.com/opensearch-project/OpenSearch-Dashboards/pull/3497))
 
 ### 🛠 Maintenance
 

SECURITY.md

@@ -1,27 +1,77 @@
 ## Reporting a Vulnerability
 
-- If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do **not** create a public GitHub issue.
-
-- For Security-CVE related fix - 
-    - For direct dependency - Use ```yarn upgrade package``` to update the package and in order to enforce as sub-deps please add nested-dep step2.
-
-    - For nested dependency/sub-deps - In order to enforce package above Vx.y.z, we can add version in the resolutions [section](https://classic.yarnpkg.com/lang/en/docs/selective-version-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.
-    - To add the CVEs fix to previous versions, add label ex: backport 1.x. 
-
-      ```
-      Example: [email protected] vulnerable package and 1.y is the fix 
-      step 1: 
-      For direct dependency checks: 
-              run: yarn upgrade [email protected] to update the package.json 
-              and yarn install to update the yarn.lock file
-      Step 2.
-      Check for sub deps foobar in other package. 
-              If [email protected] exists for subdeps in yarn.lock file
-              Then edit the package.json file and add **/[email protected] in resolution section as shown below to enforce the 1.y.
-                'resolutions': { "**/foobar": "^1.y", 
-                                 "**/foo": "^2.x" ,
-                                 "**/bar": "^3.k"}
-              Then run: yarn install for updating yarn.lock file
-
-
+If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do **not** create a public GitHub issue.
+
+
+- For direct dependency - There are two ways to update. First one is update the package version directly in the package.json then run ```yarn osd bootstrap```.  Second way is to use ```yarn upgrade package``` to update the package. In order to enforce as sub-deps please add nested-dep step2.
+
+```
+Example: We have a vulnerable [email protected] and 1.y is the fix.
+
+option-1: update foobar from @1.x to @1.y in package.json and run yarn osd bootstrap.
+
+option-2: run yarn upgrade [email protected] to update the package.json and yarn install to update the yarn.lock file.
+```
+
+- For nested dependency/sub-deps
+
+    - If package.json is correct but yarn.lock does not fetch the lastest version, could remove package in yarn.lock and run `yarn osd bootstrap`.
+
+    ```
+    Example: We have a vulnerable package [email protected] and 1.x.z is the fix. In package.json, we have foobar@^1.x.y which should update you to all future minor/patch versions, without incrementing the major version.
+
+    Find [email protected] in yarn.lock and remove it.
+    Run yarn osd bootstrap
+
+    ```
+
+    - If package.json is not correct, we can add version in the resolutions [section](https://classic.yarnpkg.com/lang/en/docs/selective-version-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.
+
+    ```
+    Example: If [email protected] exists for subdeps in yarn.lock file. Then edit the package.json file and add **/[email protected] in resolution section as shown below to enforce the 1.y.
+
+    Add the package to resolution in package.json:
+    'resolutions': { "**/foobar": "^1.y",
+                     "**/foo": "^2.x" ,
+                     "**/bar": "^3.k"}
+    Then run: yarn install for updating yarn.lock file
+
+    ```
+
+    Please be aware of that fixing nested dependency can be tricky. Sometimes, bump the dependent package will auto bump all the nested dependencies which will solve multiple security vulnerabilities and provide a more maintainable code base.
+
+- To backport the CVEs fix to previous versions, add backport label (ex: `backport 1.x`) to trigger auto backport. If auto backport fail, pls use the following steps to manually backport:
+
+    - Identify the pull request you want to backport and the target backport version.
+    - Create a new local branch from the target version.
+    - 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`.
+    - Resolve any conflicts. This step may require some manual intervention.
+    - Test the changes thoroughly.
+    - Push the new branch to the appropriate remote repository.
+    - Submit a new pull request to the target version for the backported changes.
+
+    ```
+       Example: backport a pull request with hash 123 in main to 1.3
+
+       1. Fetch the latest changes from upstream or whatever you name the remote upstream repo:
+       git pull upstream
+
+       2. Create a new local branch from the target version:
+       git checkout -b backport-cve upstream/1.3
+
+       3. Cherry pick the changes:
+       git cherry-pick 123
+
+       4. Resolve any conflicts.
+
+       5. Push to your origin forked repo:
+       git push -u origin backport-cve
+
+       6. Submit a new pull request to 1.3.
+
+    ```
+
+    It's worth noting that backporting a pull request can be a complex process, and there may require additional steps depending on the changes involved and target branch. It's important to carefully review and test the changes to ensure they are applied correctly.
+
+
+