With reference to industry standards and best practices, this document provides guidelines for secure tests.
# OpenHarmony Security Test Guide
With reference to industry standards and best practices, this document provides specifications for security tests of the OpenHarmony project.
## Security Test Content
## Secure Coding Test
- Review the code of each module according to [OpenHarmony C&C++ Secure Coding Guide](OpenHarmony-c-cpp-secure-coding-guide.md) and fix all issues found in the review.
1. Review the code of each module, and ensure that the code complies with the [Coding Style](./code-contribution.md#coding-style).
- Use the OpenHarmony gated check-in to scan your code and clear all alarms.
2. Use a dedicated tool to scan the code and ensure all the alarms are cleared. A secure code scanning tool has been integrated in the OpenHarmony gated check-in.
- Use the compilation option scanning tool to scan your binary file and ensure that the settings of all the compilation options comply with the [OpenHarmony Compilation Specifications].
- For the module that receives and processes user-mode parameters, develop gray-box and white-box fuzz testing suites according to the [Fuzz Testing Guide](https://gitee.com/openharmony/test_developertest/tree/master/libs/fuzzlib) and complete the tests.
## Security Design Verification
- Use mainstream vulnerability scanning tools to scan open-source components. Ensure that all the detected vulnerabilities have been fixed according to the vulnerability management process of the community.
Review and verify the security design of each module, and ensure that the security design complies with [OpenHarmony Security Design Specifications](./OpenHarmony-security-design-guide.md).
- Perform consistency check of the released versions, and check that the [released version images](../release-notes/Readme.md) provide the SAH-256 checksum.
- Complete the security design self-check for each module according to [OpenHarmony Security Design Specifications](OpenHarmony-security-design-guide.md). Ensure that all design issues found in the self-check have been fixed.
- Use mainstream viruses scanning software to scan software packages. Ensure that all virus detected have been removed or confirmed as false alarms.
## Security Tests
- Search for ".cer" and ".pem" or keyword such as "PRIVATE KEY" to find the certificate key, and check that the certificate key is within the validity period and the encryption algorithm meets [encryption algorithm requirements](OpenHarmony-security-design-guide.md#3-encryption). Ensure that all certificate key issues have been resolved.
1. For critical modules, develop graybox and whitebox fuzzing test suites based on the [Fuzzing Test Framework](https://gitee.com/openharmony/test_developertest/tree/master/libs/fuzzlib) and complete the tests.
- Perform black-box fuzz testing on exposed user-mode APIs, including system service APIs, kernel driver APIs, socket APIs, and more.
2. Perform blackbox fuzzing tests on exposed user-mode APIs, including system service APIs, kernel driver APIs, socket network APIs, and more.
3. Use a build scanning tool to check the build option settings. The build files must comply with the OpenHarmony Build Specifications.
>**NOTE**
>
>The preceding requirements apply to all new and inherited features.
4. Use the mainstream vulnerability scanning tools to scan open-source components. Ensure that all the detected vulnerabilities have been fixed according to the vulnerability management process of the community.
## Security Test Completion Requirements
The mandatory security test performed before version release is complete only when:
- All the security tests mentioned in [Security Test Content](#security-test-content) are complete.
- All security issues have been closed.
## Security Test Report Template
- The security test report must contain the security test results in [Security Test Content](#security-test-content) and pending security issues.
- The version security test report is released with the entire test report of the version, instead of being released and archived separately.
The Distributed Data Management subsystem can persistently store various structured data of a single device and also supports data synchronization and sharing across devices. With the Distributed Data Management subsystem, application data can be seamlessly processed across different devices, ensuring consistent user experience for the same application across devices.
The Distributed Data Management subsystem can persistently store various structured data of a single device. It also supports data synchronization and sharing across devices. With the Distributed Data Management subsystem, application data can be seamlessly processed across devices, ensuring consistent user experience for the same application across devices.
**Subsystem Architecture**
...
...
@@ -47,15 +47,15 @@ The **DataShare** module allows an application to manage its own data and share
### DDS
The Distributed Data Service (DDS) implements distributed database collaboration across devices for applications. The DDS isolates data based on a triplet of the account, application, and database. The DDS synchronizes data between trusted devices to provide users with consistent data access experience on different devices.
The Distributed Data Service (DDS) implements database collaboration across devices for applications. The DDS isolates data based on a triplet of the account, application, and database. The DDS synchronizes data between trusted devices, delivering a consistent data access experience on different devices.
### Preferences
The **Preferences** module allows quick access to data in KV pairs and storage of a small amount of data for local applications. The data is stored in local files and loaded in memory, which allows faster access and higher processing efficiency. Preferences provide non-relational data storage and are not suitable for storing a large amount of data.
The **Preferences** module allows quick access to data in KV pairs and storage of a small amount of data for local applications. The data is stored in local files in KV pairs and loaded in memory, which allows for faster access and higher processing efficiency. Preferences provide non-relational data storage and are not suitable for storing a large amount of data.
1. The **Preferences** module provides APIs for **preferences** operations.
2. You can use **getPreferences()** to load the content of a specified file to a **Preferences** instance. Each file has only one **Preferences** instance. The system stores the instance data in memory through a static container until the app removes the instance from the memory or deletes the file.
3. After obtaining a **Preferences** instance, the app can call the APIs in**Preferences** to read data from or write data to the **Preferences** instance, and call **flush()** to save the instance data to a file.
2. You can use **getPreferences()** to load the content of a specified file to a **Preferences** instance. Each file has only one **Preferences** instance. The system stores the instance data in memory through a static container until the application removes the instance from the memory or deletes the file.
3. After obtaining a **Preferences** instance, the application can call the APIs of**Preferences** to read data from or write data to the **Preferences** instance, and call **flush()** to save the instance data to a file.
