Gold Digger follows semantic versioning. Security updates are provided for the following versions:

We take security vulnerabilities seriously. Please report any security issues you discover.

1. Go to the Security tab
2. Click "Report a vulnerability"
3. Fill out the security report form
4. Provide detailed information about the vulnerability

• Email: support@evilbitlabs.io (for urgent or highly sensitive issues)
• GitHub Issue: Use the Security Report template (public disclosure - redact sensitive details)

When reporting a vulnerability, please provide:

• Description: Clear explanation of the security issue
• Severity: Critical, High, Medium, or Low impact
• Steps to Reproduce: Detailed reproduction steps
• Proof of Concept: Minimal code demonstrating the issue (redact sensitive data)
• Affected Versions: Which versions are vulnerable
• Environment: OS, architecture, enabled features
• Impact Assessment: Potential consequences

As a single maintainer project:

• Critical/High: 24-48 hours initial response
• Medium: 3-5 business days
• Low: 1-2 weeks

Security issues are prioritized over feature development.

• Credential Protection: Database URLs and credentials are never logged
• TLS Support: Secure database connections with native TLS or rustls
• Connection Validation: Proper error handling for connection failures
• No Credential Storage: Credentials are only read from environment variables

• SQL Injection Prevention: Uses parameterized queries via mysql crate
• Environment Variable Validation: Validates required configuration
• File Path Sanitization: Validates output file paths

• File Permissions: Respects system umask for output files
• No Sensitive Data in Output: Database credentials are never included in results
• Structured Output: Safe CSV, JSON, and TSV generation

Some CLI flags and features carry security-relevant trade-offs. Operators must understand these before deploying Gold Digger in production environments or handing the binary to non-experts.

This flag disables both the certificate chain and hostname checks performed by rustls. Any network attacker able to intercept the TCP connection can present an attacker-controlled certificate, complete the TLS handshake, and read or modify the database protocol — including plaintext credentials.

• Never use --allow-invalid-certificate against a production database.
• Prefer --tls-ca-file <path> for self-signed CAs — this keeps full chain and hostname validation against an explicitly trusted anchor.
• Prefer --insecure-skip-hostname-verify when only the hostname presented in the certificate does not match — chain validation still runs and the time-window check still applies.
• The flag is intentionally not gated by an interactive prompt; treat its presence in any deployment manifest, CI workflow, or shell history as an incident that requires rotating the affected DB credentials.

--query-file reads any file readable by the Gold Digger process. Path-safety guards landed with todo #023 and limit — but do not eliminate — the risk:

• Canonicalisation. The path is passed through std::fs::canonicalize before the file is opened. .. is resolved and symlinks are collapsed, so the extension / size checks below apply to the true target, not the link.
• Extension deny-list. Paths ending in .exe, .dll, .so, .dylib, .bin, .bat, .cmd, .com (case-insensitive) are refused with a configuration error. Paths with .sql, .txt, or no extension are accepted.
• Size cap. Files larger than 10 MiB are refused to cap DoS / memory blow-up risk.

Residual risks remain: running Gold Digger as root or under a service account with broad filesystem access still lets an attacker who can choose the path read arbitrary .sql / .txt files (other tenants' SQL, anything with a matching extension). Treat --query-file paths supplied from outside the trust boundary (webhook payloads, CI parameters from forks) as untrusted:

• Store query files in a dedicated, restricted directory owned by the Gold Digger user and audit who can write to that directory.
• Do not pass user-supplied paths to --query-file from outside the trust boundary.

Path-safety guards on the output path landed with todo #024:

• Refuse-existing by default. Gold Digger opens the output with O_CREAT | O_EXCL semantics (Unix: OpenOptions::create_new; Windows: the equivalent fallback). A pre-existing file at the target path is a hard error with a message prompting the operator to pass --force. This blocks the "accidental clobber" footgun and the TOCTOU race where an attacker pre-plants a file at a predictable path.
• Refuse symlinks (Unix). The output file is opened with O_NOFOLLOW, so a symlink at the target — attacker-placed or otherwise — is refused regardless of --force. This closes the classic "symlink at /tmp/results.json" redirect attack.
• 0o600 permissions (Unix). Created files are owner read/write only. Query results often contain sensitive data; the previous default of honouring the umask could leave world-readable files behind.
• --force opts into overwrite. Explicit overwrite still refuses symlinks (O_NOFOLLOW) and preserves the 0o600 mode.

--dump-config prints the resolved configuration as JSON, with a best-effort credential redactor applied to URLs and known secret keys. The redactor pattern set is finite — it does not catch arbitrary encodings (base64, hex, JWT) or non-English secret labels. Treat any --dump-config output as probably-safe but not certified-safe when attaching it to bug reports or pasting it into chat.

• Skim the JSON for tokens, API keys, base64 blobs, or labels in languages your eye does not parse before sharing externally.
• Tracked improvements: repo todos #004 (route through the canonical redact_sql_error), #029 (adversarial test corpus).

1. Use Environment Variables: Store database credentials in environment variables, not in scripts
2. Enable TLS: Use mysql:// URLs with SSL parameters for encrypted connections
3. Limit Permissions: Use database users with minimal required permissions
4. Secure Output: Store output files in secure locations with appropriate permissions
5. Regular Updates: Keep Gold Digger updated to the latest version

1. Security Reviews: All code changes undergo security review
2. Dependency Scanning: Regular vulnerability scanning with cargo audit
3. Secure Defaults: Security-focused default configurations
4. Error Handling: No sensitive information in error messages
5. Input Validation: Validate all external inputs

• CodeQL Analysis: Automated security scanning via GitHub Actions
• Dependency Scanning: Regular vulnerability checks with Dependabot
• Cargo Audit: Rust dependency vulnerability scanning
• SBOM Generation: Software Bill of Materials for supply chain security

• Code Reviews: All changes reviewed for security implications
• Penetration Testing: Periodic security testing of the application
• Configuration Audits: Regular review of security configurations

1. Private Reporting: Security issues are reported privately first
2. Coordinated Disclosure: Vulnerabilities are disclosed after fixes are available
3. CVE Assignment: Critical and high-severity issues receive CVE assignments
4. Public Disclosure: Security advisories published with fix details

• Discovery: Vulnerability is discovered and reported
• Assessment: Issue is assessed and severity determined
• Fix Development: Security fix is developed and tested
• Release: Fixed version is released
• Disclosure: Public disclosure with security advisory

• Maintainer: UncleSp1d3r
• GitHub: @unclesp1d3r
• Email: unclesp1d3r@evilbitlabs.io

This is a single-maintainer project. All security issues are handled by the primary maintainer.

We appreciate security researchers who responsibly disclose vulnerabilities. Contributors to security improvements will be acknowledged in:

• Release notes
• Security advisories
• Project documentation

• GitHub Security Policy
• Rust Security WG
• OWASP Top 10
• CVE Database

This security policy is part of the Gold Digger project and is licensed under the MIT License.