We take the security of NOFX seriously. This document outlines our security policy and procedures for reporting vulnerabilities.
We release patches for security vulnerabilities. Which versions are eligible for receiving such patches depends on the CVSS v3.0 Rating:
| Version | Supported | Status |
|---|---|---|
| 3.x.x | β Yes | Active development |
| 2.x.x | Security fixes only | |
| < 2.0 | β No | No longer supported |
Please do not report security vulnerabilities through public GitHub issues.
If you discover a security vulnerability, please follow these steps:
Send an email to the security team at:
- Email: tinklefund@gmail.com (or contact maintainers directly via Twitter DM)
- Twitter: @nofx_official or @Web3Tinkle
Please include the following details in your report:
- Description: A clear description of the vulnerability
- Impact: The potential impact of the vulnerability
- Steps to Reproduce: Detailed steps to reproduce the issue
- Proof of Concept: If applicable, include PoC code or screenshots
- Suggested Fix: If you have ideas on how to fix it
- Your Contact Information: For follow-up questions
- Initial Response: Within 48 hours of receiving your report
- Status Update: Weekly updates on the progress
- Fix Timeline: Critical issues within 7 days, others within 30 days
- Public Disclosure: After the fix is deployed (coordinated disclosure)
After you submit a report:
- β We will acknowledge receipt of your report
- π We will investigate and validate the issue
- π We will develop and test a fix
- π We will deploy the fix to production
- π’ We will coordinate public disclosure with you
- π We will credit you in the security advisory (if desired)
If you're using NOFX, please follow these security best practices:
- β Never commit API keys, private keys, or secrets to version control
- β Use environment variables for all sensitive configuration
- β Rotate keys regularly (at least every 90 days)
- β Use separate keys for different environments (dev/staging/prod)
- β Implement IP whitelisting for exchange API keys
- β Enable 2FA on all exchange accounts
- β Never share your private keys with anyone
- β Use dedicated wallets for trading (not your main wallet)
- β Use agent wallets when available (Hyperliquid)
- β Limit wallet funds to amounts you can afford to lose
- β Back up keys securely using encrypted storage
- β Enable API key restrictions (IP whitelist, permissions)
- β Use read-only keys for monitoring when possible
- β Set withdrawal restrictions on exchange accounts
- β Monitor API usage for unusual activity
- β Revoke compromised keys immediately
- β
Keep dependencies updated (run
npm auditandgo mod tidy) - β Use HTTPS for all external communications
- β Implement rate limiting on API endpoints
- β Enable authentication on production deployments
- β Review logs regularly for suspicious activity
- β Use Docker for isolated environments
- β Encrypt sensitive data at rest (API keys, private keys)
- β Restrict database access (not exposed to internet)
- β Back up regularly with encrypted backups
- β Use strong passwords for database credentials
- β Never use default passwords or weak credentials
- β Change default ports if exposed to internet
- β Disable unnecessary features in production
- β Use firewall rules to restrict access
- β Implement RBAC for multi-user setups
The following are not considered security vulnerabilities:
- β Trading losses due to AI decisions
- β Exchange API rate limiting
- β Network latency issues
- β Market volatility impacts
- β Social engineering attacks
- β DDoS attacks on public infrastructure
- β Issues in third-party dependencies (report to upstream)
- β Already known and documented limitations
We appreciate the security research community's efforts. Contributors who responsibly disclose vulnerabilities will be:
- β Credited in security advisories (with permission)
- β Listed in our Hall of Fame (coming soon)
- β Eligible for bug bounties (when program launches)
- Code Scanning: GitHub Advanced Security (enabled)
- Dependency Scanning: Dependabot (enabled)
- Secret Scanning: GitHub Secret Scanning (enabled)
- Container Scanning: Docker Scout (recommended)
NOFX uses the following security measures:
- AES-256 encryption for sensitive data at rest (planned v3.1)
- TLS 1.3 for all network communications
- JWT tokens for API authentication
- bcrypt for password hashing (where applicable)
- Environment isolation via Docker containers
| Date | Version | Auditor | Report |
|---|---|---|---|
| TBD | 3.0.0 | Internal | Initial security review |
We follow a coordinated disclosure approach:
- π§ Report received and acknowledged
- π Investigation and validation (1-7 days)
- π οΈ Fix development and testing (7-30 days)
- π Fix deployment to production
- π’ Public advisory published (after fix)
- π Credit to researcher (if desired)
Please allow us time to fix critical issues before public disclosure.
For security concerns, reach out via:
- Email: Contact maintainers (see GitHub profile)
- Twitter: @nofx_official (DM open)
- Telegram: NOFX Developer Community
- GitHub: Private security advisory (preferred for verified issues)
Safe Harbor: We consider security research conducted under this policy to be:
- β Authorized in accordance with applicable law
- β Lawful and in good faith
- β Exempt from DMCA and CFAA claims
- β Protected from legal action by the project
Conditions:
- Make a good faith effort to avoid privacy violations
- Do not access or modify other users' data
- Do not disrupt our services or infrastructure
- Do not publicly disclose issues before we've had time to address them
This security policy may be updated from time to time. We will notify users of significant changes via:
- GitHub release notes
- Security advisories
- Community channels (Telegram, Twitter)
Last Updated: January 2025 Version: 1.0.0
Thank you for helping keep NOFX and its users safe! π