🇩🇪 Deutsche Version: SECURITY.DE.md
🇬🇧 English Version | 📖 Deutsche Version
This document outlines the security policies, practices, and vulnerability reporting procedures for the Tandoor Recipes Docker image.
This container implements comprehensive security hardening based on LinuxServer.io standards with additional enhancements for production environments.
- Base Security: LinuxServer.io Alpine 3.22 with S6 Overlay v3
- Application Security: Django/Python security best practices
- Container Security: Enhanced hardening with capability dropping
- Network Security: Configurable network isolation
- Data Security: Encrypted secrets management
- ✅ Non-root execution - All processes run as user
abc(UID 911) - ✅ Capability dropping - All capabilities dropped, minimal set added back
- ✅ No new privileges - Prevents privilege escalation
- ✅ Read-only root filesystem - Where possible
- ✅ SecComp profiles - System call filtering
- ✅ AppArmor integration - Additional access control
# Automatic security hardening (docker-compose.override.yml)
security_opt:
- no-new-privileges:true
- apparmor=docker-default
cap_drop:
- ALL
cap_add:
- CHOWN
- DAC_OVERRIDE
- FOWNER
- SETGID
- SETUIDdeploy:
resources:
limits:
cpus: '2.0'
memory: 1G
pids: 200Secure secret management using LinuxServer.io FILE__ prefix standard:
# Environment variables pointing to secret files
FILE__SECRET_KEY=/run/secrets/tandoor_secret_key
FILE__POSTGRES_PASSWORD=/run/secrets/tandoor_postgres_password
FILE__POSTGRES_USER=/run/secrets/tandoor_postgres_usersecrets:
tandoor_secret_key:
file: ./secrets/tandoor_secret_key.txt
tandoor_postgres_password:
file: ./secrets/tandoor_postgres_password.txt
services:
tandoor:
secrets:
- tandoor_secret_key
- tandoor_postgres_passwordThe project includes automatic secure secret generation:
# Generate secure secrets
make secrets-generate
# View secret status
make secrets-info
# Rotate secrets
make secrets-rotateSecret Specifications:
- Django SECRET_KEY: 512-bit cryptographically secure random string
- Database passwords: 256-bit secure random strings
- API keys: 256-bit secure tokens
- Storage: Proper file permissions (600) and ownership
# Secure localhost-only binding (recommended)
ports:
- "127.0.0.1:8080:8080"
# Alternative: specific interface binding
ports:
- "192.168.1.100:8080:8080"# Custom bridge network for service isolation
networks:
tandoor-network:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/16- ✅ DEBUG=False in production
- ✅ Secure cookie settings (HTTPS only)
- ✅ CSRF protection enabled
- ✅ Content Security Policy headers
- ✅ XSS protection headers
- ✅ Clickjacking protection
- ✅ Encrypted connections to PostgreSQL
- ✅ Credential isolation using secrets
- ✅ Database user privileges minimal required permissions
- ✅ Connection pooling with secure configurations
The project includes comprehensive security scanning:
# Run all security scans
make security-scan
# Individual scan tools
make trivy-scan # Container vulnerability scanning
make codeql-scan # Static code analysis- GitHub Actions: Automated security scans on every push
- Trivy: Container and filesystem vulnerability detection
- CodeQL: Static code analysis for security issues
- Hadolint: Dockerfile security best practices
- Critical: Immediate patching within 24 hours
- High: Patching within 7 days
- Medium: Regular maintenance cycle (monthly)
- Low: Next major version
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=5 \
CMD ps aux | grep -v grep | grep "gunicorn" || exit 1- Security events: Authentication, authorization failures
- Application logs: Error tracking and monitoring
- Container logs: System-level security events
- Audit logs: File access and permission changes
We provide security updates for the following versions:
| Version | Supported |
|---|---|
| 1.5.x | ✅ Yes |
| 1.4.x | |
| < 1.4 | ❌ No |
For security vulnerabilities, please DO NOT open a public issue.
- Go to the Security tab of this repository
- Click "Report a vulnerability"
- Fill out the security advisory form with detailed information
Send vulnerability reports to: security@mildman1848.dev
- Description: Clear description of the vulnerability
- Impact: Potential security impact and affected components
- Reproduction: Step-by-step instructions to reproduce
- Environment: Container version, configuration details
- Suggested Fix: If you have ideas for remediation
- Acknowledgment: Within 48 hours
- Initial Assessment: Within 7 days
- Status Updates: Weekly until resolved
- Resolution: Target 30 days for critical issues
- Report Received: Security team acknowledges receipt
- Vulnerability Assessment: Impact and severity evaluation
- Fix Development: Patch development and testing
- Coordinated Disclosure: Public advisory after fix is available
- Security Update: New container image with fix released
# Use production security configuration
docker-compose -f docker-compose.yml -f docker-compose.production.yml up -d- ✅ Use specific image tags, not
latest - ✅ Implement network segmentation
- ✅ Enable audit logging
- ✅ Regular security updates
- ✅ Monitor container behavior
- ✅ Principle of least privilege: Minimal required permissions
- ✅ Role-based access: Django user roles and permissions
- ✅ Strong authentication: Complex passwords and 2FA where possible
- ✅ Regular access review: Periodic user and permission audits
- Never commit secrets to version control
- Use FILE__ prefix for Docker secrets
- Rotate secrets regularly (90-day cycle recommended)
- Monitor secret access and usage
- Backup secrets securely with encryption
- Use dedicated database user with minimal privileges
- Enable connection encryption (SSL/TLS)
- Regular database backups with encryption
- Database access monitoring
- Keep PostgreSQL updated to latest secure version
- Review and customize
.envconfiguration - Generate secure secrets with
make secrets-generate - Configure network security (port binding, firewall)
- Enable production security hardening
- Set up monitoring and alerting
- Review user access and permissions
- Update container images monthly
- Rotate secrets quarterly
- Review access logs monthly
- Update dependencies regularly
- Perform security scans weekly
- Backup configurations and data
- Monitor security alerts
- Have incident response plan
- Know how to isolate compromised containers
- Maintain forensic logging
- Test disaster recovery procedures
- Trivy - Vulnerability scanner
- Docker Bench - Security auditing
- Hadolint - Dockerfile linting
- ✅ CIS Docker Benchmark: Container security guidelines
- ✅ NIST Cybersecurity Framework: Security controls implementation
- ✅ OWASP Top 10: Web application security risks mitigation
- ✅ LinuxServer.io Standards: Container best practices
This security policy is released under the same AGPL-3.0 license as the project.
Last Updated: September 2025 Next Review: December 2025
For questions about this security policy, please open a discussion or contact the maintainers.