Security Policy

Reporting a Vulnerability

If you discover a security vulnerability in HeliosDB Nano, please report it by emailing:

security@heliosdb.com

Please do not create public GitHub issues for security vulnerabilities.

We will acknowledge receipt of your vulnerability report within 48 hours and send you regular updates on our progress. If you’re curious about the status of your report, please feel free to email us again.

What to Include

Please include the following information in your report:

• Description of the vulnerability
• Steps to reproduce the issue
• Potential impact
• Any suggested fixes (optional)
• Your name/handle for credit (optional)

Security Model

Threat Model

HeliosDB Nano is designed as an embedded database for trusted applications. Our security model assumes:

In Scope:

• Protection against SQL injection
• Protection against buffer overflows and memory corruption
• Protection against resource exhaustion (DoS)
• Secure encryption of data at rest
• Safe handling of untrusted SQL queries
• Safe handling of untrusted data inputs

Out of Scope (in embedded mode):

• Network-based attacks (no network server in embedded mode)
• Multi-tenant isolation (single-tenant embedded mode)
• Authentication/authorization (application responsibility)

Security Features

1. Memory Safety

• Zero unsafe code in production codebase
• Rust’s memory safety guarantees prevent:
  • Buffer overflows
  • Use-after-free
  • Null pointer dereferences
  • Data races

2. SQL Injection Protection

• SQL parser validation using industry-standard sqlparser-rs
• No string concatenation for query building
• Parameterized query support over the PostgreSQL extended query protocol ($1, $2, …)
• SQL injection tests

3. Cryptography

• AES-256-GCM for data encryption (AEAD)
• Argon2 for password-based key derivation
• Random nonce generation (no nonce reuse)
• Authenticated encryption (tamper detection)

Cryptographic Libraries:

• aes-gcm 0.10 - AES-256-GCM implementation
• ring 0.17 - Cryptographic primitives
• argon2 0.5 - Password hashing
• rustls 0.23 - TLS implementation

4. Input Validation

• Bounds checking on all inputs
• Type validation before operations
• Division by zero protection
• Integer overflow checking (debug builds)

5. Error Handling

• No panics in production code
• Error types
• No information leakage in error messages
• Proper error propagation

6. Resource Management

• Automatic resource cleanup (RAII)
• Planned: memory limits
• Planned: query timeouts
• Planned: connection limits

Security Best Practices

For Application Developers

1. Data Encryption

use heliosdb_nano::crypto::{encrypt, decrypt, derive_key_from_password};

// Derive encryption key from password
let salt = b"random_salt_16_bytes_minimum";
let key = derive_key_from_password("your_password", salt)?;

// Encrypt sensitive data
let plaintext = b"Sensitive data";
let ciphertext = encrypt(&key, plaintext)?;

// Decrypt when needed
let decrypted = decrypt(&key, &ciphertext)?;

Best Practices:

• Use strong passwords (12+ characters, mixed case, numbers, symbols)
• Generate random salts (at least 16 bytes)
• Store salts separately from encrypted data
• Never reuse salts across different datasets
• Consider key rotation for long-lived data

2. SQL Query Safety

use heliosdb_nano::EmbeddedDatabase;

let db = EmbeddedDatabase::new("./data.db")?;

// SAFE: Literal values in SQL
db.execute("SELECT * FROM users WHERE id = 1")?;

// UNSAFE: Don't concatenate user input
let user_input = get_user_input();
// DON'T DO THIS:
// db.execute(&format!("SELECT * FROM users WHERE name = '{}'", user_input))?;

// Instead, validate and sanitize input at application level
let sanitized = sanitize_input(user_input);
db.execute(&format!("SELECT * FROM users WHERE name = '{}'", sanitized))?;

Best Practices:

• Validate all user inputs before using in SQL
• Use application-level input sanitization
• Limit query complexity in user-facing features
• Implement query timeouts for user queries
• Log suspicious query patterns

3. Resource Limits

// Set reasonable limits in your application
const MAX_QUERY_RESULTS: usize = 10_000;
const MAX_QUERY_TIME: Duration = Duration::from_secs(30);

let results = db.query("SELECT * FROM large_table")?;

if results.len() > MAX_QUERY_RESULTS {
    return Err("Query returned too many results");
}

Best Practices:

• Implement application-level query timeouts
• Limit result set sizes
• Monitor memory usage
• Implement rate limiting for queries
• Set maximum database size limits

4. Error Handling

// GOOD: Handle errors properly
match db.execute("SELECT * FROM users") {
    Ok(results) => process_results(results),
    Err(e) => {
        // Log error (without sensitive data)
        error!("Query failed: {}", e);
        // Return user-friendly error
        return Err("Database operation failed");
    }
}

// BAD: Don't expose internal errors to users
// db.execute("SELECT * FROM users").expect("Query failed");

Best Practices:

• Never use unwrap() or expect() in production code paths
• Log errors for debugging
• Return sanitized errors to users
• Don’t expose internal details in error messages

5. Network Listeners (Server Mode)

Keep the HTTP and MySQL listeners on loopback (the default): API-key authentication for the HTTP API is planned, and a smaller listening surface is good practice anyway. When the PostgreSQL listener must be reachable from other hosts, start the server with --listen 0.0.0.0 --http-listen 127.0.0.1; trust authentication is refused on a non-loopback listener, so configure password or SCRAM authentication.

For HeliosDB Nano Contributors

Code Review Checklist

Before submitting code, verify:

• No unsafe blocks (unless absolutely necessary with safety comments)
• No unwrap() or panic!() in production code
• All errors handled with Result<T, Error>
• Input validation for all external inputs
• Bounds checking for array access
• No string concatenation for SQL building
• Tests cover error cases
• No hardcoded secrets or credentials
• Dependencies are up-to-date and audited

Security Testing

Run security tests before submitting:

# Run all tests including security tests
cargo test

# Run security-specific tests
cargo test --test sql_injection_tests
cargo test --test resource_exhaustion_tests
cargo test --test crypto_tests

# Run security audit
./run_security_audit.sh

# Check for unsafe code
grep -r "unsafe" src/ --include="*.rs"

# Check for unwrap/panic
grep -r "unwrap()\|panic!" src/ --include="*.rs"

Dependency Security

Dependency Auditing

We use cargo-audit and cargo-deny to check for known vulnerabilities:

# Install tools
cargo install cargo-audit cargo-deny

# Run audits
cargo audit
cargo deny check

Dependency Policy

• Only use crates from crates.io (no git dependencies in production)
• Prefer well-maintained crates with security audits
• Avoid dependencies with known vulnerabilities
• Keep dependencies up-to-date
• Review dependency changes in PRs

CI/CD Security

Our CI/CD pipeline includes:

1. Dependency Audit - Check for known vulnerabilities
2. Supply Chain Security - Verify dependency licenses and sources
3. Secret Scanning - Detect committed secrets
4. Code Security Analysis - static analysis security lints
5. SAST Analysis - Static analysis for unsafe code
6. Fuzz Testing - Randomized testing for edge cases
7. Container Security - Scan Docker images
8. CodeQL Analysis - Advanced code analysis

See .github/workflows/security.yml for details.

Security Metrics

Current security status:

Metric	Result
Unsafe code blocks	0
unwrap() in production	0
panic!() in production	0
Known vulnerabilities	0
Code coverage	85%+

Security Roadmap

Available

• Memory safety (Rust guarantees)
• SQL injection protection
• Data encryption (AES-256-GCM)
• Zero-knowledge encryption (keys derived and data encrypted on the client)
• Row-level security through the embedded API and the REPL
• Audit logging
• Input validation
• Error handling
• Security test suite

Planned

• Query timeouts
• Resource limits (memory, CPU)
• Connection pooling with limits
• Row-level security through SQL CREATE POLICY, enforced for REST and wire clients
• API key authentication for the HTTP API
• Key rotation support

Future

• Multi-factor authentication
• Role-based access control (RBAC)
• Field-level encryption
• Secure enclaves support
• Hardware security module (HSM) integration
• Compliance certifications (SOC 2, ISO 27001)

Vulnerability Disclosure Timeline

When a vulnerability is reported, we follow this timeline:

1. Day 0: Acknowledge receipt of report
2. Day 1-7: Investigate and verify vulnerability
3. Day 7-14: Develop and test fix
4. Day 14-21: Release patch version
5. Day 21: Public disclosure (coordinate with reporter)

Security Hall of Fame

We appreciate security researchers who responsibly disclose vulnerabilities.

Security Contacts

• Security Email: security@heliosdb.com

References

• Rust Security Guidelines
• OWASP Top 10
• CWE Top 25
• Common Vulnerabilities and Exposures (CVE)

---

Security Policy Version: 1.0