---
title: "Security Policy"
description: "HeliosDB Lite security policy: how to report a vulnerability, the security model, encryption at rest, query safety and resource limits."
---

# Security Policy

## Reporting a Vulnerability

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

**security@heliosdb.com**

**Please do not disclose security vulnerabilities publicly.**

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 Lite 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 queries** (`$1`, `$2`, ...) over the PostgreSQL wire protocol and the REST API
- **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**
- **Typed errors**
- **No information leakage** in error messages
- **Proper error propagation**

#### 6. Resource Management

- **Automatic resource cleanup** (RAII)
- **Per-user memory limits, query timeouts and result-row caps** (`[resource_quotas]`)
- **Connection limits** (`[server] max_connections`, default 100)

## Security Best Practices

### For Application Developers

#### 1. Data Encryption

Enable AES-256-GCM encryption at rest in the configuration file and keep the key out of it:

```toml
[encryption]
enabled = true
key_source = { Environment = "HELIOSDB_ENCRYPTION_KEY" }
```

```bash
export HELIOSDB_ENCRYPTION_KEY="$(openssl rand -hex 32)"
export HELIOSDB_JWT_SECRET="$(openssl rand -hex 32)"
heliosdb-lite start --data-dir ./data --config heliosdb.toml
```

**Best Practices:**
- Generate keys with a cryptographically secure random source
- Store keys in a secret manager, never in the configuration file or in source control
- Back up the key separately from the data; data encrypted with a lost key cannot be recovered
- Rotate keys for long-lived data

#### 2. SQL Query Safety

Never build SQL by concatenating user input. Send values as parameters with your PostgreSQL driver:

```python
import psycopg

with psycopg.connect("host=127.0.0.1 port=5432 user=app") as conn:
    # SAFE: the value travels as a bound parameter
    conn.execute("SELECT * FROM users WHERE name = %s", (user_input,))

    # UNSAFE: string formatting lets input change the statement
    # conn.execute(f"SELECT * FROM users WHERE name = '{user_input}'")
```

**Best Practices:**
- Use bound parameters for every value that comes from a user
- Limit query complexity in user-facing features
- Set query timeouts for user queries
- Log suspicious query patterns

#### 3. Resource Limits

Cap what a single user or query can consume:

```toml
[resource_quotas]
memory_limit_per_user_mb = 1024
max_concurrent_queries = 100
query_timeout_secs = 30
max_result_rows = 10000

[server]
max_connections = 100
```

**Best Practices:**
- Set query timeouts and result-row caps for user-facing workloads
- Monitor memory usage
- Rate-limit clients at the application or a reverse proxy
- Set maximum database size limits

#### 4. Error Handling

**Best Practices:**
- Log errors for debugging, without sensitive data
- Return sanitized errors to users
- Don't expose internal details in error messages

## Dependency Security

### Dependency Auditing

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

```bash
# 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

## Security Metrics

Current security status:

| Metric | Result |
|--------|--------|
| Unsafe code blocks | 0 |
| unwrap() in production | 0 |
| panic!() in production | 0 |
| Known vulnerabilities | 0 |

## 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
- Bug Bounty Program: planned

## References

- [Rust Security Guidelines](https://anssi-fr.github.io/rust-guide/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [CWE Top 25](https://cwe.mitre.org/top25/)
- [Common Vulnerabilities and Exposures (CVE)](https://cve.mitre.org/)