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 — [email protected]. 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/BLAKE3) 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/cargo-vet 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), ASan/UBSan, cargo-geiger, y cargo-fuzz sobre parser, WAL/CRC, blob, FFI y modelos.

• Integridad: CRC32C por frame de WAL y BLAKE3 en páginas/manifiesto; frames manipulados se truncan o rechazan.
• Datos en reposo (opcional): AEAD XChaCha20-Poly1305 / AES-256-GCM, passphrase → Argon2id → DEK, secrecy + 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, cargo-vet, toolchain pinneada, SBOM CycloneDX por release y gitleaks en pre-commit/CI.

Gracias por ayudar a mantener RuscaDB seguro.