Skip to content

Security: edycutjong/somapulse

Security

SECURITY.md

Security Policy — SomaPulse

Supported Versions

Version Supported
0.1.x (current) ✅ Active

Reporting a Vulnerability

If you discover a security vulnerability in SomaPulse, please report it responsibly.

Do NOT open a public GitHub issue for security vulnerabilities.

Instead, please email: security@edycu.dev

Include the following in your report:

  • Description of the vulnerability
  • Steps to reproduce
  • Potential impact assessment
  • Suggested fix (if any)

We will acknowledge receipt within 48 hours and provide an initial assessment within 5 business days.

Security Architecture

Edge-First / Offline-First Design

SomaPulse is architecturally designed to operate with zero network connectivity. This fundamentally eliminates entire classes of network-based attacks.

  • No Cloud API Calls: All AI inference (Whisper.cpp, SapBERT ONNX) runs locally on the device
  • No Data Exfiltration Path: Patient symptom transcripts never leave the local machine during triage
  • No Authentication Required: The system is designed for emergency field use — no login gates during crisis response

Medical Data Privacy

  • No PII Collection: SomaPulse does not collect, store, or transmit patient names, IDs, or demographic data
  • Ephemeral Transcripts: Voice recordings are processed in-memory and discarded after transcription — no audio files are persisted
  • Local-Only Vector Search: All protocol matching occurs against a pre-seeded local SQLite database; no external database queries

AI Model Security

  • Quantized Models: Whisper.cpp uses 16-bit GGML quantization — models are static, versioned, and cannot be tampered with at runtime
  • ONNX Sandboxing: SapBERT runs via ONNX-runtime in a read-only inference mode — no model training or fine-tuning occurs on-device
  • Deterministic Seeds: The protocol database (protocols.db) is generated by a deterministic seed.py script with known, auditable medical content

Data Layer

  • Row-Level Security (RLS): Supabase tables (used for the dashboard demo) enforce RLS — anonymous users have read-only access
  • Environment Variables: All secrets (SUPABASE_ANON_KEY) are stored in .env.local and excluded via .gitignore

Frontend

  • Client-Side Only: Supabase queries use the public anon key — no service_role key is exposed to the browser
  • No External Scripts: The dashboard loads zero third-party analytics or tracking scripts

Threat Model

Threat Mitigation
Patient data leakage No PII stored; transcripts are ephemeral in-memory only
Network interception (MITM) Eliminated — system runs fully offline with no network calls
Model poisoning Models are static GGML/ONNX files; no on-device training or fine-tuning
Credential exposure .env.local excluded from git; only public anon key used client-side
SQL injection SQLite queries use parameterized bindings; Supabase SDK uses parameterized queries
XSS Next.js automatically escapes rendered content; no dangerouslySetInnerHTML
Prompt injection No LLM prompts — system uses embedding similarity, not generative text

Dependencies

We regularly review dependencies for known vulnerabilities:

npm audit          # Check for known CVEs
npm audit fix      # Auto-fix where possible

Medical Disclaimer

SomaPulse is a decision-support tool, not a certified medical device. It should be used to supplement — not replace — clinical judgment by trained medical professionals. Protocol recommendations are based on pre-seeded guidelines and may not reflect the latest clinical evidence.

Disclosure Policy

  • We follow coordinated disclosure practices
  • Reporters will be credited in release notes (unless anonymity is requested)
  • We do not pursue legal action against good-faith security researchers

There aren't any published security advisories