Audit this repository to determine whether the application is safe and trustworthy to self-host. Do not modify any code.
Examine the actual implementation, dependencies, configuration, and deployment files. Focus on:
- External communication: Identify all outbound connections, telemetry, analytics, update checks, and data sent to third parties. Flag anything unexpected or undocumented.
- Security: Look for vulnerabilities, insecure defaults, hardcoded secrets, weak authentication, exposed endpoints, and unsafe handling of sensitive data.
- Data privacy: Determine what data the application collects, stores, transmits, and logs. Identify where sensitive data could leak.
- Dependencies & supply chain: Check for suspicious, outdated, or vulnerable dependencies, installation scripts, container images, and build-time downloads.
- Deployment safety: Review Docker/Compose files, environment variables, exposed ports, privileges, filesystem mounts, and other relevant deployment settings.
- Application-specific risks: Identify additional risks based on what the application actually does (e.g., database access, backups, file management, remote execution, or public APIs).
Adapt the audit to the intended deployment. Internal-only applications should still be checked for data exfiltration, lateral movement, and excessive privileges. Public-facing applications require additional scrutiny of authentication, authorization, input validation, and network exposure.
For every finding, provide a severity (Critical/High/Medium/Low), a brief explanation, and exact file/line references. Distinguish confirmed issues from potential risks, and never claim something is safe without evidence.
Finish with:
- Verdict: Safe to deploy / Safe with precautions / Not recommended
- Top risks: The most important findings, prioritized.
- Before deployment: Specific, actionable mitigations.
- External connections: A concise list of destinations, purposes, and data transmitted.
Keep the report concise and practical. Do not make changes or run untrusted installation scripts. If something cannot be verified through static inspection, explicitly say so.
- Application purpose: [What the application does]
- Deployment: [Internal-only / Public-facing / Both]
- Environment: [Docker / VM / Bare metal / Kubernetes]
- Sensitive data or permissions: [e.g., database credentials, production backups, SSH keys, host filesystem access]
- Additional concerns: [Optional specific things to investigate]