NIMA Core uses SQLite as its sole storage backend, with optional extensions (sqlean, sqlite_vec). All database access uses parameterized queries to prevent SQL injection. This document outlines security practices and how to report vulnerabilities.

All queries use parameterized placeholders (?). No user-controlled strings are interpolated directly into SQL.

# CORRECT — parameterized query
cursor.execute("SELECT * FROM memory_nodes WHERE who = ?", (user_input,))

# WRONG — string interpolation (never do this)
cursor.execute(f"SELECT * FROM memory_nodes WHERE who = '{user_input}'")

• Memory layer names are validated against a whitelist before use
• Numeric parameters (hours, limits) are cast to int with range checks
• Session keys and conversation IDs are validated as non-empty strings

NIMA optionally loads two SQLite extensions:

Extensions are loaded via conn.enable_load_extension(True) only during initialization, then disabled. No user-controlled extension paths are accepted.

• All multi-statement operations use explicit transactions
• WAL (Write-Ahead Logging) mode is enabled for concurrent read access
• Connection pooling prevents lock contention (up to 5 connections)

Memory entries can be signed with HMAC-SHA256 to detect tampering:

• Signatures cover text content, timestamps, and metadata
• Verification runs during recall to flag corrupted entries

hybrid_search.py and other file-accessing modules validate paths:

• Database paths are resolved to absolute paths and checked against NIMA_HOME
• No user-controlled input is used to construct file paths
• All file operations use os.path.realpath() to resolve symlinks

• Database files are created with user-only permissions (0600)
• WAL mode enabled by default for safe concurrent access
• PRAGMA journal_mode=WAL and PRAGMA synchronous=NORMAL set at connection time

DO NOT open a public GitHub issue.

Report security vulnerabilities privately:

1. Email: Send details to the project maintainers (see pyproject.toml)
2. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if available)

• Acknowledgment within 48 hours
• Assessment within 7 days
• Fix timeline communicated based on severity
• Credit in release notes (if desired)

1. Parameterized queries everywhere -- never interpolate user input into SQL
2. Input validation at entry points -- validate before use, not after
3. Principle of least privilege -- minimal database permissions
4. Fail securely -- on validation failure, reject the request
5. Extension loading -- only from trusted pip packages, disabled after init

• OWASP Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
• SQLite Security: https://www.sqlite.org/security.html

Last Updated: 2026-04-04 Security Review Required: When adding new SQL queries or modifying database access patterns