From 1ff7b5e44dcabd72e41e420ecff73398431fc2fd Mon Sep 17 00:00:00 2001 From: Peter Xing Date: Wed, 20 May 2026 11:18:15 +1000 Subject: [PATCH] docs: add bug bounty security policy draft --- SECURITY.md | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..6074c2d --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,87 @@ +# Security Policy + +TurboLong is a Stellar/Blend leverage strategy project. This policy defines a draft public bug-bounty surface for issue #88 and gives researchers a safe disclosure path while the maintainers choose the final platform and fund the program. + +## Program status + +This policy is **not a promise to pay until maintainers publish the final external program URL and funding source**. Until then, please treat the table below as the proposed reward schedule for launch planning. + +| Item | Status | +| --- | --- | +| External platform | TBD by maintainers: Immunefi, HackerOne, or a self-hosted intake | +| Disclosure contact | TBD by maintainers; use the platform inbox once live | +| Launch scope | `contracts/strategies/blend_leverage`, keeper/loop execution scripts, rate/health-factor math, and deployment configuration | +| Out of scope by default | Social engineering, phishing, physical attacks, spam, denial-of-service against public RPCs, vulnerabilities that require leaked secrets, and issues only present in local debug/test fixtures | + +## In-scope assets + +The initial launch scope should stay narrow enough to triage well: + +- `contracts/strategies/blend_leverage/**` + - leverage/repay/withdraw accounting + - Blend pool and reserve integration assumptions + - oracle/rate-health-factor math used for safety decisions +- `src/bin/execute_loop.rs` and `src/bin/simulate.rs` + - transaction construction and signer safety + - unsafe loop/repay sequencing + - simulation/readiness checks before submitting transactions +- `scripts/mainnet_loop.ts`, `scripts/testnet_loop.ts`, and deployment scripts + - keeper automation behavior + - environment validation + - accidental mainnet/testnet mix-ups +- Public documentation that could cause users to take materially unsafe actions. + +## Severity guide + +| Severity | Examples | Proposed reward tier | +| --- | --- | --- | +| Critical | Direct loss of user funds; unauthorized withdrawal/borrow; strategy action that can force liquidation from a normal user position; signer/key exposure path in production flow | USD 10,000-50,000 | +| High | Incorrect health-factor/rate math that can trigger unsafe leverage; keeper/deployment bug that can submit harmful transactions; oracle/reserve mismatch with credible loss path | USD 2,500-10,000 | +| Medium | Safety check bypass with limited preconditions; inaccurate risk display that can materially mislead users; denial of strategy closure without fund loss | USD 500-2,500 | +| Low | Hardening gaps, missing validation, confusing docs, or issues with no direct user-fund impact | USD 100-500 | + +Maintainers should set final amounts before launch and record whether rewards are paid in fiat, XLM, USDC, or another asset. + +## Safe harbor + +Researchers acting in good faith should: + +1. Use local tests, simulations, forks, or testnet deployments whenever possible. +2. Avoid accessing, modifying, draining, or locking funds they do not own. +3. Avoid disrupting public RPC endpoints, frontend hosting, or third-party services. +4. Report privately through the chosen program inbox before public disclosure. +5. Give maintainers a reasonable remediation window before publication. + +The maintainers should not pursue legal action against good-faith research that follows this policy and avoids harm. This is a draft safe-harbor statement and should be reviewed before the external program goes live. + +## Report template + +A useful report should include: + +- Affected commit, contract, script, or deployment target. +- Severity estimate and why it matters economically. +- Preconditions and exact reproduction steps. +- Minimal proof of concept using local tests, simulation, fork, or testnet where possible. +- Expected vs actual behavior. +- Impact estimate: funds at risk, affected users, liquidation/interest-rate effect, or operational failure mode. +- Suggested fix or mitigation, if known. +- Reporter contact and payout preference once the program is live. + +## Disclosure-pipeline launch test + +Before marking issue #88 done, run one dry-run report through the selected intake channel: + +1. Create a harmless test report titled `Disclosure pipeline test - no vulnerability`. +2. Confirm the report reaches the triage owner. +3. Confirm severity, duplicate, and payout decisions can be recorded. +4. Confirm private notes are not exposed publicly. +5. Confirm the final public advisory path is documented. + +## Maintainer launch checklist + +- [ ] Choose platform: Immunefi, HackerOne, or self-hosted. +- [ ] Publish the final disclosure contact or platform URL. +- [ ] Confirm reward currency, funding source, and maximum payout. +- [ ] Confirm the in-scope commit/tag and deployed contract addresses. +- [ ] Confirm coordinated-disclosure timelines and embargo rules. +- [ ] Run the disclosure-pipeline launch test above.