We take security vulnerabilities seriously. If you discover a security vulnerability in Aspida, please report it responsibly.

Do NOT open a public issue. Instead, please:

1. Email security reports to: [TBD - add security email]
2. Include "SECURITY" in the subject line
3. Provide:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 7 days
• Status Updates: Every 7 days until resolved
• Disclosure: After fix is released (typically 90 days)

Aspida implements several security features:

• End-to-End Encryption: X25519 key exchange + ChaCha20-Poly1305 AEAD
• SPARK Verification: ChaCha20, SHA-256, HKDF & PBKDF2 proved to absence-of-runtime-errors + functional contracts (make prove); the rest of the crypto library is SPARK flow-analysed (make prove-flow). X25519/Poly1305/AEAD field-arithmetic proofs are tracked as future work.
• Constant-Time Operations: Timing-safe comparisons, secure memory wiping
• Forward Secrecy: Ephemeral key exchange per session
• No Third-Party Crypto: All cryptographic primitives implemented from scratch

1. Model Files: GGUF weights are not encrypted at rest. Set ASPIDA_STORE_PASSWORD to enable PBKDF2/ChaCha20-Poly1305 encryption of persisted session history (not weights); rely on host disk encryption (LUKS/FileVault) for weight confidentiality.

2. Client Tokens: ASPIDA_CLIENT_TOKEN should be kept secret. Do not commit to version control.

3. GPU Memory: GPU offload may expose model weights in memory. Consider threat model before enabling.

4. Network: Default configuration binds to 0.0.0.0. Use ASPIDA_BIND=127.0.0.1 for local-only access.

5. Untrusted code execution: the verifier-driven training path (Exec_Verifier, src/train/exec_verifier.adb) runs model-generated code — that is the point of a verifier, and it is the sharpest attack surface in this repo. In-process hardening (unique scratch path, direct exec with no shell, suppressed output, wall-clock timeout) is a down-payment, not containment.

   Set ASPIDA_VERIFY_SANDBOX to a sandbox command prefix and every execution is wrapped by it. This is required before any multi-tenant or rented-host use:

   # Preinstalled util-linux only (unshare -n + setpriv nobody + timeout -KILL + ulimits);
   # verified on Linux to block network egress incl. cloud metadata, run as nobody,
   # and kill runaways at the timeout.
   ASPIDA_VERIFY_SANDBOX=tools/verify_sandbox.sh
   
   # or firejail:
   ASPIDA_VERIFY_SANDBOX='firejail --quiet --net=none --private \
     --rlimit-cpu=10 --rlimit-as=536870912 --seccomp'
   
   # or a container wrapper:
   ASPIDA_VERIFY_SANDBOX='docker run --rm -i --network=none --read-only \
     --user 65534 --memory=512m --pids-limit=64 --cap-drop=ALL aspida-verify'

   Whatever you choose must provide: non-root, read-only rootfs, fresh tmpfs, no network and blocked cloud-metadata (169.254.169.254), rlimits/cgroups, and seccomp. While untrusted code runs, give one tenant one dedicated host.

1. Authentication: Always set ASPIDA_CLIENT_TOKEN in production
2. TLS: Use a reverse proxy (nginx, Caddy) for TLS termination
3. Firewall: Restrict access to trusted IPs
4. Updates: Keep up to date with security patches
5. Logs: Monitor for suspicious activity

All cryptographic implementations follow published standards:

Aspida has not yet undergone a formal security audit. We welcome security researchers to review the code.

• We follow responsible disclosure
• CVEs will be assigned for confirmed vulnerabilities
• Security advisories will be published on GitHub Security tab
• Credit will be given to reporters (unless anonymity requested)

Thank you for helping keep Aspida secure! 🔒