Update vulnerability management and coordinated disclosure

Author: Ekhorn

docs/vulnerability-management-and-coordinated-disclosure.md

@@ -32,23 +32,33 @@ When security issues affecting OpenRemote software are confirmed, a security adv
 
 Security advisories are reviewed and approved internally before publication and are archived for reference.
 
-People can submit potential vulnerabilities at [Security Advisories](https://github.com/openremote/openremote/security/advisories).  
-Submitted advisories are reviewed by the quality officer or its backups in a timely manner.  
+People can submit potential vulnerabilities at [Security Advisories](https://github.com/openremote/openremote/security/advisories).
+Submitted advisories are reviewed by the quality officer or its backups in a timely manner.
 They decide to accept or reject them. If accepted, a CVE is requested from GitHub.
 
-Once accepted, a fix can be developed in a private fork, created from the advisory page.  
+An advisory covers a single vulnerability. A report describing several independently fixable vulnerabilities is split into one advisory per vulnerability, each with its own CVE. Separate reports of the same vulnerability are merged into one, and everyone who found it is credited. Reporters are told the outcome either way. This follows CVE CNA rules [4.1 vulnerability determination](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-1_Vulnerability_Determination) and [4.2 CVE ID assignment](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-2_CVE_ID_Assignment), which GitHub applies when issuing a CVE.
+
+Severity is scored with CVSS. A score supplied in a report is re-evaluated by the team, and the vector is recorded alongside it so the score can be rechecked.
+
+### Developing the fix
+
+Once accepted, a fix can be developed in a private fork, created from the advisory page.
 This is a private repository with limited access and limited functionality. It does not support LFS and does not run any CI/CD actions.
 
-As it does not support LFS, when cloning, use `GIT_LFS_SKIP_SMUDGE=1 git clone https://…` to avoid any problem.  
-If you’re using git worktree, working with a private fork requires you to use a separate remote, this can become quite confusing; working on a fork in a completely separate clone is often easier and less error-prone.  
-Although work on the fork can still be performed in a branch, it does not bring much value.  
-Once a PR is created, it will not appear in the normal PR list, it must be accessed via the advisory page.  
-Similarly, it must be merged from the advisory page and by a person from the “Product Owners” group.
+As it does not support LFS, when cloning, use `GIT_LFS_SKIP_SMUDGE=1 git clone https://…` to avoid any problem.
+If you’re using git worktree, working with a private fork requires you to use a separate remote, this can become quite confusing; working on a fork in a completely separate clone is often easier and less error-prone.
+Although work on the fork can still be performed in a branch, it does not bring much value.
+Once a PR is created, it will not appear in the normal PR list, it must be accessed via the advisory page.
+Similarly, it must be merged from the advisory page and by a person from the “openremote/security-managers” team.
+
+Because the fork runs no CI, the pipeline checks have to pass locally before the fix is proposed for merge.
+
+### Merging
+
+Branch protection does not need to be touched for this merge. GitHub does not run status checks on pull requests in a temporary private fork, and does not enforce the protection rules set on the branch being merged into.
+
+### Publishing
 
-For the merge feature to become available, those persons must be able to bypass the branch policies.  
-This means that “Product Owners” have been added as able to bypass any defined rulesets (as of this writing, there’s only one, “Copilot review for default branch”).    
-In addition, for the merge to succeed, the check that a valid CI/CD has run must be bypassed.  
-This is done by temporarily unchecking the "Do not allow bypassing the above settings" option in the branch protection rules configuration.  
-Don’t forget to re-enable it once the merge has been done.
+An advisory whose fix is planned is published once a release containing that fix is publicly available.
 
-Once a release including the fix has been made publicly available, publish the advisory.
+A confirmed vulnerability that will not be fixed is still published. Having no fix planned is not a reason to withhold the advisory: publish it stating that no fix is planned, and document the mitigations available to users.