From acea2d591bdcedc996fa34feba6fde78ab41c755 Mon Sep 17 00:00:00 2001 From: Ekhorn Date: Wed, 9 Sep 2026 09:29:35 +0200 Subject: [PATCH 1/4] Update vulnerability management and coordinated disclosure --- ...y-management-and-coordinated-disclosure.md | 38 ++++++++++++------- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/docs/vulnerability-management-and-coordinated-disclosure.md b/docs/vulnerability-management-and-coordinated-disclosure.md index f49748f..db5e962 100644 --- a/docs/vulnerability-management-and-coordinated-disclosure.md +++ b/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. \ No newline at end of file +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. From e41e93e4f390c1e3e0d0e0d6dee7f2bb67bcd6d1 Mon Sep 17 00:00:00 2001 From: Ekhorn Date: Mon, 14 Sep 2026 16:45:36 +0200 Subject: [PATCH 2/4] Use \ to put sentences on the next line --- docs/vulnerability-management-and-coordinated-disclosure.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/vulnerability-management-and-coordinated-disclosure.md b/docs/vulnerability-management-and-coordinated-disclosure.md index db5e962..19cf93b 100644 --- a/docs/vulnerability-management-and-coordinated-disclosure.md +++ b/docs/vulnerability-management-and-coordinated-disclosure.md @@ -32,8 +32,8 @@ 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. 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. From 0034c5660d82d146eaa435a5c12e323b9a836763 Mon Sep 17 00:00:00 2001 From: Ekhorn Date: Tue, 15 Sep 2026 09:48:12 +0200 Subject: [PATCH 3/4] Clearify CVSS vector re-evaluation and score misrepresentation --- docs/vulnerability-management-and-coordinated-disclosure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/vulnerability-management-and-coordinated-disclosure.md b/docs/vulnerability-management-and-coordinated-disclosure.md index 19cf93b..df8fb47 100644 --- a/docs/vulnerability-management-and-coordinated-disclosure.md +++ b/docs/vulnerability-management-and-coordinated-disclosure.md @@ -38,7 +38,7 @@ They decide to accept or reject them. If accepted, a CVE is requested from GitHu 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. +Severity is scored with CVSS from a vector such as `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`, which gives a score of 9.3 (Critical). A vector supplied in a report is re-evaluated by the team and corrected where it is wrong. If the vector is accurate but the score misrepresents the real-world risk, explain why in a separate severity assessment on the advisory rather than changing the score. ### Developing the fix From 9eeef0b795356484b30d85a82065ba5e4a834b09 Mon Sep 17 00:00:00 2001 From: Ekhorn Date: Tue, 15 Sep 2026 09:56:03 +0200 Subject: [PATCH 4/4] Clearify bypassing branch protections --- docs/vulnerability-management-and-coordinated-disclosure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/vulnerability-management-and-coordinated-disclosure.md b/docs/vulnerability-management-and-coordinated-disclosure.md index df8fb47..0eb0332 100644 --- a/docs/vulnerability-management-and-coordinated-disclosure.md +++ b/docs/vulnerability-management-and-coordinated-disclosure.md @@ -55,7 +55,7 @@ Because the fork runs no CI, the pipeline checks have to pass locally before the ### 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. +Merge with **Merge and bypass branch protections** on the advisory page. The fork runs no status checks, so the checks required on the default branch never report, and the advisory page states that the changes can only be merged by bypassing branch protections. ### Publishing