We release patches for security vulnerabilities for the following versions:

Please do not report security vulnerabilities through public GitHub issues.

If you discover a security vulnerability in ramem (RAM), please report it by one of the following methods:

1. Go to the Security tab of this repository
2. Click "Report a vulnerability"
3. Fill out the form with details about the vulnerability

Alternatively, you can email security reports to: security@example.com

Please include:

• A description of the vulnerability
• Steps to reproduce the issue
• Potential impact
• Any suggested fixes (if available)

For sensitive disclosures, you may encrypt your report using our PGP key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
[PGP key would go here]
-----END PGP PUBLIC KEY BLOCK-----

• Acknowledgment: We will acknowledge receipt of your vulnerability report within 72 hours.
• Initial Assessment: We will provide an initial assessment of the vulnerability within 7 days.
• Fix Timeline: We aim to release a fix within 30 days for critical vulnerabilities, 90 days for moderate vulnerabilities.
• Disclosure: We will coordinate disclosure timing with you. We prefer to disclose vulnerabilities after a fix is available.

RAM processes local Claude Code session transcripts and stores them in a local database. The following types of vulnerabilities are in scope:

• Secret Leakage: Vulnerabilities that could expose API keys, tokens, or other secrets from transcripts
• Path Traversal: Issues that could allow reading or writing files outside the intended directories
• Code Injection: Vulnerabilities in transcript parsing or command execution
• Denial of Service: Issues that could crash the application or consume excessive resources
• Data Corruption: Bugs that could corrupt the LanceDB or SQLite databases
• Privilege Escalation: Issues that could allow unauthorized access to system resources
• Information Disclosure: Unintended exposure of transcript content or metadata

• Social Engineering: Attacks that rely on tricking users
• Physical Access: Vulnerabilities requiring physical access to the user's machine
• Outdated Dependencies: Unless actively exploited in RAM's context
• Theoretical Attacks: Without a practical proof of concept

RAM is designed to process local data only. All transcript processing, embedding generation, and search operations occur on the user's machine. No data is sent to external services unless explicitly configured (e.g., OpenAI-compatible embedding API).

RAM includes a content filter (ram-core/src/ingest/filter.rs) that attempts to detect and exclude secrets from indexing. However, this is a best-effort heuristic and should not be relied upon as the sole protection against secret leakage.

Users should:

• Review their Claude Code transcripts before indexing
• Use the ram forget command to remove sensitive content
• Configure .gitignore-style patterns to exclude sensitive files

• LanceDB: Stored in ~/.config/ram/lancedb/ with user-only permissions
• SQLite: Stored in ~/.config/ram/state.db with WAL mode enabled
• Backups: Use ram backup to create encrypted backups if needed

If using an external embedding API (via EmbeddingConfig.backend = "local_api"), be aware that transcript content will be sent to that API endpoint. Ensure the endpoint is trusted and uses TLS.

When using RAM:

1. Review transcripts before bulk indexing with ram init
2. Use ram forget to remove sensitive content
3. Backup regularly with ram backup
4. Keep RAM updated to receive security patches
5. Audit your config in ~/.config/ram/config.toml
6. Monitor logs for unusual activity (if OTel is enabled)

We follow a coordinated disclosure policy:

1. Security researchers report vulnerabilities privately
2. We work with the researcher to understand and fix the issue
3. We prepare a security advisory and patch
4. We coordinate a public disclosure date with the researcher
5. We release the patch and advisory simultaneously
6. We credit the researcher in the advisory (unless they prefer anonymity)

We recognize security researchers who responsibly disclose vulnerabilities:

• No vulnerabilities reported yet

Thank you for helping keep ramem and its users safe!