RuscaDB es una base de datos embebida, in-process, multi-modelo y multimodal escrita en Rust. Esta política describe cómo reportar vulnerabilidades, qué versiones se soportan, el alcance del modelo de amenazas y la política de unsafe.

El canon de referencia es OWASP (Top 10, ASVS, SAMM), MITRE CWE y las prácticas de seguridad de GitHub (security advisories privados, Dependabot, secret scanning, push protection). Las clases de debilidad relevantes para una DB in-process se citan como CWE-XXXX.

Solo se aplican parches de seguridad a la última versión de la serie 0.1.x (estado pre-1.0, API inestable).

Antes de 1.0 el proyecto puede introducir cambios incompatibles en versiones MINOR; los avisos de seguridad se publican siempre para la última 0.1.z.

NO abras un issue público. Un issue público expone la vulnerabilidad antes de que exista un parche (coordinación de divulgación responsable / CWE-1059 deficiencias de documentación de seguridad).

Usa uno de estos canales privados:

1. GitHub Security Advisory (preferido) — pestaña Security → Advisories → Report a vulnerability del repositorio (https://github.com/ruscadb/ruscadb/security/advisories/new). Permite discutir el reporte de forma privada y coordinar el CVE.
2. Email — security@ruscadb.dev. Si quieres cifrar el reporte, solicita primero la clave pública PGP en ese mismo buzón.

Incluye, en lo posible:

• versión de RuscaDB (0.1.z) y plataforma/arquitectura;
• el crate o capa afectada (ruscadb-query, ruscadb-wal, ruscadb-ffi, ruscadb-vector, ruscadb-multimodal, ruscadb-crypto, …);
• una descripción del impacto y un PoC mínimo (input, RQL, blob o llamada al C-ABI) que reproduzca el fallo;
• clasificación sugerida CWE-XXXX y, si aplica, el mapeo OWASP;
• si lo deseas, tu nombre/afiliación y si quieres crédito público.

Estos plazos son objetivos de buena fe (proyecto pre-1.0, mantenido por voluntarios). Si el reporte está activamente explotado, se prioriza la mitigación inmediata.

RuscaDB corre en el mismo proceso que la aplicación anfitriona: no hay frontera de proceso ni de red. Por tanto, un fallo de corrupción de memoria en el parser, la deserialización o la FFI es un fallo de la app anfitriona (RCE o corrupción de datos, CWE-119 memoria fuera de límites, CWE-416 use-after-free, CWE-787 escritura fuera de límites). «Es seguro por estar en Rust» es falso: el unsafe acotado, la deserialización y el parser son la superficie real.

• Ataques que requieren acceso físico o root al host: cifrado en reposo protege el archivo en disco, no un adversario con control total de la máquina (keylogging, volcado de memoria del proceso vivo).
• La aplicación anfitriona: validación de identidad, autenticación, autorización de negocio, TLS/servidor y manejo de las claves que RuscaDB recibe. RuscaDB es una librería embebida: no expone red ni usuarios.
• Configuración insegura deliberada: capacidades file/net/script habilitadas, presupuestos de recursos elevados o desactivar la verificación de integridad (CRC32C) por parte del integrador.
• DoS de recursos cuando el anfitrión amplía los límites por encima de los defaults seguros documentados (docs/RuscaDB-roadmap.md §6.4).
• Dependencias de terceros: se enrutan a su upstream (RustSec), aunque el proyecto las rastrea con cargo-audit/cargo-deny y SBOM.

El unsafe es el riesgo número uno de una DB in-process. La política es release-blocking:

• Solo ruscadb-ffi habilita unsafe (#![allow(unsafe_code)]) porque su contrato es el C-ABI. Todos los demás crates lo prohíben con #![forbid(unsafe_code)].
• El presupuesto de bloques unsafe por crate vive versionado en unsafe-allowlist.toml y lo verifica scripts/check_core_unsafe.py en el gate T1. Ningún unsafe nuevo entra sin ampliar el presupuesto en un PR revisado.
• Cada bloque unsafe lleva un comentario // SAFETY: que justifica por qué las precondiciones se cumplen. Los lints undocumented_unsafe_blocks, missing_safety_doc y multiple_unsafe_ops_per_block están en deny; unsafe_op_in_unsafe_fn en deny.
• La frontera C valida (ptr, len) antes de from_raw_parts/dereferenciar, usa una tabla de handles con marca mágica + generación (anti doble-free / use-after-free) y captura panics con catch_unwind para que ninguno cruce el ABI.
• Cobertura adicional: miri (UB) en crates sin unsafe, AddressSanitizer (ASan) sobre ruscadb-ffi y cargo-fuzz sobre el parser RQL y la recuperación del WAL (.github/workflows/nightly.yml).

• Integridad: CRC32C por frame de WAL; frames manipulados se truncan o rechazan. El manifiesto y el heap .data no llevan checksum propio: su durabilidad depende de la escritura atómica (tmp + fsync + rename).
• Datos en reposo (opcional): AEAD XChaCha20-Poly1305 sobre el WAL (el heap .data hereda el cifrado), passphrase → Argon2id → clave de 256 bits, zeroize para el material sensible.
• Límites de recursos por defecto: profundidad AST 64, query budget 100 000, timeout 5 000 ms, LIMIT implícito 1 000 filas, blob 256 MiB, dimensión de vector ≤ 4 096, traversal depth 16.
• Path safety: file() restringido al sandbox root (canonicalización + prefijo; anti ../symlink).
• Supply chain: Cargo.lock --locked, cargo-audit, cargo-deny, toolchain pinneada, SBOM CycloneDX por release y gitleaks en pre-commit/CI.

• Autenticación por defecto: el servidor MCP arranca sin sesión; todo método de datos (tools/*, resources/*) devuelve -32001 hasta completar el handshake session/auth con un token que solo el proceso padre puede emitir (McpServer::issue_session_token). Los mensajes de error jamás contienen el token ni material de key.
• Tokens AEAD: v1.<kid>.<nonce>.<ciphertext> — el payload (ruscadb-mcp-session-v1) se sella con XChaCha20-Poly1305 bajo la key activa del keystore; la validación es criptográfica y constante (tag Poly1305), sin estado en memoria del emisor.
• Rotación = revocación: rotate() retira la key activa; todos los tokens de esa key quedan invalidados en el acto (incluso en procesos posteriores si el keystore está en disco). No hay TTL: la rotación es el mecanismo de revocación.
• KMS-lite (alcance local): el keystore es un fichero JSON versionado (version, kid, status) creado con permisos 0600 en unix. Las keys viven en claro a propósito: cifrarlas exigiría una passphrase fuera de alcance. Amenaza asumida: lectura local con permisos de fichero (mismo usuario). Amenaza fuera de alcance: KMS remoto/nube, rotación automática por tiempo, transporte HTTP/TLS.
• Modelo MCP local: el transporte es stdio (sin red); la amenaza mitigada es un cliente local que hable por el stdio del hijo sin ser el padre que lo lanzó.

Gracias por ayudar a mantener RuscaDB seguro.