We actively support and provide security updates for the following versions:

All encryption operations in Communitas use approved cryptographic libraries and are enforced through:

• Automated CI checks scanning for insecure cryptographic practices
• Code review requirements for security-critical modules
• Runtime validation of encryption implementations
• Post-quantum cryptography (ML-DSA signatures, ML-KEM key exchange)

1. NO unwrap() or expect() in production code - All error conditions must be handled gracefully
2. NO panic!() in production code - Use Result types and proper error propagation
3. USE approved cryptography - ChaCha20-Poly1305 AEAD, ML-DSA/ML-KEM for PQC
4. NO hardcoded secrets - All credentials must be externally configured
5. Memory safety - Rust's ownership system prevents many vulnerabilities, but we use additional tools like zeroize for sensitive data

Our CI pipeline includes:

• Security vulnerability scanning with cargo audit
• Dependency license checking with cargo deny
• Static code analysis for security anti-patterns
• Hardcoded secrets detection
• Encryption compliance validation

If you discover a security vulnerability, please:

1. DO NOT open a public GitHub issue
2. DO NOT discuss the vulnerability publicly
3. Email security concerns to: [email protected]

Include in your report:

• Description of the vulnerability
• Steps to reproduce (if applicable)
• Potential impact assessment
• Suggested fix (if you have one)

• Initial response: Within 24 hours
• Vulnerability assessment: Within 72 hours
• Fix timeline: Depends on severity
  • Critical: Within 7 days
  • High: Within 14 days
  • Medium: Within 30 days
  • Low: Next planned release

Critical: Remote code execution, privilege escalation, cryptographic bypass

• Immediate patching required
• Public disclosure after fix is deployed

High: Data exposure, authentication bypass, significant DoS

• Fast-track patching within 2 weeks
• Coordinated disclosure

Medium: Limited information disclosure, local privilege escalation

• Regular patching cycle
• Standard disclosure process

Low: Minor information leaks, configuration issues

• Next release cycle
• Public discussion acceptable after fix

Communitas implements defense-in-depth encryption:

1. Transport Layer: QUIC with ant-quic NAT traversal
2. Application Layer: ChaCha20-Poly1305 AEAD encryption
3. Storage Layer: Full-file replication with encrypted storage
4. Identity Layer: Post-quantum signatures (ML-DSA) and key exchange (ML-KEM)

• Key Generation: Cryptographically secure random generation
• Key Storage: Platform-specific secure storage (Keychain, Credential Manager, etc.)
• Key Rotation: Automatic rotation for long-lived keys
• Key Zeroization: Sensitive material cleared from memory

• P2P Security: Gossip-based overlay with cryptographic identities (four-word addresses)
• Peer Discovery: IPv4/IPv6 peer cache with offline bootstrap
• NAT Traversal: QUIC protocol for direct peer connections
• Message Authentication: Digital signatures (ML-DSA) on all messages

• Rust Ownership: Compile-time memory safety guarantees
• Zeroization: Sensitive data automatically cleared
• Constant-time Operations: Timing attack resistance
• Stack Protection: Compiler-level stack overflow protection

Our CI pipeline runs:

• Unit tests for all cryptographic operations
• Integration tests for P2P security
• Property-based testing with QuickCheck
• Fuzzing for input validation
• Static analysis with Clippy security lints

Required for:

• All cryptographic code changes
• Network protocol modifications
• Identity system updates
• Storage layer changes
• CI/CD pipeline modifications

We perform regular security audits of:

• Cryptographic implementations
• P2P network protocols
• Key management systems
• Attack surface analysis

• Vulnerability Scanning: Weekly automated scans
• License Compliance: Approved license list enforcement
• Supply Chain Security: Hash verification of dependencies
• Minimal Dependencies: Reduce attack surface

Only these cryptographic libraries are approved:

• ChaCha20-Poly1305: AEAD encryption for application layer (via chacha20poly1305 crate)
• ML-DSA (Dilithium): Post-quantum digital signatures
• ML-KEM (Kyber): Post-quantum key encapsulation
• Blake3: Cryptographic hashing and content addressing
• rand: Secure random number generation
• zeroize: Secure memory clearing for sensitive data

❌ Direct use of:

• OpenSSL (prefer Rust-native alternatives)
• Custom cryptographic implementations
• Deprecated cryptographic algorithms
• Weak random number generators

1. Detection: Automated monitoring and manual reporting
2. Assessment: Severity classification and impact analysis
3. Containment: Immediate measures to limit damage
4. Eradication: Remove the vulnerability from all systems
5. Recovery: Restore normal operations securely
6. Lessons Learned: Post-incident analysis and improvements

• Internal Team: Immediate notification via secure channels
• Users: Coordinated disclosure after fix deployment
• Community: Security advisory with mitigation steps
• Authorities: As required by applicable regulations

We align with:

• OWASP Top 10: Web application security risks
• NIST Cybersecurity Framework: Risk management approach
• ISO 27001: Information security management
• GDPR: Data protection and privacy

All security-relevant events are logged:

• Authentication attempts
• Cryptographic operations
• Network connections
• Data access patterns
• Configuration changes

For all security-related matters:

Primary Contact: David Irvine

• Email: [email protected]
• GitHub: @dirvine

GPG Key: Available on request for encrypted communications

This security policy is reviewed quarterly and updated as needed to reflect current threats and best practices.

Last Updated: January 2025