If you discover a security vulnerability, please do not open a public GitHub issue.

Instead, report it via GitHub's private vulnerability reporting:

1. Go to the Security tab of this repository
2. Click "Report a vulnerability"
3. Provide a description, steps to reproduce, and potential impact

We will acknowledge your report within 48 hours and aim to release a fix within 14 days for confirmed vulnerabilities.

M3 Memory is designed with security as a first-class concern:

• FIPS 140-3 deployment-ready — all cryptography routes through wolfCrypt, with a Tier-2 path that runs on the CMVP-validated wolfCrypt FIPS module. Crypto fails closed when the FIPS provider is absent, power-up known-answer tests gate startup, and library loading is hardened against DLL-hijack. M3 is the consumer of the validated module, not itself a validated boundary — see Sovereign Deployment.
• Credential storage — AES-256-GCM encrypted vault (PBKDF2-HMAC-SHA256, 600K iterations — meets OWASP guidance). API keys and secrets never stored in plaintext. OS keyring integration (Keychain on macOS, Credential Manager on Windows).
• Content integrity — SHA-256 hash computed and stored on every write. memory_verify re-computes and compares to detect post-write tampering.
• Input safety — write boundary rejects XSS, SQL injection, Python code injection, and prompt injection patterns before data reaches storage.
• Search safety — FTS5 operator sanitization prevents query injection.
• Network hardening — circuit breaker (3-failure threshold), strict timeouts, API tokens never logged.
• Data locality — all data remains on your hardware by default. Optional sync to PostgreSQL is under your control.

In-scope for vulnerability reports:

• Authentication/authorization bypass
• Credential vault weaknesses
• Input sanitization bypasses (XSS, injection, poisoning)
• Data exfiltration vulnerabilities
• Tamper detection failures

Out of scope:

• Issues requiring physical access to the machine
• Social engineering attacks
• Vulnerabilities in third-party dependencies (report to the upstream project)

We run bandit (static analysis), regex-based secrets scans, and pip-audit (dependency CVEs) against the tree and publish the results. Each scan is dated and reproducible — every report includes the exact commands so you can verify on your own machine.

What "periodic" means here, concretely: a full published audit at least quarterly, and always before a release that changes the security surface. The dated table below is the evidence — if the newest row is more than a quarter old, the practice has lapsed, and you should read that as a gap rather than as assurance. (It did lapse once: 2026-05-01 → 2026-09-08.) Continuous coverage between audits comes from CI, which runs pip-audit scoped to core dependencies on every push.

CI runs pip-audit scoped to core dependencies on every push, so new CVEs in shipped-library deps surface immediately. See .github/workflows/ci.yml.