oh-distributed-security-design-review

Code Review Skill for OpenHarmony Distributed System Security

Overview

This skill provides professional guidance for security code review of OpenHarmony distributed business, including 18 security design rules and corresponding review points. When reviewing the security of distributed system code, use these rules to strengthen the review on top of general network security rules.

Trigger Phrases

• "review code security implementation"
• "code security review"
• "secure code review"
• "check the security of this code"
• "review distributed code security"
• "OpenHarmony security review"

Code Review Workflow

Step 1: Understand the Code Context

First understand the code's business scenario and the module it resides in:

1. Identify key modules: Determine whether the code involves the following modules

   • Distributed device management
   • Distributed soft bus
   • Other modules that require distributed capabilities

2. Identify business types: Determine whether the following security-sensitive businesses are involved

   • Authentication and authorization between devices
   • Transmission of user sensitive data
   • Cross-device state machine management
   • Trusted relationship management
   • Hardware resource access

3. Determine the role: Identify whether the code is on the subject side (client) or the object side (server)

Step 2: Load Security Rules

According to the business type involved in the code, loadsecurity_rules.mdthe corresponding rules in:

Quick index keywords:

• Cross-device transmission → Rules 3, 8, 15, 17
• State machine → Rule 2
• Authorization/authentication → Rules 1, 5, 6, 8, 12
• PIN code/key → Rules 3, 8, 9, 10
• Resource request → Rule 4
• Permission configuration → Rules 7, 13
• Switch flag → Rule 14
• User switching → Rule 16
• Compatibility code → Rule 18

Step 3: Review Against Security Rules

For each applicable security rule, perform the following review:

1. Locate relevant code: Use Grep to search for key patterns

   Grep patterns examples:
   - "auth", "authorize", "permission" for authorization checks
   - "PIN", "secret", "key" for sensitive data
   - "state", "status" for state machine
   - "random", "generate" for secret generation
   

2. Check implementation details:

   • Check item by item against the Check points in the rules
   • Look for potential violation patterns
   • Identify missing security measures

3. Record findings:

   • Mark the location of violating code (file:line)
   • Explain the specific rule violated
   • Provide remediation suggestions

Step 4: Apply General Security Best Practices

In addition to OpenHarmony-specific rules, also check general security practices:

1. Input validation: Whether all external inputs have been validated
2. Error handling: Whether sensitive operations have appropriate error handling
3. Log security: Whether sensitive information has been logged
4. Resource management: Whether there is a risk of resource leakage

Step 5: Generate Review Report

Generate a structured security review report, including:

1. Executive summary: The number and severity levels of serious security issues found
2. Violation List: Violation items sorted by severity
3. Rule Mapping: The security rule corresponding to each issue
4. Fix Suggestions: Specific code modification suggestions

Common Violation Patterns

Pattern 1: Client-controlled Authorization (violates Rule 1)

Bad Example:

// 客体侧直接使用主体侧传入的标志控制弹框
void handleAuthRequest(bool showPopup) {
    if (!showPopup) {
        // 直接跳过授权弹框
        grantAccess();
    }
}

Correct Approach:

// 客体侧独立决策是否需要授权
void handleAuthRequest() {
    if (isSystemBusinessAndRegistered()) {
        // 已注册的免授权业务
        grantAccess();
    } else {
        // 默认必须弹框
        showAuthorizationDialog();
    }
}

Pattern 2: Plaintext Sensitive Data (violates Rule 3)

Bad Example:

// 明文传输PIN码
message.pin_code = userPin;
sendToRemote(message);

Correct Approach:

// 加密后传输
encryptedPin = encryptPin(userPin, sessionKey);
message.encrypted_pin = encryptedPin;
sendToRemote(message);

Pattern 3: Custom Trust Verification (violates Rule 8)

Bad Example:

// 自行比对账号信息判断可信关系
bool isTrusted() {
    return localAccount == remoteAccount;
}

Correct Approach:

// 依赖HiChain查询
bool isTrusted() {
    CredentialType type = HiChain.queryCredentialType(remoteDevice);
    return type == CredentialType.SAME_ACCOUNT;
}

Pattern 4: Insecure Switch Defaults (violates Rule 14)

Bad Example:

// 默认值放通
bool enableSecurityCheck = true;  // 默认启用

Correct Approach:

// 默认值禁用
bool enableSecurityCheck = false;  // 默认禁用，需显式启用

Security Rule Categories

1. Authorization & Authentication

• Rule 1: Object-side Authorization Control
• Rule 5: Anti-Brute Force Protection
• Rule 6: Server-side Security Logic
• Rule 12: Sensitive Data Authorization and Audit

2. Data Protection

• Rule 3: No Plaintext Sensitive Data Transmission
• Rule 10: Secure Random Secrets
• Rule 17: Business-level Key Isolation

3. Trust Management

• Rule 7: Trusted Relationship Lifecycle Minimization
• Rule 8: Trusted Relationship Verification
• Rule 9: Trusted Relationship Persistence Timing
• Rule 15: Device Legitimacy Verification
• Rule 16: User Isolation for Distributed Trust

4. State Machine & Process Control

• Rule 2: State Machine Context Validation

5. Resource Management

• Rule 4: Resource Access Parameter Validation
• Rule 11: Resource Cleanup
• Rule 13: Minimal Permission Configuration

6. Code Quality

• Rule 14: Secure Switch Default Values
• Rule 18: Legacy Protocol Cleanup

Example Review Session

User request: "Review the security of this distributed device management code"

Review process:

1. Load security rules → Read security_rules.md
2. Identify relevant rules → Rules 1, 2, 7, 8, 9, 11 (device management related)
3. Search code patterns → Grep for authorization, trust, state machine
4. Check each rule:
   • ✓ Rule 1: Whether the authorization process is independently controlled on the object side
   • ✗ Rule 2: The discovery state machine does not validate context
   • ✓ Rule 7: Trust relationship lifecycle management is correct
   • ✗ Rule 8: Custom trust determination logic discovered
5. Generate report → List violations and fix suggestions

Tips

1. Start with keywords: Use keywords in security_rules.md to quickly locate suspicious code
2. Check both sides: Distributed business requires checking both subject-side and object-side code
3. Verify complete flows: Trace the complete business process, do not inspect only a single function
4. Consider edge cases: Check boundary scenarios such as error handling, timeouts, and retries
5. Review logging: Ensure sensitive information is not leaked in logs

Resources

• Detailed Rules: See security_rules.md for complete rule descriptions and check points
• Quick Reference: Use keyword mapping at the end of security_rules.md for fast rule lookup