Code Review Skill for OpenHarmony Distributed System Security

Overview

Trigger Phrases

• "Review code security implementation"
• "Code security audit"
• "Security code review"
• "Check the security of this code"
• "Review distributed code security"
• "OpenHarmony security review"

Code Review Workflow

Step 1: Understand the Code Context

1. Identify key modules: Determine whether the code involves the following modules
   • Distributed device management
   • Distributed soft bus
   • Other modules requiring distributed capabilities
2. Identify business types: Determine whether it involves the following security-sensitive businesses
   • Inter-device authentication and authorization
   • User sensitive data transmission
   • Cross-device state machine management
   • Trusted relationship management
   • Hardware resource access
3. Determine roles: Identify whether the code is on the subject side (client) or object side (server)

Step 2: Load Security Rules

• Cross-device transmission → Rules 3, 8, 15, 17
• State machine → Rule 2
• Authorization/authentication → Rules 1, 5, 6, 8, 12
• PIN code/secret key → Rules 3, 8, 9, 10
• Resource application → 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

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)
   • Specify the specific rule violated
   • Provide repair suggestions

Step 4: Apply General Security Best Practices

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

Step 5: Generate Review Report

1. Executive Summary: Number and severity level of critical security issues found
2. Violation List: Violations sorted by severity
3. Rule Mapping: Security rules corresponding to each issue
4. Repair Suggestions: Specific code modification suggestions

Common Violation Patterns

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

// The object side directly uses the flag passed from the subject side to control the pop-up dialog
void handleAuthRequest(bool showPopup) {
    if (!showPopup) {
        // Skip the authorization pop-up directly
        grantAccess();
    }
}

// The object side independently decides whether authorization is required
void handleAuthRequest() {
    if (isSystemBusinessAndRegistered()) {
        // Registered business exempt from authorization
        grantAccess();
    } else {
        // Pop-up is required by default
        showAuthorizationDialog();
    }
}

Pattern 2: Plaintext Sensitive Data (Violates Rule 3)

// Transmit PIN code in plaintext
message.pin_code = userPin;
sendToRemote(message);

// Transmit after encryption
encryptedPin = encryptPin(userPin, sessionKey);
message.encrypted_pin = encryptedPin;
sendToRemote(message);

Pattern 3: Custom Trust Verification (Violates Rule 8)

// Judge trusted relationship by comparing account information directly
bool isTrusted() {
    return localAccount == remoteAccount;
}

// Rely on HiChain query
bool isTrusted() {
    CredentialType type = HiChain.queryCredentialType(remoteDevice);
    return type == CredentialType.SAME_ACCOUNT;
}

Pattern 4: Insecure Switch Defaults (Violates Rule 14)

// Default to allow
bool enableSecurityCheck = true;  // Enabled by default

// Default to disable
bool enableSecurityCheck = false;  // Disabled by default, need explicit enabling

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

1. Load security rules → Read security_rules.md
2. Identify relevant rules → Rules 1, 2, 7, 8, 9, 11 (related to device management)
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: Found that the state machine does not validate the context
   • ✓ Rule 7: Trusted relationship lifecycle management is correct
   • ✗ Rule 8: Found custom trust judgment logic
5. Generate report → List violations and repair suggestions

Tips

1. Start with keywords: Use keywords in security_rules.md to quickly locate suspicious code
2. Check both sides: Distributed services require checking both subject-side and object-side code
3. Verify complete flows: Track the complete business process, do not only check individual functions
4. Consider edge cases: Check edge scenarios such as error handling, timeouts, and retries
5. Review logging: Ensure that 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