Svalinn-Project Compliance: 20%

Svalinn is a Deno-based HTTP gateway under active security development. This document describes our current security status, implemented features, and known limitations.

IMPORTANT: Post-quantum TLS is CRITICAL for svalinn-project compliance but blocked by Deno's crypto backend. Options:

1. Wait for Deno to integrate OQS-BoringSSL (6-12 months)
2. Rewrite Svalinn in Rust with Hyper + Rustls + liboqs (2-3 months)
3. Put nginx with OQS-OpenSSL in front of Svalinn (1-2 weeks)

1. Navigate to Report a Vulnerability
2. Click "Report a vulnerability"
3. Complete the form with as much detail as possible
4. Submit — we'll receive a private notification

⚠️ Important: Do not report security vulnerabilities through public GitHub issues or discussions.

As an HTTP gateway for verified container operations, Svalinn has specific security requirements:

• OAuth2 / OIDC flows with token refresh
• JWT signature verification (RS256, ES256)
• API key authentication with configurable scopes
• mTLS for machine-to-machine authentication
• RBAC planned (not yet implemented)

• JSON Schema validation for all requests (Ajv)
• Gatekeeper policy format validation
• URL validation (SSRF prevention planned)
• Request size limits

• TLS 1.3 enforced (Deno default)
• HSTS with preload directive
• Strong cipher suites (BoringSSL defaults)
• No PQ-TLS yet (Deno limitation)

We've created OWASP ModSecurity Core Rule Set (CRS) configurations in config/modsecurity/:

Defenses Configured:

• SQL injection detection and blocking
• XSS attack detection
• SSRF prevention (localhost/private IP blocking)
• Rate limiting (100 req/min per IP)
• Request size limits
• Suspicious header detection

Deployment Options:

1. Nginx with ModSecurity: Put nginx in front of Svalinn, load ModSecurity module
2. Apache with mod_security2: Use Apache as reverse proxy
3. Cloudflare WAF: Use Cloudflare's managed WAF (commercial)

Deployment Required: ModSecurity is not yet active. Configs are ready but need web server integration.

We've created firewalld zone configurations in config/firewalld/zones/:

Zones:

• svalinn-edge.xml: Public-facing HTTPS gateway (ports 80, 443)
• svalinn-internal.xml: Internal service communication (MCP to Vörðr)

Deployment Steps:

# Copy zone files
sudo cp config/firewalld/zones/*.xml /etc/firewalld/zones/

# Reload firewalld
sudo firewall-cmd --reload

# Assign interface to zone
sudo firewall-cmd --zone=svalinn-edge --add-interface=eth0 --permanent

1. No Post-Quantum TLS
   • Uses classical TLS 1.3 (RSA/ECDHE key exchange)
   • Session keys vulnerable to future quantum computers
   • Mitigation Options:
     • Wait for Deno PQ-TLS support (6-12 months)
     • Rewrite in Rust with liboqs (2-3 months)
     • Nginx PQ-TLS frontend (1-2 weeks)

1. No QUIC / HTTP/3

   • Uses HTTP/2 (1-RTT TLS handshake vs 0-RTT with QUIC)
   • Head-of-line blocking on lossy networks
   • Mitigation: Track Deno issue #9900

2. ModSecurity Not Deployed

   • WAF configs created but not active
   • No OWASP Top 10 runtime protection yet
   • Fix: Deploy nginx with ModSecurity (1-2 weeks)

1. No SSRF Protection

   • URL validation not implemented
   • Could allow server-side request forgery attacks
   • Fix: Add URL allowlist validation (2-3 days)

2. No RBAC

   • JWT verification works but no role-based access control
   • All authenticated users have same permissions
   • Fix: Implement role/scope checking (1 week)

3. No MFA

   • OAuth2 works but no multi-factor authentication
   • Single factor (password/token) only
   • Fix: Add TOTP/WebAuthn support (2-3 weeks)

When deploying Svalinn in production:

• Deploy behind nginx with OWASP ModSecurity enabled
• Configure firewalld zones with principle of least privilege
• Use TLS 1.3 with strong ciphers only
• Enable HSTS with preload directive
• Isolate in Kubernetes namespace or Docker network

• Use OAuth2 / OIDC for human users
• Use mTLS for machine-to-machine (Vörðr communication)
• Rotate API keys regularly (90 days recommended)
• Store secrets in vault (HashiCorp Vault, Kubernetes Secrets)
• Enable MFA when support is added

• Forward logs to SIEM (Splunk, ELK, Datadog)
• Alert on authentication failures (5+ in 5 minutes)
• Alert on rate limit violations
• Monitor ModSecurity blocks
• Track certificate expiration

• Subscribe to GitHub security advisories
• Apply security patches within 7 days
• Test updates in staging first
• Keep Deno runtime updated

We follow coordinated disclosure (responsible disclosure):

1. You report the vulnerability privately
2. We acknowledge and begin investigation (48 hours)
3. We develop a fix and prepare a release
4. We coordinate disclosure timing with you
5. We publish security advisory and fix simultaneously
6. You may publish your research after disclosure

• We will not take legal action against researchers who follow this policy
• We will work with you to understand and resolve the issue
• We will credit you in the security advisory (unless you prefer anonymity)
• We will notify you before public disclosure

• Report vulnerabilities promptly after discovery
• Give us reasonable time to address the issue (90 days)
• Do not access, modify, or delete data beyond proof-of-concept
• Do not share vulnerability details until coordinated disclosure

• DEPLOYMENT.adoc - Production deployment guide (includes security hardening)
• TESTING.adoc - Security testing procedures
• ROADMAP.adoc - Security feature roadmap
• Cerro Torre MISSING-SECURITY-COMPONENTS.adoc - Ecosystem security audit

Thank you for helping keep Svalinn and its users safe. 🛡️

_{Last updated: 2026-01-28 · Policy version: 1.0.0 · v0.2.0-rc1 Status}