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

[ananzh]

Issues Resolved

#3494

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[AMoo-Miki]

Suggested change

	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 aws-security@amazon.com. Please do **not** create a public GitHub issue.
	If you discover a potential security issue in this project, we ask that you notify AWS/Amazon Security via the [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly, via email, to aws-security@amazon.com. Please do **not** create a public GitHub issue.

[ananzh]

I think this paragraph is using a standard template for all repos. For example, here is the SECURITY.md from OpenSearch: https://github.com/opensearch-project/OpenSearch/blob/main/SECURITY.md. Let's just use it as it is.

[AMoo-Miki]

I am not sure where they got that but the grammar errors are bad.

[davidlago]

Except for the missing comma after the first subordinate clause, the other suggestions are less black and white... and I wouldn't classify any of them as "bad grammar", but I'm not a native speaker so what do I know :)

@AMoo-Miki: If you feel strongly about the way the paragraph is stated, I'd recommend opening up a PR against the one @ananzh links above, so that we can all benefit from this feedback.

[AMoo-Miki]

Suggested change

- 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:

- To backport a pull request for a CVE fix to previous versions of OpenSearch Dashboards, add the desired backport labels (ex: `backport 1.x`) to the PR. When the PR is merged, a workflow will attempt to backport the PR. If this backporting attempt fail, the PR will be updated with comments about the failure; follow the instructions in those comments to manually backport your changes which you can then use in a new PR.

[AMoo-Miki]

Suggested change

	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.
	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.

[kavilla]

Do we need to get this reviewed as an org perspective? I know other SECURITY.md is identical and was provided as a template.

[ananzh]

I am curious when we initially modify this file here ... did we get this reviewed as an org perspective? Seems in the previous comments there is no reviewed?

[ananzh]

@kavilla I have discussed this with team and the point brought by @AMoo-Miki is that this is not related to repo security standard, this doc is more like a reference for any contributors who want to contribute. So I think the question is now that is this the right place to add these instruction references?

I know that we started to modify the file in this PR #2674. But is SECURITY.md the correct place to add these steps?

[ananzh]

@kavilla I think we could move on to approve the file. I already add @davidlago in the reviewer. Since we own the repo, we should be able to modify this file. If there is any organization concerns, we could restore the standard file later.

[joshuarrrr]

Thanks @ananzh, this is a definite improvement. I have a few minor suggestions about how we could make it better, but most of them could be added in a follow-up PR. The one change I would like to see before approving is a running yarn osd bootstrap as part of the process of doing a manual dependency backport.

[joshuarrrr]

Suggested change

extra lines

[ananzh]

will remove

[joshuarrrr]

Let's add a header to separate Reporting from Fixing

Suggested change

	## Fixing a Vulnerability

[joshuarrrr]

We can clarify what counts as a direct dependency:

Suggested change

	- For direct dependencies - 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.
	- 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.

that is both compatible with OpenSearch Dashboards

Do we want to clarify more guidance on how to pick a version? For changes to main, major version upgrades are welcome, but may require migrations of deprecated methods and APIs. Otherwise, you can look for the latest version that works out of the box.

[ananzh]

Let me think about it. Maybe not in this PR. Because it could be complex, major version upgrades could also be not in main.

[joshuarrrr]

If the package range is suitable

Add instructions on how to determine?

[ananzh]

will add instructions.

[joshuarrrr]

Suggested change

- To backport a pull request for a CVE fix to previous versions of OpenSearch Dashboards, add the desired backport labels (ex: `backport 1.x`) to the PR. When the PR is merged, a workflow will attempt to backport the PR. If this backporting attempt fail, the PR will be updated with comments about the failure; follow the instructions in those comments to manually backport your changes which you can then use in a new PR. Here are some steps for reference.

- To backport a pull request for a CVE fix to previous versions of OpenSearch Dashboards, add the desired backport labels (ex: `backport 1.x`) to the PR. When the PR is merged, a workflow will attempt to backport the PR. If this backporting attempt fails, the PR will be updated with a comment about the failure. Follow the instructions provided to manually backport your changes in a new PR. Here are some steps for reference:

We also probably need some links to our maintainer/backporting processes more generally. And to note that some CVEs will require manual resolution on each branch - maybe a major version bump on main, a smaller version bump on 2.x, and a resolution on 1.x, for example.

[ananzh]

will fix

[joshuarrrr]

Nit - for steps in a sequence, ordered/numbered list is better.

[ananzh]

will change

[joshuarrrr]

This is missing an explicit step to run yarn osd bootstrap. Because yarn.lock is intended to always be a generated file, this helps catch bad merges or conflict resolutions.

[ananzh]

will add