6. Vulnerability Management and Coordinated Disclosure
6.1 Vulnerability Monitoring
OpenRemote continuously monitors vulnerability information sources relevant to the technologies used within its platform. These sources include security advisories, dependency vulnerability databases, and vendor notifications.
Potential vulnerabilities, as discovered by dependency scanning during builds, are reviewed and evaluated immediately on a daily basis to determine their impact on OpenRemote systems or software components.
6.2 Patch Management Policy
Security patches and updates are applied in a structured manner to address identified vulnerabilities. Critical vulnerabilities are prioritised and addressed as quickly as possible, while lower-risk issues are handled during scheduled development and maintenance cycles.
Patch management activities are coordinated between product development and project operations teams to ensure system stability.
6.3 Coordinated Vulnerability Disclosure
This is work in progress and not fully implemented yet, as OpenRemote, we are working on this subject and will publish an update soon.
OpenRemote supports responsible disclosure of security vulnerabilities by external parties. Individuals or organisations discovering vulnerabilities are encouraged to report them through designated communication channels.
Reported vulnerabilities are assessed and addressed in a coordinated manner before public disclosure.
6.4 Security Advisory Process
When security issues affecting OpenRemote software are confirmed, a security advisory may be issued to inform users about the vulnerability and recommended mitigation actions.
Security advisories are reviewed and approved internally before publication and are archived for reference.
People can submit potential vulnerabilities at Security Advisories.
Submitted advisories are reviewed by the quality officer or their backups in a timely manner.
During triage the report is classified as publishable, duplicate, split, or rejected, and the reporter is told the outcome whichever it is. A CVE is requested from GitHub for each publishable advisory that triage produces.
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. This follows CVE CNA rules 4.1 vulnerability determination and 4.2 CVE ID assignment, which GitHub applies when issuing a CVE.
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
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 “openremote/product-owners” team.
Because the fork runs no CI, the pipeline checks have to pass locally before the fix is proposed for merge.
Merging
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.
The option is shown to anyone who can reach the advisory page, but the merge itself fails unless the person performing it is able to bypass branch protections in the first place, which the “openremote/product-owners” team can and the “openremote/security-managers” team cannot. A security manager who is not also a product owner can tick the box and click merge, but it will fail to merge.
Publishing
An advisory whose fix is planned is published once a release containing that fix is publicly available.
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.