174 lines
4.7 KiB
Markdown
174 lines
4.7 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Supported |
|
|
| ------- | ------------------ |
|
|
| 1.0.x | :white_check_mark: |
|
|
|
|
## Security Features
|
|
|
|
HelmView implements several security measures:
|
|
|
|
### File Upload Security
|
|
- File size limits (100MB default)
|
|
- Extension validation (`.tgz`, `.tar.gz`, `.zip` only)
|
|
- Zip-slip attack protection
|
|
- Safe path traversal checks
|
|
- Sandboxed extraction directories
|
|
|
|
### Execution Security
|
|
- No arbitrary code execution
|
|
- Helm runs only with `template` and `lint` commands
|
|
- No hook execution allowed
|
|
- Command timeouts (60s default)
|
|
- Resource limits in Docker containers
|
|
|
|
### Input Validation
|
|
- YAML syntax validation
|
|
- Kubernetes schema validation
|
|
- API input sanitization
|
|
- SQL injection protection (when using database)
|
|
|
|
### Isolation
|
|
- Per-project sandboxed directories
|
|
- Docker container isolation
|
|
- Temporary file cleanup
|
|
- No network access from Helm commands
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
We take security vulnerabilities seriously. If you discover a security issue, please follow these steps:
|
|
|
|
### DO NOT
|
|
- Open a public GitHub issue
|
|
- Discuss the vulnerability publicly
|
|
- Exploit the vulnerability
|
|
|
|
### DO
|
|
1. **Email**: Send details to security@helmview.io (if available) or create a private security advisory on GitHub
|
|
2. **Include**:
|
|
- Description of the vulnerability
|
|
- Steps to reproduce
|
|
- Potential impact
|
|
- Suggested fix (if any)
|
|
3. **Wait**: Allow up to 48 hours for initial response
|
|
|
|
### What to Expect
|
|
- **Initial Response**: Within 48 hours
|
|
- **Status Update**: Within 7 days
|
|
- **Fix Timeline**: Depends on severity
|
|
- Critical: 1-7 days
|
|
- High: 7-30 days
|
|
- Medium: 30-90 days
|
|
- Low: Next release cycle
|
|
|
|
## Security Best Practices for Deployment
|
|
|
|
### Production Deployment
|
|
1. **Authentication**: Implement user authentication (not included by default)
|
|
2. **HTTPS**: Always use TLS/SSL in production
|
|
3. **Firewall**: Restrict backend access to frontend only
|
|
4. **Secrets**: Use environment variables or secret management
|
|
5. **Updates**: Keep dependencies updated regularly
|
|
6. **Monitoring**: Set up security monitoring and logging
|
|
7. **Backups**: Regular backups of project data
|
|
8. **Resource Limits**: Configure Docker resource limits
|
|
|
|
### Network Security
|
|
```yaml
|
|
# Recommended docker-compose.yml additions
|
|
services:
|
|
backend:
|
|
networks:
|
|
- internal
|
|
frontend:
|
|
networks:
|
|
- internal
|
|
- external
|
|
|
|
networks:
|
|
internal:
|
|
internal: true
|
|
external:
|
|
```
|
|
|
|
### Environment Hardening
|
|
```bash
|
|
# Set restrictive file permissions
|
|
chmod 600 .env
|
|
|
|
# Use non-root user in containers
|
|
# (already implemented in Dockerfiles)
|
|
|
|
# Enable Docker security features
|
|
docker run --security-opt=no-new-privileges --cap-drop=ALL
|
|
```
|
|
|
|
### Rate Limiting
|
|
Consider implementing rate limiting for production:
|
|
- File uploads: 10 per hour per IP
|
|
- API requests: 100 per minute per IP
|
|
- Chart renders: 20 per hour per project
|
|
|
|
### Database Security (when using PostgreSQL)
|
|
- Use strong passwords
|
|
- Enable SSL connections
|
|
- Regular security updates
|
|
- Principle of least privilege for DB users
|
|
- Regular backups with encryption
|
|
|
|
## Known Limitations
|
|
|
|
### Current Security Limitations
|
|
1. **No Authentication**: Users must implement their own auth layer
|
|
2. **No Rate Limiting**: Should be added for production
|
|
3. **No Audit Logging**: Consider adding for compliance
|
|
4. **Shared Resources**: All users share the same backend (multi-tenancy not implemented)
|
|
|
|
### Helm Security Considerations
|
|
- Helm charts may contain malicious templates (mitigated by no hook execution)
|
|
- Large charts may consume significant resources (mitigated by timeouts)
|
|
- Chart dependencies are not validated (user responsibility)
|
|
|
|
## Security Checklist for Production
|
|
|
|
- [ ] Enable HTTPS/TLS
|
|
- [ ] Implement authentication & authorization
|
|
- [ ] Set up rate limiting
|
|
- [ ] Configure firewall rules
|
|
- [ ] Set resource limits
|
|
- [ ] Enable audit logging
|
|
- [ ] Set up monitoring & alerts
|
|
- [ ] Regular security updates
|
|
- [ ] Backup strategy in place
|
|
- [ ] Incident response plan defined
|
|
- [ ] Security review completed
|
|
- [ ] Penetration testing performed
|
|
|
|
## Compliance
|
|
|
|
HelmView does not currently provide built-in compliance features for:
|
|
- HIPAA
|
|
- PCI-DSS
|
|
- SOC 2
|
|
- GDPR (data handling must be implemented separately)
|
|
|
|
Users requiring compliance should implement additional controls.
|
|
|
|
## References
|
|
|
|
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
|
|
- [CWE Top 25](https://cwe.mitre.org/top25/)
|
|
- [Docker Security Best Practices](https://docs.docker.com/develop/security-best-practices/)
|
|
- [Kubernetes Security](https://kubernetes.io/docs/concepts/security/)
|
|
- [Helm Security Considerations](https://helm.sh/docs/topics/rbac/)
|
|
|
|
## License
|
|
|
|
This security policy is part of the HelmView project and follows the same MIT License.
|
|
|
|
---
|
|
|
|
**Last Updated**: January 2026
|