If you believe you've found a security issue in Scarlett Help, please report it privately.
- Email:
contact@voxhash.dev - What to include: reproduction steps, impact assessment, and (if possible) a minimal PoC.
For threat model + hardening guidance, see:
docs/security.md(when created)
Scarlett Help's web interface is intended for local use or behind proper authentication. Do not expose it to the public internet without proper security measures.
Scarlett Help requires Python 3.11 or later. This version includes important security patches and features.
Verify your Python version:
python --version # Should be 3.11 or laterFrontend requires Node.js 18 or later (LTS recommended).
Verify your Node.js version:
node --version # Should be v18 or laterWhen running Scarlett Help in Docker:
- The official image should run as a non-root user for reduced attack surface
- Use
--read-onlyflag when possible for additional filesystem protection - Limit container capabilities with
--cap-drop=ALL - Use secrets management for API keys and sensitive data
Example secure Docker run:
docker run --read-only --cap-drop=ALL \
-v scarlett-help-data:/app/data \
-e OPENAI_API_KEY=${OPENAI_API_KEY} \
scarlett-help:latest- Never commit API keys to the repository
- Use environment variables for sensitive configuration
- Rotate API keys regularly
- Use different keys for development and production
- Use strong passwords for PostgreSQL
- Enable SSL/TLS for database connections in production
- Regularly backup database
- Use connection pooling with limits
- Implement proper authentication for production deployments
- Use HTTPS in production
- Implement rate limiting
- Validate and sanitize all user inputs
- Keep dependencies up to date
- Regularly run security audits:
npm auditandpip-audit - Use dependency pinning for production
- Review dependency licenses
cd frontend
npm audit
npm audit fixcd backend
pip install pip-audit
pip-audit- CORS: Currently allows all origins in development. Restrict in production.
- API Keys: Stored in environment variables. Consider using a secrets manager in production.
- Database: Uses PostgreSQL. Ensure proper access controls.
- Redis: Used for caching. Ensure proper network isolation.
If you discover a security vulnerability, please:
- Do not open a public issue
- Email
contact@voxhash.devwith:- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
We will respond within 48 hours and work with you to resolve the issue.
- Initial Report: Email security report to
contact@voxhash.dev - Acknowledgment: We will acknowledge receipt within 48 hours
- Investigation: We will investigate and verify the vulnerability
- Fix Development: We will develop and test a fix
- Disclosure: After fix is deployed, we will:
- Update CHANGELOG.md with security fix details
- Credit the reporter (if desired)
- Publish security advisory if critical
Security updates are released as patch versions (e.g., 1.0.1 → 1.0.2) following semantic versioning. Critical security fixes may be released as hotfixes outside the normal release cycle.
We provide security updates for:
- Latest major version
- Previous major version (for 6 months after new major release)
- Keep dependencies updated:
npm auditandpip-audit - Use strong passwords and API keys
- Enable rate limiting in production
- Use HTTPS in production
- Regularly review and rotate credentials
- Monitor security advisories