morphit/docs/AUDIT-OUTSIDE-SCOPE.md

Pre-launch — outside-scope security testing

Ken asked: "if I were to hire an outside professional security auditing agency, would they do any tests that you have not?" Yes. This document catalogs what they would do that I CAN'T do from inside a code-review sandbox, why each matters, and which ones are highest-leverage for Morphit's specific threat model.

The two big categorical gaps: DAST (dynamic application security testing — needs a running target) and wetware (a human security specialist's intuitions don't substitute for source review alone).

---

High-leverage tests I cannot run

1. DAST — dynamic web-app testing against a running instance

What it is. A professional firm spins up a Morphit instance and hits it with tools like Burp Suite Pro, ZAP, or Nuclei to find runtime bugs that static review misses: timing leaks under load, race conditions in real concurrency, response-header drift, content-type sniffing, session fixation, etc.

Why this matters for Morphit specifically.

• Every instance is operator-deployed, so the attack surface includes the operator's stack (nginx, BunkerWeb, kernel, Tor exit posture). A pen-tester running against a real deploy catches misconfigurations that source review never sees.
• The federation layer means responses from one instance can be observed by other instances; behavior under cross-instance load is not reproducible in source review.

Recommendation. Highest-leverage gap. Engage at least one DAST-capable team before any "soft launch" beyond a closed-group beta. The BETA-INCIDENT-RUNBOOK.md already anticipates that operators may discover issues post-launch — a DAST pass before that catches issues operators can't.

2. Active fuzzing

What it is. AFL, libFuzzer, Atheris, or stateful fuzzers like Boofuzz/Restler crash-test parsers and protocol handlers. Different from property-based testing (fast-check) in that fuzzers actively mutate inputs to maximize coverage and find crashes/hangs/asserts.

Where it would land in Morphit.

• Chain-op JSON payload parsers (apps/indexer/src/indexer/handlers/)
• Chat-payload decoder (apps/web/src/lib/chat/payload.ts)
• Address validators (BTC/XMR/BLURT/USDT/USDC/DAI/BCH/LTC/DASH/DOGE/ ZEC/ARRR/DCR/SOL/ETH/XRP — 16 codepaths)
• Keystore envelope decoder (apps/web/src/lib/crypto/keystore.ts)
• HTTP body parsers in indexer + relay

Recommendation. Run a 24-hour libFuzzer pass against each parser. The chain-op payload parsers are the highest-priority targets because untrusted input flows directly into DB writes.

3. Cryptographic specialist review

What it is. A working cryptographer (think Trail of Bits, NCC Group, or Cure53) reads the crypto code line-by-line. They catch things a generalist source reviewer cannot:

• Side-channel weaknesses in primitive selection
• Padding-oracle exposure
• Bleichenbacher-style attacks
• Subtle nonce-reuse hazards
• Key-derivation parameter choices (Argon2 m/t/p tuning for the threat model, not just "above OWASP floor")
• Forward-secrecy / future-secrecy posture in the chat layer

Where it would land in Morphit.

• apps/web/src/lib/crypto/keystore.ts — envelope encryption
• apps/web/src/lib/crypto/keystoreYubikey.ts — hardware-key wrapping
• apps/web/src/lib/crypto/keystoreTotp.ts — 2FA secret encryption
• apps/web/src/lib/crypto/passkeys/ — WebAuthn flows
• apps/web/src/lib/chat/ — message authentication

Recommendation. One full crypto pass before launch. Pre-launch is the cheapest time to discover that a primitive choice was wrong; post-launch every key in existence becomes legacy.

cp175 update — signing migration RAISES this item's priority. Since cp173–cp174 Morphit carries TWO chain-signing implementations: the incumbent @beblurt/dblurt ECDSA (elliptic-based, the CVE-2025-14505 exposure) and a new @noble/secp256k1 signer, selected by the SIGNER_BACKEND flag (default still dblurt; cutover gated on a real chain broadcast — see ADR-0046 + SECURITY.md). Dual-signer periods are a classic site for subtle cryptographic bugs: nonce-generation differences (dblurt uses a bespoke per-attempt nonce, noble uses RFC-6979), low-S / canonical-S enforcement, recovery-id computation, and digest-binding. Static review here proved byte-recovery equivalence against dblurt's own verifier (scripts/blurt-noble-*-proof.ts, transfer/order/comment/custom_json), but a cryptographer should independently audit the noble signing path

• the cutover plan BEFORE the SIGNER_BACKEND='noble' flip. The new signer (apps/web/src/lib/blurt/nobleSigner.ts) and the two signing chokepoints (sign.ts, ops/comment.ts) are the specific targets.

4. Threat modeling workshop

What it is. A 1-2 day session where security engineers run STRIDE or PASTA on every trust boundary, identifying threats that source review cannot enumerate because they emerge from system composition.

For Morphit specifically.

• Trust boundary: user ↔ instance frontend ↔ instance indexer ↔ Blurt chain ↔ other instances ↔ counterparties off-platform
• Each boundary has a STRIDE category that source review touches partially but doesn't systematize.

Recommendation. Skippable if budget is tight, but a pre-launch threat model from outsiders catches blind spots in the developer's own threat model. Most teams over-defend against attackers they've been thinking about and under-defend against attackers they haven't.

5. Supply-chain attack review

What it is. Audit of every npm package + Python dependency for known vulnerabilities, malicious-package risk, abandoned-maintainer risk, typosquatting risk, post-install script risk, lockfile-integrity risk.

Tools the firm would run.

• npm audit + socket.dev + Snyk + Dependabot advisories
• SBOM generation (CycloneDX or SPDX)
• Reproducible-build attestation
• Signature verification on the release tarballs

Where I have partial coverage. I've run npm audit informally and the deps-clean smoke checks for known-bad packages. A pro firm would do a full SBOM with attestations.

Recommendation. Medium-high leverage. Easy wins. Ken's BLURT- treasury and YubiKey are the highest-value targets a supply-chain attacker would aim for.

6. Browser-fingerprinting analysis

What it is. Run the deployed UI through PrivacyAnalyzer, Panopti- click-style tools, or a custom canvas/WebGL/font fingerprint extractor to verify that "no fingerprinting" is actually true at runtime.

Why this matters for Morphit's priority #1 (privacy).

• The brag list claims "no fingerprinting via canvas/WebGL/fonts." Source review checks that we don't WRITE fingerprinting code; runtime testing checks that no third-party script or browser default exposes one anyway.

Recommendation. Medium leverage. Can do a self-test by running Tor Browser at the deployed instance.

7. Tor/I2P / hidden-service operational testing

What it is. Pen-test the .onion deployment specifically:

• Hidden-service descriptor leakage
• Exit-node correlation
• Tor circuit-isolation per-action
• Onion-balance failover
• Static-asset hostname leaks (CDN, fonts, favicons)

Recommendation. High leverage for the niche of users who NEED this (journalists, dissidents, etc.). Lower leverage for the broad user base. Schedule it post-soft-launch when there's a live .onion to test.

8. Real-load + chaos testing

What it is. k6 / Locust / Gatling fire realistic load patterns at the indexer + relay + DB and a chaos-engineering tool (Litmus, Chaos Mesh) injects faults (kill -9, network partition, disk full, clock skew). Tests behavior under stress.

Where it would land in Morphit.

• Indexer's chain-replay path under burst load
• Relay's altcha challenge issuance under DDoS
• DB upsert race conditions under concurrent writes
• Federation probe scheduler under network partition
• Chain-op handler idempotency under replay

Recommendation. Run before any second-instance comes online. Hardest to schedule but the chaos-tests catch things that fix themselves in dev but fail in production.

9. Mobile / WebView attack surface

What it is. If anyone bundles Morphit in a WebView (Tauri, Capacitor, etc.), that WebView is the attack surface. Same source, different runtime.

For Morphit. PWA only. No native Android/iOS yet. If a community member packages it, those packages need their own review.

Recommendation. N/A pre-launch. Note in SECURITY.md that unofficial mobile packagings are out-of-scope.

10. Social-engineering / phishing simulation

What it is. Test Ken (and any future operator/admin) for spear-phishing resistance: fake YubiKey-firmware-update emails, fake Forgejo "admin needs to re-auth" emails, fake "your operator account is suspended" emails.

Recommendation. Low priority pre-launch. Document the operator-trust model in OPERATOR-TRUST-DESIGN.md so operators know that "this email is from Anthropic-Agorise" is a phishing red flag (we never email; Matrix only).

---

Lower-leverage but worth knowing

11. Smart-contract audit

N/A. Morphit has zero smart contracts. The chain-op model is BLURT custom_json, not on-chain logic.

12. PCI / GDPR / AML compliance audit

N/A. Non-custodial means no PCI scope. No KYC means the GDPR surface is minimal (the /privacy page enumerates what data flows where). AML doesn't apply to a non-custodial marketplace.

13. Hardware HSM review

N/A unless an operator chooses to back the treasury key in an HSM. That's an operator decision documented in OPERATIONS.md.

14. Penetration of physical infrastructure

N/A. Software project, no physical infrastructure.

15. Red-team engagement

A red-team engagement combines DAST + fuzzing + threat modeling + social engineering over a 2-4 week period with a defender-vs-attacker scoreboard. Highest-bandwidth security exercise. Only worth it post-launch when you have something for attackers to actually try to compromise.

---

What I AM doing in cp138 that overlaps

• Source code review. A pro firm would also do this; mine is comprehensive but they bring different intuitions and battle-scar pattern recognition.
• Static analysis (tsc, eslint, custom smokes). They'd also run CodeQL, Semgrep, and specialty tools like Bandit (Python), Brakeman (Ruby; N/A here), gosec, etc.
• Documentation review. They'd verify SECURITY.md, OPERATIONS.md, threat-model docs match the code. I'm doing this in Phase I.

---

Concrete recommendation

For a non-custodial, no-KYC, AGPL-3.0 P2P marketplace at pre-launch:

Test	Leverage	Urgency
DAST against running instance	High	Pre-public-launch
Cryptographic specialist review	High	Pre-public-launch
Active fuzzing of payload parsers	High	Pre-public-launch
Threat modeling workshop	Medium-high	Pre-public-launch
Supply-chain audit + SBOM	Medium-high	Pre-public-launch
Tor/I2P operational test	Medium	Post-soft-launch
Real-load + chaos tests	Medium	Pre-second-instance
Browser-fingerprinting verify	Medium	Post-soft-launch
Mobile / WebView	Low	If/when Morphit ships WebView
Social engineering	Low	Post-soft-launch
Red-team engagement	High	Post-launch (when valuable)

Estimated cost for the top 5 from a tier-1 firm (Trail of Bits, NCC Group, Cure53): $40–120k depending on scope. For a $0-revenue, launching project that's a large bill. Realistic alternatives:

• HackerOne / Bugcrowd bug bounty. ~$5k initial setup. Public pre-launch programs find lots of low-hanging fruit cheaply.
• Pre-launch reviewer rotation. Find 3-5 individual contractors via Matrix/Mastodon at $5-15k each for focused mini-engagements (one does DAST, one does crypto, one does fuzzing). Cheaper than a firm; takes more coordination.
• Academic crypto review. Some university research groups will review crypto designs for free if the work is publishable. AGPL + novel threat model could attract this.

---

cp175 addendum — what this static deep-deep covered, and the recommended sequence

The cp175 deep-deep (this audit campaign) was the most exhaustive STATIC pass to date: a full five-persona walkthrough, a hostile-op sweep across all 17 indexer handlers (authz / money-parsing / replay / auth-context / oversized-payload / unicode-confusable / numeric-precision — all verified clean), a DB dead-field sweep, a memory-leak sweep, type-strictness across all 14 projects, a regex-accuracy pass, fallback/failover completeness, and a doc-accuracy pass (env vars + FAQ). Findings F-001..F-010 fixed or documented; full ledger in AUDIT-cp175-DEEP-DEEP.md.

None of that changes the answer to Ken's question: yes, an outside firm would still run tests this static review cannot. The deep-deep is necessary-not-sufficient. The static pass maximizes the value an outside engagement then delivers (they don't burn budget on issues already fixed) and narrows their focus to the genuinely dynamic/adversarial surface.

Recommended sequence (unchanged, now concrete):

1. Finish the static deep-deep (this campaign) — DONE through cp175 for the security core; a couple of doc/cleanliness items remain.
2. Stand up a staging deploy — this is the single biggest unlock. It converts ~8 of the 10 deployment-gated items (#95–104) from "impossible" to "runnable," and it's a prerequisite for the operator personas to be tested against reality rather than source.
3. Run the cheap-but-high-yield self-serve passes first: a 24h libFuzzer pass on the chain-op payload parsers (highest priority — untrusted input → DB writes), a ZAP/Nuclei baseline scan against staging, and a public bug-bounty (HackerOne/Bugcrowd, ~$5k) for breadth.
4. THEN engage a specialist for the two things money buys best: a cryptographer for the signing migration + keystore (now elevated — see §3 cp175 update), and a DAST/threat-model team for the federation + operator-stack surface. Pre-launch timing is cheapest; post-launch every key and every deployed instance becomes legacy you can't easily change.

Bottom line for Ken: the code is in unusually good static shape for a pre-launch project, but "static-clean" and "pentested" are different claims. Don't conflate them in launch messaging. The honest public line is "extensively self-audited; independent third-party review pending" — which is both true and the right posture.