OpenCloudOS Security Vulnerability Disclosure Policy
1. Overview
The OpenCloudOS Community treats the security of the distribution and its components as a primary responsibility. The community practises Coordinated Vulnerability Disclosure (CVD): we do not disclose vulnerability details before a fix is available, and once a fix is released we publish information promptly, completely, and in a verifiable form.
This policy describes how to report a vulnerability to the community, what response the community commits to, how vulnerabilities are rated and remediated, and how security advisories are published. It is intended for security researchers, downstream vendors, users, and upstream communities.
This policy does not cover the community's internal incident response procedures for events such as attacks against community infrastructure (website, build systems, code hosting) or source code tampering.
2. Scope
This policy applies to:
- All OpenCloudOS releases within their maintenance lifecycle, including their kernels;
- All packages distributed through the community repositories;
- Components, patches, and build configurations developed or maintained by the community.
This policy does not apply to:
- Releases that have reached end of life (EOL) — the community no longer provides security fixes for them; please upgrade to a release within its maintenance lifecycle;
- Derivative distributions or commercial products built on top of OpenCloudOS by third parties — please contact the respective provider;
- Issues in upstream projects unrelated to OpenCloudOS — please report these to the upstream project directly; the community can help forward the report.
For the releases currently within their maintenance lifecycle and the lifecycle policy, see "Release Lifecycle".
3. Reporting a Vulnerability
3.1 Reporting channels
| Type of report | Channel |
|---|---|
| Undisclosed vulnerability (0-day, no CVE ID yet) | Email security@opencloudos.tech; PGP encryption is recommended |
| Publicly known vulnerability (a CVE ID exists; you want to confirm whether OpenCloudOS is affected) | Email security@opencloudos.tech; no encryption required |
Please do not describe details of an undisclosed vulnerability in public issues, mailing lists, social media, or commit messages.
PGP public key: https://keys.openpgp.org/vks/v1/by-fingerprint/7A556C4804B196CD87F1FB9CE6BCD4FE7B7BAC04
The community also publishes a security.txt file in accordance with RFC 9116.
3.2 What to include in a report
To help the community validate and assess the issue quickly, please include the following where possible:
- Affected scope: component or package name, version, OpenCloudOS release, and hardware architecture;
- Description: vulnerability type, root cause, and trigger conditions;
- Impact: what an attacker gains (e.g. remote code execution, privilege escalation, information disclosure, denial of service), and the preconditions required (whether authentication, local access, or a non-default configuration is needed);
- Reproduction: environment setup, steps to reproduce, and a proof of concept if available;
- Suggested fix: a proposed patch or mitigation, if you have one;
- Disclosure status: whether the issue is already public elsewhere, whether it has been reported to the upstream project or other distributions, and whether a CVE ID has been assigned;
- Disclosure plan: your preferred public date, and whether you plan to publish an article or present the research at a conference;
- Credit preference: how you wish to be credited in the advisory, or whether you request anonymity.
Reports that consist only of raw output from automated scanning tools, without supporting analysis or reproducible evidence, may not be accepted.
3.3 Anonymous reports
Anonymous reports are accepted. However, an anonymous report does not allow follow-up technical questions, which limits how thoroughly it can be handled, and it also makes it impossible to agree on a coordinated disclosure date.
4. The Community's Response Commitments
| Stage | Target | Notes |
|---|---|---|
| Acknowledgement | Within 2 business days | A human response, not an automated reply |
| Initial assessment | Within 10 business days | One of three outcomes: confirmation of the vulnerability together with a severity rating; an explanation of why it does not constitute a vulnerability; or an explanation that further analysis time is needed, with a committed date for the next update |
| Status updates | Every 14 days | Provided periodically until the issue is closed |
| Closure notice | After the fix is published | The reporter is informed of the advisory ID and the publication date (except for anonymous reports) |
Every report is tracked by a designated member of the Security SIG, who is responsible for driving assessment, remediation, and disclosure through to completion.
5. Expectations of Reporters and Safe Harbour
5.1 Expectations
- Limit validation to what is necessary to demonstrate that the vulnerability exists, without widening its impact;
- Do not access, modify, or delete data belonging to others, and do not disrupt service availability;
- Do not use the vulnerability to obtain privileges or data beyond the purpose of validation;
- Do not provide directly usable exploit tooling to third parties;
- Do not disclose vulnerability details to third parties before the agreed public date.
5.2 Safe harbour
For good-faith research conducted in compliance with this policy, the community commits that:
- It will not require the reporter to sign a non-disclosure agreement (NDA);
- It will not pursue legal action against the reporter for that research, nor ask a third party to do so;
- It will not disclose the reporter's personal information to third parties, except where required by law or necessary for public disclosure.
These commitments do not apply where there is evidence of malicious intent, of profiting from the vulnerability, or of actual harm caused.
5.3 Vulnerability rewards
The community does not operate a bug bounty programme and does not offer monetary or material rewards. The community recognises reporters through credit in security advisories and on the acknowledgements page.
6. Vulnerability Assessment
6.1 Scoring
The community supports both the CVSS v3.1 and CVSS v4.0 scoring standards. Scores reflect the actual impact of the vulnerability within OpenCloudOS, rather than its generic theoretical impact.
Assessment principles:
- Scores are based on realistically reachable attack scenarios, not on an assumed worst case;
- Where multiple attack scenarios exist, the one with the greatest impact prevails;
- Vulnerabilities in libraries or dependencies are scored according to how the component is actually used in OpenCloudOS;
- Where the OpenCloudOS default configuration, compiler options, or hardening mechanisms (such as SELinux policy, modules not loaded by default, FORTIFY, or PIE) block or weaken exploitation, the score or rating is lowered accordingly and the rationale is stated in the advisory.
As a result, OpenCloudOS scores may differ from those published by NVD or by the upstream CNA. Where OpenCloudOS is concerned, we recommend giving precedence to the score published by the community. The Security Center pages display the NVD score, the upstream CNA score, and the OpenCloudOS score side by side for comparison.
6.2 Severity ratings
In addition to the CVSS score, the community assigns an EARS (Exploitability and Attack Risk Severity) rating across five levels, used to determine remediation priority:
| Rating | Definition |
|---|---|
| Critical | Vulnerabilities of this kind are extremely damaging. They typically allow an unauthenticated remote attacker to exploit the system easily under its default configuration and without user interaction, leading to complete system compromise (for example, obtaining remote root privileges), remote data theft, or large-scale data loss. Such vulnerabilities are commonly known to be actively exploited in the wild, or are highly likely to be used to launch large-scale attacks. Recommended action: update to the latest version immediately to block potential large-scale attacks. |
| Important | Vulnerabilities of this kind can cause significant security impact and are easy to exploit under certain environment configurations, potentially leading to severe remote denial of service (DoS), local privilege escalation, or local data theft or loss. Similar vulnerabilities have been exploited in the past, so the likelihood of exploitation is relatively high and there is a risk of targeted attacks. Recommended action: schedule an upgrade as soon as possible to prevent targeted exploitation. |
| Moderate | Vulnerabilities of this kind can still cause significant impact, but are usually subject to more constraints — for example, they depend on a specific configuration, user privileges, or user interaction in order to be exploited. Their impact may include denial of service against a network service, cross-site scripting, or obtaining ordinary user privileges. Because they require more specialised knowledge or complex exploitation conditions, and there is no recent trend of active exploitation in the wild, the likelihood of exploitation is relatively low. Recommended action: schedule a fix in a subsequent regular update cycle. |
| Low | Vulnerabilities of this kind have limited security impact and cause little actual harm. Exploitation usually requires a very complex configuration, high existing privileges, and user cooperation, making successful exploitation extremely difficult. Recommended action: urgent handling is generally unnecessary; the issue can be resolved as part of a later cumulative update containing multiple fixes. |
| Negligible | Issues of this kind present a security risk only in theory. In real-world environments they are almost incapable of causing harm, or they arise only under highly unusual and rare configurations. Exploit code for them is almost impossible to use in a real attack, and no active exploitation has been observed historically. Recommended action: no specific attention or update is generally required; normal operation of the system is unaffected. |
A severity rating reflects the community's technical judgement of how serious a vulnerability is. The rating does not change merely because public exploit code appears; it is re-evaluated only when new technical details emerge.
Where an advisory covers multiple vulnerabilities, the overall rating of the advisory is the highest of the individual ratings.
6.3 Remediation targets
Measured from the date a vulnerability is confirmed, the community's remediation targets for releases within their maintenance lifecycle are:
| Rating | Target |
|---|---|
| Critical | Within 7 calendar days |
| Important | Within 30 calendar days |
| Moderate | Within 90 calendar days |
| Low | A fix is not guaranteed; released as part of a subsequent regular update |
| Negligible | A fix is not guaranteed; released as part of a subsequent regular update |
Major vulnerabilities that are being exploited in the wild, or that are listed in authoritative catalogues such as the CISA Known Exploited Vulnerabilities (KEV) catalogue, are not bound by the targets above; they are handled at the highest priority, and where necessary a mitigation is published before a patch.
For issues that genuinely cannot be fixed (for example, the upstream project is no longer maintained, or a fix would break compatibility), the community states the reason in the advisory and provides a mitigation.
7. Coordinated Disclosure and Embargoes
7.1 Embargoes
Where a fix is not yet ready, the community agrees a common public date with the reporter and other relevant parties. Until that date, vulnerability information is shared only on a need-to-know basis and is handled as TLP:RED.
- The community prefers shorter embargo periods and normally proposes 14 to 30 days;
- Validated vulnerabilities are disclosed within 90 days at the latest; where there is valid justification (for example, a complex fix or the need for multi-party coordination), this may be extended once, by at most a further 90 days;
- The community respects disclosure dates already set by the reporter or the upstream community and adheres to those agreements.
7.2 Lapse of an embargo
In any of the following cases, the community considers the vulnerability public and will immediately publish the information it holds, regardless of whether a fix is complete:
- Any party has disclosed the vulnerability information ahead of the agreed date;
- A commit in a public repository explicitly addresses the security issue;
- The details have been discussed through public channels or independently disclosed by a third party.
7.3 Upstream and downstream coordination
- Where the vulnerability lies in an upstream project, the community — with the reporter's agreement — helps forward the issue upstream and aligns with the upstream disclosure date;
- Where the vulnerability lies in a component owned by OpenCloudOS and affects downstream derivative distributions, the community notifies downstream vendors before public disclosure;
- For complex coordination involving multiple parties, the community may work through platforms such as CERT/CC's VINCE.
7.4 Publication by the reporter
If the reporter plans to publish their own research (an article, conference talk, or proof of concept), please coordinate the timing with the community and observe the same agreed disclosure date. The community does not restrict reporters from publishing their research.
8. CVE Identifiers
- Where the vulnerability lies in an upstream project that already has a corresponding CNA (for example, Linux kernel vulnerabilities are handled by the kernel.org CNA), the CVE ID is assigned by that CNA and the community helps move the process forward;
- Where the vulnerability lies in a component owned by the community and is not within the scope of another CNA, the community is responsible for requesting a CVE ID for it;
- The community references all relevant CVE IDs in full in its security advisories, and maintains in the Security Center the mapping between CVE IDs, affected packages, fixed versions, and advisory IDs.
9. Security Advisories
9.1 Published content
Once a fix is released, the community publishes an OpenCloudOS Security Advisory (OCSA), identified in the format OCSA-YYYY:NNNN. Each advisory includes:
- A description of the vulnerability and its impact;
- The corresponding CVE IDs;
- The CVSS score and severity rating;
- Affected releases, packages, and architectures;
- Fixed versions and how to upgrade;
- Mitigations, where applicable;
- Credit to the reporter (with their consent).
9.2 Where to obtain advisories
| Channel | Location |
|---|---|
| Security advisories page | https://security.opencloudos.tech/advisories |
| Vulnerability database page | https://security.opencloudos.tech/cves |
| Machine-readable data (CSAF and others) | See: https://docs.opencloudos.org/en/security/security_data_api/ |
The community does not provide an advance notification service for advisories. All advisories are publicly accessible and require no login or commercial subscription.
10. Acknowledgements
The community credits vulnerability reporters in security advisories and on the acknowledgements page. Reporters may choose:
- To be credited by real name, handle, or affiliated organisation;
- Not to be credited (anonymous).
By default the community credits the reporter; if you prefer to remain anonymous, please state this in your report.
11. Policy Maintenance
- This policy is maintained by the OpenCloudOS Security SIG;
- Changes to the policy are announced on the community mailing list, with the version and effective date recorded on this page;
- Comments and suggestions on this policy may be sent to security@opencloudos.tech.