OpenHarmony has adopted the security disclosure and response policies described in this document to ensure that we handle security issues in a timely manner.
This team is responsible for responding to and handling security issues in the community, including internal communication and external disclosure. However, the entire process needs to be completed with the assistance of relevant development engineers and release managers.
For details, see README
Track and coordinate each security issue from the time it is reported to the time it is successfully handled.
Ensure that all personnel who should handle the issues have been notified.
Respond to issues that have not been confirmed as security issues.
Assist in confirming the scoring of security issues in OpenHarmony products.
Escalate security issues to the issue distributor if there is any disagreement on handling the issues.
All members of the online security issue response team are responsible for this work and will respond to security issues in the order they are reported.
This role is not a member of the security issue response team and should be taken by the members who want to join the security issue response team. Each SIG team should designate a SIG member to participate in security activities. They will be responsible for:
If a bug in the SIG is confirmed as a security vulnerability, the team member changes the corresponding issue to a private issue, adds a security issue label, and adds a priority label as needed. The security issue distributor will periodically check the updates of such issues. The security issue distributor will periodically check the updates of such issues.
If a security vulnerability is not on the list of public security vulnerabilities that the OpenHarmony security team has handled, you can handle it as follows:
Email notification: Please immediately send an email to firstname.lastname@example.org to notify the security issue response team so that the team can start the patch, release, and announcement processes. After receiving the email, the security issue distributor creates a security issue in the community.
Community issue: You can create an issue in the community where the issue is found and mark the issue as a
security issue. When creating the issue, select the private issue type.
If necessary, the security issue response team will ask whether you can disclose this issue secretly through the person in charge. If you object, we will adopt the public disclosure method.
The vulnerability rewards of the community are being planned and will be available in the future.
The security issue distributor will confirm new issues, including:
Record the confirmation result in the issue progress, and change the issue status to resolving.
The fixing owner sets up a fixing team, which contains:
Version or patch release manager
SIG members of the affected projects, preferentially those who have participated in the issue distribution (defined in the corresponding OWNERS document).
For each vulnerability, the fixing owner coordinates with the fixing team and release manager, and sends emails to relevant community members. The fixing owner develops a fixing plan based on his/her best judgment, severity of the issues, the time required for development, and the version plan provided by the release manager.
The fixing owner and fixing team will use the CVSS calculator o create a CVSS. They will use“severity assessment - how we score the vulnerabilities”to determine the impact and severity of the issues. The fixing owner makes a final evaluation of the risk.
If the evaluation score is lower than 4.0 (low severity) or the evaluation risk is low, the fixing owner can choose semi-public fixing. This means that the PR is conducted directly on the public OpenHarmony repository and can be discussed on public channels. At the same time, the fixing team can slow down the release process under certain circumstances, such as during holidays. These decisions must be discussed at security meetings.
If the evaluation score is higher than 4.0 and lower than 7.0 (medium severity), the fixing owner can also choose semi-public fixing. The fixing owner will determine whether public fixing will harm the users and whether to limit the discussion of the security aspects of the issue to private channels.
Note: The fixing owner has the right to classify vulnerabilities by severity.
As the fix progresses, the fixing owner needs to submit an overall communication plan for the wider community. The overall communication should be started after the fixing team has developed the fixing or mitigation measures so that an achievable plan can be delivered to users.
Fix Release Date （within 1 to 21 days after the issue is confirmed）
The fixing owner provides the new version number, security issue ID (if necessary), severity and impact, and location of binary files to the disclosure owner to support wider distribution and user operations. The disclosure owner places a notice in the community as soon as possible and should include mitigation measures that users can take before upgrading to the fixed version. Notices will be placed on the:
These steps should be completed one to three days after the release date. The review process is aimed at making improvement.