We take the security of EventCore seriously. If you believe you have found a security vulnerability in EventCore, please report it privately by email.

Please do not report security vulnerabilities through public issues.

1. Email john@johnwilger.com with a subject line starting with [eventcore security]
2. Provide a clear description of the vulnerability including:
   • Type of vulnerability (e.g., SQL injection, resource exhaustion)
   • Affected components or modules
   • Steps to reproduce
   • Potential impact
   • Any suggested fixes (if applicable)

• Initial Response: We will acknowledge receipt of your report within 7 days
• Assessment: We will investigate and assess the severity within 30 days
• Resolution: We aim to resolve confirmed vulnerabilities within 30-90 days, depending on complexity
  • Critical vulnerabilities that are actively exploited will be prioritized
  • Expedited fixes may be available for sponsors or through paid support

• We follow responsible disclosure practices
• Security advisories will be published after a fix is available
• We will credit reporters who wish to be acknowledged
• We request that you do not publicly disclose the vulnerability until we have published a fix

When contributing to EventCore, please follow these security guidelines:

1. Input Validation

   • Always use validated types (nutype) for public API inputs
   • Validate at system boundaries only - internal functions can trust validated types
   • Never trust user input without validation

2. SQL Security

   • Use parameterized queries exclusively - never concatenate SQL strings
   • Review the sqlx query macros to ensure compile-time SQL verification
   • Test for SQL injection attempts in integration tests

3. Error Handling

   • Never expose internal system details in error messages
   • Don't leak database connection strings or file paths
   • Use the thiserror crate for structured error types

4. Dependencies

   • Run cargo audit before submitting PRs
   • Justify any new dependencies in PR descriptions
   • Prefer well-maintained, widely-used crates
   • Check for security advisories on dependencies

5. Memory Safety

   • Avoid unbounded allocations (use limits on collections)
   • Be careful with recursive data structures
   • Use Box for large stack allocations
   • Leverage Rust's ownership system - avoid unsafe code

6. Testing

   • Never commit real credentials or sensitive data
   • Use mock data for all tests
   • Include security-focused test cases (e.g., malformed input)
   • Test error paths thoroughly

• Code Review: All changes require review before merging
• CI Security Checks: All PRs must pass cargo audit and security lints
• Commit Signing: Contributors are encouraged to sign commits with GPG
• Branch Protection: Main branch requires PR reviews and passing CI

When building applications with EventCore, follow these security best practices:

• Never store sensitive data unencrypted in events (passwords, API keys, SSNs, etc.)
• Use encryption for PII and sensitive business data before storing in events
• Consider data retention - events are immutable and permanent by design

// Bad: Storing sensitive data directly
#[derive(Serialize, Deserialize)]
struct UserRegistered {
    email: String,
    password: String,  // Never do this!
}

// Good: Store only necessary data
#[derive(Serialize, Deserialize)]
struct UserRegistered {
    user_id: UserId,
    email_hash: String,  // Store hash for lookups
    registered_at: Timestamp,
}

EventCore doesn't provide built-in authorization. Implement access control at the application layer:

// Implement authorization before command execution
async fn handle_command(
    store: impl EventStore,
    cmd: MyCommand,
    user: AuthenticatedUser,
) -> Result<ExecutionResponse, CommandError> {
    // Check user permissions for the affected streams
    if !user.can_access_stream(&cmd.stream_id()) {
        // EventCore has no `Unauthorized` variant; surface a domain
        // authorization error as a business rule violation (or `.into()`
        // a `&str`/`String` message).
        return Err("unauthorized: user cannot access stream".into());
    }

    // `execute` is a free function, not a method on an executor.
    execute(store, cmd, RetryPolicy::new()).await
}

Always validate and sanitize input at application boundaries:

// Use nutype for domain validation
#[nutype(
    sanitize(trim),
    validate(regex = r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"),
    derive(Debug, Clone, Serialize, Deserialize)
)]
struct Email(String);

// Validate before creating commands
let email = Email::try_new(untrusted_input)
    .map_err(|_| "Invalid email format")?;

Protect against resource exhaustion:

// Execute commands with retry policy
execute(store, command, RetryPolicy::new()).await?;

// Implement rate limiting at API layer
rate_limiter.check_rate_limit(user_id)?;

• Sanitize data before displaying in read models
• Implement row-level security in projections
• Validate projection state before exposing to users

• Log security events (failed auth, suspicious patterns)
• Monitor for anomalies in event patterns
• Alert on security violations promptly

• GDPR: Implement event encryption and consider pseudonymization
• PCI DSS: Never store credit card details in events
• HIPAA: Encrypt all health-related data
• Audit Requirements: Leverage event sourcing's natural audit trail

EventCore includes several security-focused design decisions:

• Type Safety: Extensive use of validated newtypes prevents many common vulnerabilities
• Concurrency Control: Optimistic locking prevents lost updates
• Resource Limits: Configurable timeouts and batch sizes prevent resource exhaustion
• Audit Trail: Event sourcing provides complete audit history by design

EventCore aims to align with industry security standards:

• OWASP Secure Coding Practices
• NIST Software Development Framework
• General secure development lifecycle practices

Specific compliance documentation is in development.

For non-security work, follow the Tiber-backed contribution process in CONTRIBUTING.md.

For security issues, use only the private email reporting process described above.