FedDIY/SECURITY.md

Security Policy

Reporting Security Vulnerabilities

FeDIY takes security seriously. If you discover a security vulnerability in the project, we appreciate your help in disclosing it responsibly.

Please do not open a public GitHub issue for security vulnerabilities.

Instead, please report security issues by emailing [security@moturpin.com] with:

• A clear description of the vulnerability
• Steps to reproduce the issue (if possible)
• Potential impact on users and systems
• Any proposed fixes you may have

You can also use GitHub's private vulnerability reporting feature by navigating to the Security tab of the repository and clicking "Report a vulnerability."

What We Commit To

• Acknowledge receipt of your report within 48 hours
• Provide an initial assessment of the vulnerability within 5 business days
• Keep you informed of progress toward a fix
• Publish security advisories for confirmed vulnerabilities, with credit to the reporter (unless you prefer to remain anonymous)
• Work toward a coordinated disclosure timeline with you

Security Expectations

While we work to maintain FeDIY's security, please understand:

• FeDIY is an open source project maintained by volunteers. Response times may vary.
• We follow responsible disclosure practices and expect the same from reporters.
• We ask that you allow us a reasonable time (typically 30-90 days) to release a patch before public disclosure.
• If you'd like to discuss timeline adjustments, please let us know.

Security Best Practices for Users

Running FeDIY

• Keep dependencies updated. Rust dependencies are managed via Cargo. Regularly run cargo update to get security patches.
• Use HTTPS. When deploying FeDIY, use HTTPS for all connections to prevent eavesdropping.
• Secure your database. PostgreSQL (or SQLite) instances should be properly secured with strong authentication and restricted network access.
• Audit access. Regularly review who has administrative access to your FeDIY instance.
• Monitor logs. Watch logs for suspicious activity and configure alerting for authentication failures.

ActivityPub Federation

• FeDIY federates via ActivityPub. Be aware that activities may be shared with other federated instances.
• Instances should enforce their own content policies and block malicious instances if needed.
• User data shared via federation should be treated as public and potentially persistent.

Development Security

Contributors should:

• Review code carefully. Security vulnerabilities can hide in unexpected places. Code review is our first defense.
• Use secure coding practices. Avoid SQL injection, XSS, CSRF, and other common vulnerabilities. See OWASP Top 10 for reference.
• Validate all input. Never trust user input. Always validate and sanitize data before processing.
• Use type safety. Rust's type system prevents many classes of vulnerabilities. Use it effectively.
• Document security decisions. If you make security-related changes, document the reasoning in commit messages or ADRs.

Supported Versions

Version	Status	Security Updates
0.1.x	Alpha	Best effort
Future	TBD	Will be defined

Note: During the early alpha phase (v0.1), security patches may be released ad-hoc. As the project matures, we will establish a formal versioning and patching policy.

Vulnerability Disclosure

When we discover or are notified of a security vulnerability, we will:

1. Confirm the vulnerability and assess its severity
2. Develop and test a fix
3. Coordinate a release with security patches
4. Publish a security advisory with details and credit
5. Acknowledge and thank the reporter

Security Contacts

• Email: security@moturpin.com
• GitHub Security Advisory: Use the "Report a vulnerability" tab in the GitHub repository

Additional Resources

• OWASP Application Security
• Rust Security Guidelines
• CISA Secure Software Development Framework

---

Last Updated: May 2026