π©πͺ Deutsche Version: SECURITY.DE.md
π¬π§ English Version | π©πͺ Deutsche Version
We take the security of our Audiobookshelf Docker image seriously. If you discover a security vulnerability, please help us maintain the security of our project by reporting it responsibly.
DO NOT create a public GitHub issue for security vulnerabilities. Instead, please use one of the following secure channels:
- Go to the Security tab of this repository
- Click "Report a vulnerability"
- Fill out the vulnerability report form with detailed information
- Submit the report
If GitHub Security Advisories are not available, you can email security reports to:
- Email: Create an issue with
[SECURITY]prefix (this will be made private)
When reporting a security vulnerability, please include:
- Vulnerability Type: (e.g., SQL Injection, XSS, Authentication Bypass, etc.)
- Affected Component: Specify which part of the system is affected
- Docker image/container
- S6 services
- Configuration files
- Build process
- Dependencies
- Attack Vector: How the vulnerability can be exploited
- Impact: What an attacker could achieve
- Proof of Concept: Steps to reproduce (if safe to do so)
- Suggested Fix: If you have ideas for remediation
- Environment Details:
- Docker image version
- Host operating system
- Container runtime version
This security policy covers vulnerabilities in:
- Docker Image Security
- Container escape vulnerabilities
- Privilege escalation issues
- Insecure default configurations
- Application Security
- Authentication/authorization flaws
- Input validation issues
- Secret exposure
- Build Process Security
- Supply chain attacks
- Malicious dependencies
- Insecure build configurations
- S6 Overlay Services
- Service configuration vulnerabilities
- Inter-service communication issues
- LinuxServer.io Compliance
- FILE__ prefix security issues
- Docker Mods vulnerabilities
- Custom script injection
- Upstream Audiobookshelf Application
- Please report to the official Audiobookshelf repository
- LinuxServer.io Base Image
- Please report to LinuxServer.io
- Third-party Dependencies
- Report directly to the respective maintainers
- Infrastructure Issues
- Host system vulnerabilities
- Network configuration issues
- Registry/distribution vulnerabilities
We aim to respond to security reports according to the following timeline:
| Severity | Initial Response | Investigation | Resolution |
|---|---|---|---|
| Critical | Within 24 hours | Within 72 hours | Within 7 days |
| High | Within 48 hours | Within 5 days | Within 14 days |
| Medium | Within 72 hours | Within 10 days | Within 30 days |
| Low | Within 1 week | Within 2 weeks | Next minor release |
Our Docker image implements several security measures:
- Non-root execution - Runs as user
abc(UID 911) - Capability dropping - ALL capabilities dropped, minimal required added
- Security hardening -
no-new-privileges, security-opt configurations - Read-only filesystem - Where possible with tmpfs for temporary files
- UMASK enforcement - Proper file permissions (750/640)
- LinuxServer.io FILE__ prefix - Secure secret handling
- 512-bit JWT secrets - Strong cryptographic keys
- Path validation - Prevents path traversal attacks
- Automatic rotation - Built-in secret rotation capabilities
- Multi-stage builds - Minimal attack surface
- Dependency scanning - Automated vulnerability scanning with Trivy
- SBOM generation - Software Bill of Materials for transparency
- Provenance attestation - Build integrity verification
- Base image verification - Official LinuxServer.io Alpine base
- Dependency pinning - Specific versions to prevent drift
- Automated updates - Dependabot for security updates
- CI/CD security - Signed commits and protected workflows
We believe in recognizing security researchers who help improve our project's security:
- Acknowledgment - We will publicly acknowledge your contribution (with your permission)
- Hall of Fame - Recognition in our security hall of fame
- Priority Support - Fast-track support for your issues and questions
- Follow our LinuxServer.io Compliance Guide
- Use recommended environment variables
- Implement best practices from our documentation
- Container Scanning:
make security-scan(Trivy) - Dockerfile Linting:
make validate(Hadolint) - Environment Validation:
make env-validate - Health Monitoring:
make status
We regularly update our security measures:
- Monthly Reviews - Regular security assessment of dependencies
- Automated Scanning - Continuous vulnerability monitoring
- Patch Management - Rapid deployment of security fixes
- Documentation Updates - Keep security guidelines current
For non-security related issues:
- General Issues: GitHub Issues
- Questions: GitHub Discussions
- Documentation: README.md
- We will not pursue legal action against security researchers who follow this policy
- We ask that you do not publicly disclose vulnerabilities until we have had a chance to address them
- Please act in good faith and avoid privacy violations, data destruction, or service disruption
Last Updated: September 2025 Policy Version: 1.0 Next Review: June 2026