gru_emoney_token-factory/SECURITY.md

Security Policy

Supported Versions

We currently support the following versions with security updates:

Version	Supported
1.0.x	✅

Security Contact

For security issues, please contact the security team at: security@example.com

DO NOT create a public GitHub issue for security vulnerabilities.

Vulnerability Disclosure Process

We take the security of the eMoney Token Factory system seriously. If you discover a security vulnerability, we appreciate your help in disclosing it to us responsibly.

Reporting a Vulnerability

1. Email us at security@example.com with:

   • A clear description of the vulnerability
   • Steps to reproduce the issue
   • Potential impact assessment
   • Suggested fix (if available)

2. Response Timeline:

   • We will acknowledge receipt within 48 hours
   • Initial assessment within 7 days
   • We will keep you informed of the progress
   • Target resolution timeline: 30 days (may vary based on severity)

3. What to Expect:

   • Confirmation of the vulnerability
   • Regular updates on remediation progress
   • Credit in security advisories (if desired)
   • Notification when the issue is resolved

Out of Scope

The following are considered out of scope for security vulnerability reporting:

• Issues in test contracts
• Issues in dependencies (report to the dependency maintainers)
• Denial of service attacks requiring significant capital
• Frontend/UI bugs that don't affect on-chain security
• Issues requiring social engineering or physical access

Security Best Practices

For Deployers

1. Private Key Security:

   • Never commit private keys to version control
   • Use hardware wallets for production deployments
   • Rotate keys regularly
   • Use dedicated deployment wallets with minimal funds

2. Access Control:

   • Use multisig wallets for admin roles in production
   • Implement timelock for critical operations
   • Regularly audit role assignments
   • Follow principle of least privilege

3. Configuration:

   • Validate all contract addresses before deployment
   • Verify registry configurations before going live
   • Test all upgrade procedures on testnets first
   • Document all configuration decisions

For Token Issuers

1. Compliance Management:

   • Regularly update compliance statuses
   • Monitor for frozen accounts
   • Implement automated compliance checks where possible

2. Lien Management:

   • Document all lien placements and releases
   • Verify lien amounts before placing
   • Use appropriate reason codes
   • Monitor active encumbrances

3. Policy Configuration:

   • Understand lien modes before enabling
   • Test policy changes on testnets
   • Document policy rationale

For Developers

1. Code Security:

   • Follow Solidity best practices
   • Use formal verification where applicable
   • Conduct thorough testing (unit, integration, fuzz)
   • Review all external dependencies

2. Upgrade Safety:

   • Test upgrades extensively before deployment
   • Maintain upgrade documentation
   • Verify storage layout compatibility
   • Use upgrade safety checks

Known Limitations

1. Light Client Verification: The BridgeVault138 contract includes placeholder light client verification. In production, implement a proper light client verification system.

2. Lien Expiry: Liens use a "hard expiry" policy where expiry is informational only. Liens must be explicitly released by DEBT_AUTHORITY_ROLE.

3. Upgrade Authorization: Only DEFAULT_ADMIN_ROLE can authorize upgrades. In production, consider using a timelock or multisig.

4. No Rate Limiting: The system does not include built-in rate limiting. Implement at the application layer if needed.

5. Compliance Registry: The compliance registry does not automatically update. Manual intervention is required for compliance changes.

Audit Status

Completed Audits

• Initial Audit: Pending
  • Auditor: TBD
  • Date: TBD
  • Report: TBD

Pending Audits

• Formal verification of lien enforcement logic
• Bridge security audit (pending light client implementation)
• Upgrade safety audit

Bug Bounty

We currently do not operate a formal bug bounty program. However, we appreciate responsible disclosure and may offer rewards at our discretion for critical vulnerabilities.

Security Considerations

Architecture Security

• Separation of Concerns: Core functionality is separated into distinct contracts (ComplianceRegistry, DebtRegistry, PolicyManager)
• Role-Based Access Control: All privileged operations use OpenZeppelin's AccessControl
• Upgradeability: UUPS proxy pattern allows upgrades while maintaining upgrade authorization

Operational Security

• Multisig Support: Contracts support multisig wallets for all admin roles
• Emergency Pause: PolicyManager supports token-level pause functionality
• Enforcement Actions: ENFORCEMENT_ROLE can execute clawback and forceTransfer for emergency situations

Data Integrity

• Immutable Registries: Core registry addresses are immutable after deployment
• Lien Aggregation: Active encumbrances are aggregated and tracked in DebtRegistry
• Compliance Enforcement: All transfers check compliance status before execution

Additional Resources

• OpenZeppelin Security
• Consensys Best Practices
• Solidity Security Considerations

Changelog

• 2024-12-12: Initial security policy published