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

Ferrix includes the following security features:

• Bcrypt Password Hashing - Passwords hashed with bcrypt (DEFAULT_COST)
• Rate Limiting - 5 failed authentication attempts trigger 15-minute lockout
• Role-Based Access Control - Permission system for multi-user environments
• Session Locking - Read-only mode for secure session viewing

• TLS 1.3 Support - Secure remote connections using rustls
• Certificate Validation - Proper TLS certificate verification
• Configurable TLS - Optional TLS for local-only deployments

• Dependency Auditing - Regular security audits with cargo audit
• Safe Rust - 100% safe Rust code (no unsafe blocks)
• Input Validation - Sanitized user input throughout the codebase
• Secure Defaults - Security-first default configuration

Ferrix has undergone comprehensive security audits. For detailed information:

• SECURITY_AUDIT.md - Code security analysis and hardening measures
• DEPENDENCY_AUDIT.md - Dependency security status and mitigation strategies
• docs/DEPLOYMENT.md - Production deployment security best practices

Last Audit: 2025-10-05 (v0.11.0) Status: ✅ All critical vulnerabilities addressed

We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.

DO NOT create a public GitHub issue for security vulnerabilities.

Instead, please email security reports to:

Email: david@davidcanhelp.me

Subject: [SECURITY] Ferrix Vulnerability Report

Please include the following information in your report:

1. Description - Clear description of the vulnerability
2. Impact - What an attacker could achieve
3. Steps to Reproduce - Detailed reproduction steps
4. Affected Versions - Which versions are affected
5. Suggested Fix - If you have ideas for mitigation (optional)
6. Proof of Concept - Code or commands demonstrating the issue (if applicable)

We aim to respond to security reports according to the following timeline:

• Initial Response: Within 48 hours
• Severity Assessment: Within 7 days
• Fix Development: Depends on severity
  • Critical: Emergency patch within 7 days
  • High: Patch within 30 days
  • Medium: Patch in next minor release
  • Low: Addressed in roadmap planning

We follow coordinated disclosure:

1. You report the vulnerability privately
2. We acknowledge receipt and assess severity
3. We develop and test a fix
4. We release a security patch
5. We publish a security advisory
6. You may publicly disclose after patch release (we appreciate 7 days notice)

Ferrix is currently an open-source project without a formal bug bounty program. However:

• We deeply appreciate security researchers' efforts
• We will publicly acknowledge your contribution (if desired)
• We may offer swag/stickers as tokens of appreciation
• Critical findings will be prominently credited in release notes

The following security enhancements are planned for future releases:

P1 - Planned for v1.1.0:

• Certificate/key file permission validation
• Comprehensive audit logging system
• Session idle timeouts
• mTLS (mutual TLS) configuration option

P2 - Planned for v2.0.0:

• Encrypted user database at rest
• Zeroizing for password handling in memory
• Default least-privilege permissions
• Advanced authorization action identifiers

See V1_RELEASE_CHECKLIST.md for detailed planning.

Ferrix dependencies are regularly audited. See DEPENDENCY_AUDIT.md for:

• Current security advisories status
• Mitigation strategies for known issues
• Upgrade roadmap for vulnerable dependencies

Note: The battery feature (system battery monitoring) is optional and disabled by default due to a dependency vulnerability. Do not enable this feature in security-sensitive environments until v1.1.0.

For production deployments, please follow these security best practices:

• Run ferrix server as non-root user
• Set proper file permissions (0700 for directories, 0600 for files)
• Use systemd user services (not system services) when possible
• Isolate ferrix data directory (~/.ferrix/)

• Always use TLS for remote connections
• Use strong certificates (Let's Encrypt or properly signed certs)
• Configure firewall rules (allow only necessary IPs)
• Enable authentication with strong passwords
• Consider VPN instead of exposing ferrix directly to internet

• Review default configuration before deployment
• Disable features you don't need
• Use strong authentication passwords
• Set appropriate session timeouts
• Enable audit logging (when available in v1.1.0)

See docs/DEPLOYMENT.md for comprehensive deployment security guidance.

We appreciate security researchers who help make Ferrix more secure:

No security reports yet - be the first!

• GitHub Security Advisories
• Changelog - Security fixes documented in release notes
• Contributing Guidelines - Contribution process including security reviews

If you have questions about Ferrix security that are not vulnerability reports:

• Open a GitHub Discussion
• Check docs/DEPLOYMENT.md for deployment security guidance
• Read SECURITY_AUDIT.md for detailed security analysis

Last Updated: 2025-10-05 Version: 0.11.0