Last Updated: December 5, 2025

Version: 1.0

1. Security Overview
2. Reporting Security Vulnerabilities
3. Security Best Practices
4. API Key Management
5. File Security
6. Network Security
7. Audit Logging
8. Rate Limiting
9. Permissions System
10. Security Updates
11. Compliance
12. FAQ

RiceCoder is designed with security as a core principle. This document outlines the security features, best practices, and policies for using RiceCoder safely.

✅ Secure Credential Storage

• API keys stored in memory by default
• Environment variable support for secure loading
• OS keychain integration (planned)
• Encryption at rest (planned)

✅ Credential Redaction

• Automatic redaction of API keys from logs
• Redaction of sensitive information in error messages
• Support for custom redaction patterns

✅ Safe File Operations

• Atomic writes with temporary files
• Automatic backups before modifications
• Permission preservation
• Directory traversal prevention

✅ Network Security

• HTTPS/TLS by default
• Certificate validation enabled
• No HTTP fallback
• Request signing for API calls

✅ Audit Logging

• Centralized audit log for security events
• Tracking of API key access
• Authentication attempt logging
• Permission decision logging

✅ Rate Limiting

• Token bucket rate limiter
• Exponential backoff for retries
• Per-provider rate limiting
• Configurable limits

✅ Permission System

• Fine-grained tool access control
• Role-based access control
• User prompts for sensitive operations
• Permission configuration support

If you discover a security vulnerability in RiceCoder, please report it responsibly.

1. Do NOT create a public GitHub issue for security vulnerabilities

2. Use GitHub Security Advisories at https://github.com/moabualruz/ricecoder/security/advisories with:

   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if available)

3. Wait for acknowledgment (within 48 hours)

4. Coordinate with the security team on disclosure timeline

5. Receive credit in security advisory (if desired)

• Day 1: Vulnerability reported
• Day 2: Acknowledgment and initial assessment
• Day 7: Fix development begins
• Day 14: Fix completed and tested
• Day 21: Security advisory published
• Day 28: Public disclosure (if applicable)

DO:

• ✅ Store API keys in environment variables
• ✅ Use OS keychain for sensitive environments
• ✅ Rotate API keys regularly (every 90 days)
• ✅ Use separate keys for different environments
• ✅ Monitor API key usage in audit logs

DON'T:

• ❌ Hardcode API keys in configuration files
• ❌ Commit API keys to version control
• ❌ Share API keys via email or chat
• ❌ Use the same key for multiple environments
• ❌ Log API keys in debug output

DO:

• ✅ Use configuration files for non-sensitive settings
• ✅ Restrict file permissions (chmod 600 for config files)
• ✅ Use environment variables for sensitive values
• ✅ Validate configuration on load
• ✅ Review configuration changes

DON'T:

• ❌ Store secrets in configuration files
• ❌ Make configuration files world-readable
• ❌ Use default credentials
• ❌ Skip configuration validation
• ❌ Commit sensitive configuration to version control

DO:

• ✅ Use atomic file operations
• ✅ Create backups before modifications
• ✅ Validate file permissions
• ✅ Use relative paths within project
• ✅ Enable git integration for change tracking

DON'T:

• ❌ Use absolute paths
• ❌ Skip backup creation
• ❌ Modify files without validation
• ❌ Allow directory traversal
• ❌ Ignore file permission errors

DO:

• ✅ Enable audit logging for security events
• ✅ Review audit logs regularly
• ✅ Rotate logs to prevent unbounded growth
• ✅ Archive logs for compliance
• ✅ Redact sensitive information from logs

DON'T:

• ❌ Log API keys or credentials
• ❌ Log sensitive user data
• ❌ Disable audit logging
• ❌ Store logs in world-readable locations
• ❌ Ignore suspicious log entries

DO:

• ✅ Use HTTPS for all remote connections
• ✅ Verify TLS certificates
• ✅ Use secure DNS (DoH/DoT)
• ✅ Monitor network traffic
• ✅ Use VPN for sensitive operations

DON'T:

• ❌ Use HTTP for sensitive data
• ❌ Disable certificate validation
• ❌ Trust self-signed certificates
• ❌ Send credentials over unencrypted channels
• ❌ Use public WiFi for sensitive operations

DO:

• ✅ Use principle of least privilege
• ✅ Grant only necessary permissions
• ✅ Review permissions regularly
• ✅ Revoke unused permissions
• ✅ Audit permission changes

DON'T:

• ❌ Grant excessive permissions
• ❌ Use default permissions
• ❌ Forget to revoke permissions
• ❌ Share credentials across users
• ❌ Ignore permission errors

# Set API key in environment
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Run ricecoder
rice chat

# ~/.ricecoder/config.yaml
providers:
  api_keys:
    openai: "sk-..."
    anthropic: "sk-ant-..."

⚠️ WARNING: Configuration files are stored in plain text. Use environment variables for production.

# Store API key in OS keychain
rice config set-key openai "sk-..."

# Retrieve from keychain automatically
rice chat

# Rotate API key
rice config rotate-key openai

# Verify new key works
rice chat

# List configured providers
rice config list-providers

# Check if API key is available
rice config check-key openai

RiceCoder uses atomic file operations to ensure data safety:

1. Temporary File: Write to temporary file
2. Validation: Validate file contents
3. Backup: Create backup of original
4. Atomic Rename: Rename temporary to target
5. Verification: Verify file integrity

RiceCoder respects file permissions:

• Config files: 0o600 (read/write for owner only)
• Project files: 0o644 (read/write for owner, read for others)
• Directories: 0o755 (read/write/execute for owner, read/execute for others)

RiceCoder prevents directory traversal attacks:

// ✅ SAFE: Paths are validated
let path = path_resolver.resolve("src/main.rs")?;

// ❌ UNSAFE: Would be rejected
let path = path_resolver.resolve("../../../etc/passwd")?;

All network communication uses HTTPS/TLS:

• TLS Version: 1.2 or higher
• Certificate Validation: Enabled
• Cipher Suites: Modern, secure ciphers
• Certificate Pinning: Planned for major providers

API requests are signed with credentials:

Authorization: Bearer <api_key>
X-API-Key: <api_key>

RiceCoder implements rate limiting to prevent abuse:

• Default: 10 requests/second per provider
• Burst: 100 requests maximum
• Backoff: Exponential backoff on rate limit errors

~/.ricecoder/audit.log

Each entry is a JSON object:

{
  "timestamp": "2025-12-05T10:30:00+00:00",
  "event_type": "ApiKeyAccessed",
  "component": "providers",
  "actor": "system",
  "resource": "openai",
  "result": "success",
  "details": "API key accessed"
}

# View recent audit events
tail -f ~/.ricecoder/audit.log

# Search for specific events
grep "ApiKeyAccessed" ~/.ricecoder/audit.log

# Parse JSON logs
cat ~/.ricecoder/audit.log | jq '.event_type'

# ~/.ricecoder/config.yaml
providers:
  rate_limits:
    openai:
      tokens_per_second: 10
      max_tokens: 100
    anthropic:
      tokens_per_second: 5
      max_tokens: 50

RiceCoder uses exponential backoff with jitter:

• Initial Delay: 100ms
• Multiplier: 2.0 (doubles each retry)
• Max Delay: 30 seconds
• Jitter: ±10% to prevent thundering herd

# Check rate limit status
rice config check-rate-limit openai

# View rate limit history
grep "RateLimitExceeded" ~/.ricecoder/audit.log

# ~/.ricecoder/config.yaml
permissions:
  tools:
    read_file:
      level: ask
      description: "Read files from disk"
    write_file:
      level: ask
      description: "Write files to disk"
    execute_command:
      level: deny
      description: "Execute shell commands"

⚠️  Permission Required

Tool: read_file
Resource: /path/to/file.txt
Description: Read files from disk

Allow? [y/n/always/never]

# Check for security updates
rice update check

# Install security updates
rice update install

• Critical: Released immediately
• High: Released within 7 days
• Medium: Released within 30 days
• Low: Released with next version

RiceCoder dependencies are regularly updated:

# Check for vulnerable dependencies
cargo audit

# Update dependencies
cargo update

RiceCoder follows these security standards:

• OWASP Top 10: Addresses all major categories
• CWE Top 25: Addresses common weaknesses
• NIST Cybersecurity Framework: Implements core functions
• Rust Security Guidelines: Follows best practices
• SOC 2 Type II: Customer-managed encryption keys, comprehensive audit logging
• GDPR: Right to erasure, data portability, consent management
• HIPAA: Security safeguards, privacy protections, breach procedures

• ✅ No known vulnerabilities (as of December 5, 2025)
• ✅ Passes cargo audit security scan
• ✅ Follows Rust security guidelines
• ✅ Implements OWASP recommendations
• ✅ SOC 2 Type II compliance infrastructure
• ✅ GDPR/HIPAA data handling capabilities

RiceCoder implements comprehensive data protection:

• ✅ Customer-managed encryption keys (SOC 2)
• ✅ Right to data erasure (GDPR)
• ✅ Data portability (GDPR)
• ✅ Privacy-preserving analytics with opt-in
• ✅ 90-day log retention with automated cleanup
• ✅ Comprehensive audit logging
• ✅ Consent management and tracking
• ✅ No unauthorized data collection

A: Yes. RiceCoder stores API keys in memory by default and never logs them. Use environment variables for additional security.

A: No. RiceCoder generates code but requires explicit user approval before writing files. Generated code is never executed automatically.

A: Check the audit log for suspicious API key access:

grep "ApiKeyAccessed" ~/.ricecoder/audit.log

A: Immediately rotate the key:

rice config rotate-key <provider>

A: No. RiceCoder is restricted to the current project directory and global configuration directory.

A: Use GitHub Security Advisories at https://github.com/moabualruz/ricecoder/security/advisories with details. Do not create public GitHub issues for security vulnerabilities.

A: RiceCoder is currently in Beta (v0.1.4). Production use is not recommended until v1.0.0 is released.

A: Critical security updates are released immediately. Other updates follow the standard release schedule.

A: No. Security features cannot be disabled. This is intentional to protect users.

A: Review the security audit at SECURITY_AUDIT_PHASE4.md and check the source code on GitHub.

For security questions or concerns:

• GitHub Security Advisories: Report Issue
• GitHub Issues: Report Bug
• GitHub Discussions: Ask Questions

• ✅ Initial security policy
• ✅ Comprehensive security audit
• ✅ Rate limiting implementation
• ✅ Audit logging implementation
• ✅ Security headers implementation
• ✅ Vulnerability reporting process

Last Updated: December 5, 2025

Next Review: After Phase 4 implementation

Maintained by: RiceCoder Security Team