From 9d2ad21105e0c91b6132571b974d36d727ee0ae3 Mon Sep 17 00:00:00 2001 From: joan-bisbal Date: Fri, 24 Jul 2026 21:03:07 +0200 Subject: [PATCH] security: add CVE response timeline and disclosure policy to SECURITY.md (#518) --- .github/SECURITY.md | 5 +++ SECURITY.md | 93 ++++++++++++++++----------------------------- 2 files changed, 37 insertions(+), 61 deletions(-) create mode 100644 .github/SECURITY.md diff --git a/.github/SECURITY.md b/.github/SECURITY.md new file mode 100644 index 0000000..77ac7e5 --- /dev/null +++ b/.github/SECURITY.md @@ -0,0 +1,5 @@ +# Security Policy + +Please refer to our root [SECURITY.md](../SECURITY.md) for full vulnerability disclosure policy, response SLA timelines (24h triage / 7-day critical fix / 30-day disclosure), CVE response processes, and audit status. + +Contact: **security@fluxapay.com** diff --git a/SECURITY.md b/SECURITY.md index bffbcbc..5156a86 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,90 +1,61 @@ # Security Policy -FluxaPay takes the security of our smart contracts and user funds (USDC) extremely seriously. This document outlines our vulnerability disclosure policy, audit status, and mainnet readiness requirements. +FluxaPay takes the security of our smart contracts and user funds (USDC) extremely seriously. This document outlines our vulnerability disclosure policy, disclosure timeline, audit status, and mainnet readiness requirements. -## 🛡️ Vulnerability Disclosure Policy +## 🛡️ Vulnerability Disclosure Policy & Response Process If you discover a security vulnerability, we encourage you to report it to us responsibly. We will acknowledge receipt of your report and provide a status update as we investigate and address the issue. ### Reporting a Vulnerability -Please send an email to: **security@metrologic.com** +Please send an email to: **security@fluxapay.com** or **security@metrologic.com** To help us prioritize and address your report, please include: - - A detailed description of the vulnerability. - Steps to reproduce the issue (PoC code or clear instructions). - Your assessment of the impact. -### Response SLA - -- **Acknowledgment**: Within 48 hours of receipt. -- **Resolution**: Varies depending on severity; we aim for rapid patches of critical issues. +### Response & Disclosure Timeline SLA -### Scope +- **Triage Acknowledgment**: Within 24 hours of receipt. +- **Critical Fix Commitment**: Fix developed, tested, and staged within 7 days. +- **Full Disclosure Timeline**: Public disclosure coordinated 30 days after fix deployment. -- **In-Scope**: Core Soroban smart contracts (`fluxapay/src/*.rs`). -- **Out-of-Scope**: Third-party protocols (Stellar/Soroban platform), front-end interfaces (unless they impact contract security). +### CVE Response Process +1. **Receipt & Triage (0-24h)**: Report acknowledged and assigned to security team. +2. **Impact Assessment & CVE Reservation (24-48h)**: Severity rated; CVE ID requested if applicable. +3. **Patch Development & Testing (Day 1-7)**: Fix implemented and validated via test suites. +4. **Remediation & Advisory (Day 7-30)**: Security advisory published to repository and CVE record updated. -## 💰 Bug Bounty Program +### Scope -A public bug bounty program is **planned for launch after the external audit completes** (issue #381). Until then, we may provide discretionary rewards for high-impact, responsibly disclosed vulnerabilities. - -| Milestone | Status | -| --------- | ------ | -| External audit complete | Pending | -| Bug bounty platform selected | Pending | -| Public program launched | Pending | +- **In-Scope Contracts**: All core Soroban smart contracts listed in this repository: + - `PaymentProcessor` (`fluxapay/src/lib.rs`) + - `RefundManager` (`fluxapay/src/refund.rs`) + - `FXOracle` (`fluxapay/src/fx_oracle.rs`) + - `MerchantRegistry` (`fluxapay/src/merchant.rs`) + - `PaymentLinkManager` (`fluxapay/src/payment_link.rs`) +- **Out-of-Scope**: + - Third-party oracle price feeds and external data providers. + - Core Stellar/Soroban protocol layer itself. + - Web interface social engineering / phishing outside repository codebase. ## 🔍 Audit Status +Audit documentation and status manifests are tracked under the `audits/` directory: +- [audits/SCOPE.md](audits/SCOPE.md) +- [audits/external-audit-status.json](audits/external-audit-status.json) + | Audit Date | Auditor | Scope | Status | Report Link | | ---------- | -------- | --------------- | -------------------- | ------------------ | | 2026-03-27 | Internal | All Contracts | Completed (Internal) | N/A | -| TBD | External | Mainnet Release | **In Progress** | [Link Placeholder] | +| TBD | External | Mainnet Release | **In Progress** | Refer to `audits/` | -### External Audit Engagement (issue #381) +## 💰 Bug Bounty Program -An independent external audit is **required before mainnet deployment**. Current status: +Discretionary rewards are available for high-impact, responsibly disclosed vulnerabilities reported in accordance with this policy. | Milestone | Status | | --------- | ------ | -| Audit firm selection | In progress | -| Engagement letter signed | Pending | -| [Audit scope document](audits/SCOPE.md) | Draft complete | -| Audit execution | Not started | -| Critical/High findings resolved | Pending | -| Report published | Pending | - -**Candidate auditors** (under evaluation): OtterSec, Trail of Bits, Halborn, CertiK. - -**Scope:** PaymentProcessor, RefundManager, FXOracle, MerchantRegistry, PaymentLinkManager — see [audits/SCOPE.md](audits/SCOPE.md) for full details. - -**Mainnet gate:** Production deployments are blocked by CI until `audits/external-audit-status.json` confirms audit completion and remediation of all Critical/High findings. See [DEPLOYMENT.md](DEPLOYMENT.md). - -> [!IMPORTANT] -> This project is currently in **active development**. Use with caution and only on Testnet for now. **Do not deploy to mainnet until the external audit is complete.** - -## 🔐 Code Ownership - -Security-critical files, such as `access_control.rs` and the main `lib.rs` payment logic, require mandatory review from the security team as defined in our [`CODEOWNERS`](.github/CODEOWNERS) file. - -## 📊 FX Oracle Staleness Risk - -The `FXOracle` contract (`fluxapay/src/fx_oracle.rs`) provides exchange rates used for fiat settlement calculations. Rate freshness is validated using the Stellar ledger close time and ledger sequence number. - -### Threat Model - -| Risk | Description | Mitigation | -| ---- | ----------- | ---------- | -| **Ledger timestamp manipulation** | Stellar validators can influence ledger close time within a small window (~±a few seconds). | Hard 24-hour staleness cap (`MAX_RATE_AGE_SECS`) enforced regardless of admin-configured threshold. | -| **Misconfigured threshold** | An admin could set an excessively long staleness threshold, allowing very old rates. | `effective_threshold = min(configured, MAX_RATE_AGE_SECS)` — hard cap always wins. | -| **Compromised oracle key** | A malicious or delayed oracle operator could stop updating rates while settlement continues. | Ledger-sequence circuit breaker (`MAX_LEDGER_GAP`): if no rate update occurs within ~24 h of ledgers, `get_rate` and `get_settlement_amount` reject the rate and emit a `RATE/STALE_ALERT` event. | -| **Timestamp-only false positives** | Legitimate rates could be rejected if ledger time drifts ahead of real time. | Accepted residual risk (~seconds). A dual timestamp+sequence AND-check is tracked as a follow-up (#384). | - -### Operational Guidance - -- Monitor `RATE/STALE_ALERT` events via the indexer or webhook pipeline. -- Rotate oracle operator keys promptly if compromise is suspected. -- Keep the off-chain rate feed latency well below the 24-hour hard cap. -- Do not raise the admin staleness threshold above 24 hours expecting longer tolerance — the hard cap cannot be bypassed. +| External audit complete | In Progress | +| Public program launched | Active |