|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Supported Versions |
| 4 | + |
| 5 | +Given the early stage of the project, we currently only support the latest version with security updates: |
| 6 | + |
| 7 | +| Version | Supported | |
| 8 | +| ------- | ------------------ | |
| 9 | +| 0.0.x | :white_check_mark: | |
| 10 | +| < 0.0.1 | :x: | |
| 11 | + |
| 12 | +## Reporting a Vulnerability |
| 13 | + |
| 14 | +We take the security of Eliza seriously. If you believe you have found a security vulnerability, please report it to us following these steps: |
| 15 | + |
| 16 | +### Private Reporting Process |
| 17 | + |
| 18 | +1. **DO NOT** create a public GitHub issue for the vulnerability |
| 19 | +2. Send an email to security@eliza.builders with: |
| 20 | + - A detailed description of the vulnerability |
| 21 | + - Steps to reproduce the issue |
| 22 | + - Potential impact of the vulnerability |
| 23 | + - Any possible mitigations you've identified |
| 24 | + |
| 25 | +### What to Expect |
| 26 | + |
| 27 | +- **Initial Response**: Within 48 hours, you will receive an acknowledgment of your report |
| 28 | +- **Updates**: We will provide updates every 5 business days about the progress |
| 29 | +- **Resolution Timeline**: We aim to resolve critical issues within 15 days |
| 30 | +- **Disclosure**: We will coordinate with you on the public disclosure timing |
| 31 | + |
| 32 | +## Security Best Practices |
| 33 | + |
| 34 | +### For Contributors |
| 35 | + |
| 36 | +1. **API Keys and Secrets** |
| 37 | + |
| 38 | + - Never commit API keys, passwords, or other secrets to the repository |
| 39 | + - Use environment variables as described in our secrets management guide |
| 40 | + - Rotate any accidentally exposed credentials immediately |
| 41 | + |
| 42 | +2. **Dependencies** |
| 43 | + |
| 44 | + - Keep all dependencies up to date |
| 45 | + - Review security advisories for dependencies regularly |
| 46 | + - Use `pnpm audit` to check for known vulnerabilities |
| 47 | + |
| 48 | +3. **Code Review** |
| 49 | + - All code changes must go through pull request review |
| 50 | + - Security-sensitive changes require additional review |
| 51 | + - Enable branch protection on main branches |
| 52 | + |
| 53 | +### For Users |
| 54 | + |
| 55 | +1. **Environment Setup** |
| 56 | + |
| 57 | + - Follow our [secrets management guide](docs/guides/secrets-management.md) for secure configuration |
| 58 | + - Use separate API keys for development and production |
| 59 | + - Regularly rotate credentials |
| 60 | + |
| 61 | +2. **Model Provider Security** |
| 62 | + |
| 63 | + - Use appropriate rate limiting for API calls |
| 64 | + - Monitor usage patterns for unusual activity |
| 65 | + - Implement proper authentication for exposed endpoints |
| 66 | + |
| 67 | +3. **Platform Integration** |
| 68 | + - Use separate bot tokens for different environments |
| 69 | + - Implement proper permission scoping for platform APIs |
| 70 | + - Regular audit of platform access and permissions |
| 71 | + |
| 72 | +## Security Features |
| 73 | + |
| 74 | +### Current Implementation |
| 75 | + |
| 76 | +- Environment variable based secrets management |
| 77 | +- Type-safe API implementations |
| 78 | +- Automated dependency updates via Renovate |
| 79 | +- Continuous Integration security checks |
| 80 | + |
| 81 | +### Planned Improvements |
| 82 | + |
| 83 | +1. **Q4 2024** |
| 84 | + |
| 85 | + - Automated security scanning in CI pipeline |
| 86 | + - Enhanced rate limiting implementation |
| 87 | + - Improved audit logging |
| 88 | + |
| 89 | +2. **Q1 2025** |
| 90 | + - Security-focused documentation improvements |
| 91 | + - Enhanced platform permission management |
| 92 | + - Automated vulnerability scanning |
| 93 | + |
| 94 | +## Vulnerability Disclosure Policy |
| 95 | + |
| 96 | +We follow a coordinated disclosure process: |
| 97 | + |
| 98 | +1. Reporter submits vulnerability details |
| 99 | +2. Our team validates and assesses the report |
| 100 | +3. We develop and test a fix |
| 101 | +4. Fix is deployed to supported versions |
| 102 | +5. Public disclosure after 30 days or by mutual agreement |
| 103 | + |
| 104 | +## Recognition |
| 105 | + |
| 106 | +We believe in recognizing security researchers who help improve our security. Contributors who report valid security issues will be: |
| 107 | + |
| 108 | +- Credited in our security acknowledgments (unless they wish to remain anonymous) |
| 109 | +- Added to our security hall of fame |
| 110 | +- Considered for our bug bounty program (coming soon) |
| 111 | + |
| 112 | +## License Considerations |
| 113 | + |
| 114 | +As an MIT licensed project, users should understand: |
| 115 | + |
| 116 | +- The software is provided "as is" |
| 117 | +- No warranty is provided |
| 118 | +- Users are responsible for their own security implementations |
| 119 | +- Contributors grant perpetual license to their contributions |
| 120 | + |
| 121 | +## Contact |
| 122 | + |
| 123 | +- Security Issues: security@eliza.builders |
| 124 | +- General Questions: Join our [Discord](https://discord.gg/ai16z) |
| 125 | +- Updates: Follow our [security advisory page](https://github.com/ai16z/eliza/security/advisories) |
0 commit comments