-
NEVER commit API keys to version control
- The
keys.pyfile is already in.gitignore - Always use
keys.example.pyas a template - Never share your actual
keys.pyfile
- The
-
Keep your API keys private
- Don't share keys in screenshots
- Don't post keys in issues or pull requests
- Don't include keys in documentation
-
Rotate keys regularly
- Change your API keys periodically
- Immediately rotate if you suspect a key has been exposed
- Use different keys for development and production
Security Level: ⭐⭐⭐ Medium
✅ Pros:
- Easy to manage multiple configurations
- Can be version controlled (without API keys)
- Supports environment-specific settings
- API keys stored in plain text
- Need to ensure config.json is in .gitignore if it contains keys
Best Practice: Use environment variables for API keys in config.json:
{
"ai_provider": {
"api_key": "${DEEPSEEK_API_KEY}"
}
}Security Level: ⭐⭐⭐⭐ High
✅ Pros:
- Keys never stored in files
- Different keys per environment
- Standard security practice
- Need to set up for each environment
- Can be forgotten in deployment
Setup:
# Linux/macOS
export DEEPSEEK_API_KEY="your-key-here"
export OPENAI_API_KEY="your-key-here"
# Windows (PowerShell)
$env:DEEPSEEK_API_KEY="your-key-here"
$env:OPENAI_API_KEY="your-key-here"
# Windows (CMD)
set DEEPSEEK_API_KEY=your-key-here
set OPENAI_API_KEY=your-key-hereSecurity Level: ⭐⭐⭐ Medium
✅ Pros:
- Simple to set up
- Works immediately
- Already in .gitignore
- Easy to accidentally commit if .gitignore is misconfigured
- Keys stored in plain text
Setup:
# Copy the template
cp keys.example.py keys.py
# Edit keys.py with your actual keys
# The file is automatically excluded from gitRun this command to ensure keys.py is ignored:
git check-ignore keys.pyExpected output: keys.py (means it's properly ignored)
# Check if keys.py is tracked by git
git ls-files | grep keys.pyExpected output: (empty - no output means it's not tracked)
# Search git history for potential key leaks
git log --all --full-history --source --pretty=format:"%h %s" -- keys.py-
Revoke the exposed key immediately
- OpenAI: https://platform.openai.com/api-keys
- DeepSeek: https://platform.deepseek.com/api_keys
- Other providers: Check their respective dashboards
-
Generate a new key
- Create a new API key from your provider's dashboard
- Update your local configuration
-
Remove from git history (if committed):
# Use git filter-branch or BFG Repo-Cleaner # WARNING: This rewrites history git filter-branch --force --index-filter \ "git rm --cached --ignore-unmatch keys.py" \ --prune-empty --tag-name-filter cat -- --all # Force push (only if necessary and coordinated with team) git push origin --force --all
-
Notify your team
- If working in a team, inform everyone about the incident
- Ensure everyone updates their local keys
-
Use separate keys for development and production
-
Set up environment variables in your shell profile:
# Add to ~/.bashrc or ~/.zshrc export DEEPSEEK_API_KEY="dev-key-here"
-
Use a password manager to store API keys securely
-
Use environment variables or secret management services
- AWS Secrets Manager
- Azure Key Vault
- HashiCorp Vault
- Google Cloud Secret Manager
-
Implement key rotation policies
-
Monitor API usage for anomalies
-
Set up usage limits and alerts
- Document the key management process
- Use a shared secret management tool
- Implement code review for configuration changes
- Set up pre-commit hooks to prevent key commits:
# .git/hooks/pre-commit
#!/bin/bash
if git diff --cached --name-only | grep -q "keys.py"; then
echo "Error: Attempting to commit keys.py"
echo "This file should never be committed!"
exit 1
fiConfigure API key restrictions at the provider level:
- IP address restrictions
- Usage quotas
- Rate limiting
- Allowed endpoints
Set up monitoring for:
- Unusual API usage patterns
- Failed authentication attempts
- Unexpected geographic access
- Cost anomalies
- Review API key usage monthly
- Check for unused or old keys
- Verify access permissions
- Update security policies
If you discover a security vulnerability in DeepEcho:
- DO NOT open a public issue
- Email the maintainers directly
- Provide detailed information about the vulnerability
- Allow time for the issue to be addressed before public disclosure
Remember: Security is everyone's responsibility. When in doubt, ask for help!