Fuse takes security seriously. This document outlines our security practices, how to report vulnerabilities, and guidelines for secure development.
Instead, please report them via one of the following methods:
- Email: security@fuse-project.io (preferred)
- GitHub Security Advisory: Use the "Security" tab in the repository
- Private Message: Contact maintainers directly
When reporting a vulnerability, please include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
- Your contact information
- Initial Response: Within 24 hours
- Status Update: Within 72 hours
- Fix Timeline: Depends on severity
- Critical: 1-7 days
- High: 7-14 days
- Medium: 14-30 days
- Low: 30-90 days
Fuse includes comprehensive pre-commit hooks that prevent:
- β Hardcoded credentials (API keys, passwords, tokens)
- β Private keys and certificates
- β AWS credentials
- β Database connection strings
- β Sensitive configuration data
- β Large files (models, binaries)
- β Insecure file permissions
DO:
- β Use environment variables for sensitive data
- β Use secret management tools (Vault, AWS Secrets Manager)
- β
Store credentials in
.gitignored files - β Use placeholder values in example configs
- β Rotate credentials regularly
DON'T:
- β Hardcode credentials in source code
- β Commit real API keys or tokens
- β Store passwords in configuration files
- β Share credentials in chat or email
- β Use weak or default passwords
Example secure configuration:
# β
GOOD - Using environment variables
[auth]
api_key = "${FUSE_API_KEY}"
secret = "${FUSE_SECRET}"
huggingface_token = "${HF_TOKEN}"
# β BAD - Hardcoded credentials
[auth]
api_key = "sk-abc123xyz789" # Never do this!Sensitive files should have restricted permissions:
# Private keys and secrets
chmod 600 ~/.fuse/config.toml
chmod 600 ~/.ssh/id_rsa
# Configuration files
chmod 644 config.example.toml
# Executables
chmod 755 scripts/*.sh-
Code Review
- All code changes require review
- Security-sensitive changes require security team review
- Use GitHub's code scanning tools
-
Dependency Management
- Run
cargo auditregularly - Keep dependencies up to date
- Review dependency licenses
- Use
cargo-denyfor policy enforcement
- Run
-
Input Validation
- Validate all user inputs
- Sanitize data before processing
- Use type-safe parsing
- Implement rate limiting
-
Error Handling
- Don't expose sensitive information in errors
- Log errors securely
- Use structured error types
- Implement proper error boundaries
-
Testing
- Write security tests
- Test authentication and authorization
- Test input validation
- Perform fuzz testing
-
Installation
- Download from official sources only
- Verify checksums and signatures
- Use official Docker images
- Keep Fuse updated
-
Configuration
- Use strong passwords
- Enable TLS/SSL
- Configure rate limiting
- Enable audit logging
-
Model Security
- Scan models for vulnerabilities
- Verify model sources
- Use trusted registries
- Implement access controls
-
Network Security
- Use firewalls
- Restrict network access
- Use VPNs for remote access
- Enable HTTPS only
- No hardcoded credentials
- No sensitive data in code
- No debug prints with sensitive info
- Configuration uses environment variables
- Tests don't contain real credentials
- Documentation doesn't expose secrets
- Pre-commit hooks pass
- All dependencies audited
- Security scan completed
- TLS/SSL configured
- Authentication enabled
- Rate limiting configured
- Logging configured
- Backups configured
- Monitoring enabled
- Update dependencies monthly
- Rotate credentials quarterly
- Review access logs weekly
- Scan for vulnerabilities weekly
- Update security policies annually
- Conduct security training annually
Fuse follows industry security standards:
- OWASP Top 10: Protection against common vulnerabilities
- CIS Benchmarks: Secure configuration guidelines
- NIST Guidelines: Cryptography and key management
- GDPR: Data protection and privacy (where applicable)
- SOC 2: Security controls and practices
- cargo-audit: Dependency vulnerability scanning
- detect-secrets: Secret detection in code
- gitleaks: Credential scanning
- Trivy: Container and model scanning
- clippy: Rust linting with security checks
- Vault: Secret management
- SOPS: Encrypted configuration
- Falco: Runtime security monitoring
- Cilium: Network security policies
- OPA: Policy enforcement
- Stop: Don't commit or push
- Assess: Determine severity and impact
- Report: Follow reporting guidelines above
- Document: Record all details
- Remediate: Work with team to fix
-
Immediate Actions:
- Revoke exposed credentials immediately
- Rotate all related credentials
- Check access logs for unauthorized use
- Notify security team
-
Investigation:
- Determine scope of exposure
- Identify affected systems
- Review audit logs
- Document timeline
-
Remediation:
- Remove credentials from repository history
- Update security policies
- Implement additional controls
- Conduct post-mortem
If credentials were committed:
# Remove file from history
git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch path/to/file" \
--prune-empty --tag-name-filter cat -- --all
# Force push (coordinate with team)
git push origin --force --all
git push origin --force --tags
# Clean up local repository
git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin
git reflog expire --expire=now --all
git gc --prune=now --aggressiveNote: This rewrites history. Coordinate with your team and ensure everyone updates their local repositories.
- GitHub Security Advisories: Automatic notifications
- Mailing List: security-announce@fuse-project.io
- RSS Feed: https://fuse-project.io/security.xml
- Twitter: @FuseSecurity
- Critical: Immediate patch release
- High: Patch within 7 days
- Medium: Patch in next minor release
- Low: Patch in next major release
- Security Team: security@fuse-project.io
- General Issues: https://github.com/fuse/fuse/issues
- Documentation: https://docs.fuse-project.io/security
We thank the security researchers and community members who help keep Fuse secure. Responsible disclosure is appreciated and will be acknowledged in our security advisories.
This security policy is licensed under CC BY 4.0.
Last Updated: 2024-01-01
Version: 1.0.0