Skip to content

VAPT Engagement Brief

Document type: Scoped testing mandate for an independent CREST (or equivalent) VAPT provider
Version: 0.1 · Date: 2026-07-11
Owner: Waspada AI engineering
Related: Executive summary · RMiT mapping · Security overview · Phase B1–B4 runtime

1. Purpose

Commission an independent vulnerability assessment and penetration test of the Waspada gateway and adjacent trust boundaries so that:

  1. An FI CISO can attach an external assurance letter to their RMiT §11 / Appendix 5 evidence pack.
  2. Residual findings are tracked against a known architecture (not discovered from a blank box).
  3. Discovery billing is minimised — auditors receive trust-boundary maps, prior adversarial findings, and measured soak artifacts up front.

This brief is not a VAPT report and not a claim of compliance.


2. System under test (SUT)

ComponentRoleTypical deploy
@waspada/sdk (edge)On-device extraction, PII strip, JWT-bound telemetryPartner WebView / browser
gateway-apiJWT verify, defense-in-depth PII, RDAP enrich, FMS/STIX/SSE, durable B1–B4 pathRailway / FI VPC
analyst-dashboardAuthenticated SSE consumerStatic + API key / ticket
RedisJTI / rate limits / tickets; Streams (waspada:events); SSE pub/subManaged Redis
Postgresalerts (DEK+AAD), audit_events, delivery_outbox, processed_eventsManaged Postgres

Product posture: advisory mule-fraud telemetry. Automated freeze is out of scope for the product and for this test (bank owns disposition).


3. Trust boundaries (test narrative)

Auditors should treat these as the primary attack surfaces. We want findings mapped to a boundary ID.

┌─ TB-1 Client device ─────────────────────────────────────┐
│  Evidence → OCR/PDF → extract → PII strip → indicators   │
│  Local AES-GCM evidence store (optional)                 │
└────────────────────────────┬─────────────────────────────┘
                             │ HTTPS + partner RS256 JWT

┌─ TB-2 Edge / partner network ────────────────────────────┐
│  Partner app holds signing key; Waspada does not         │
└────────────────────────────┬─────────────────────────────┘


┌─ TB-3 Gateway API (hardened runtime) ────────────────────┐
│  Pre-auth rate limit → JWT verify → payload bind         │
│  PII dual gate → RDAP (SSRF-capped) → pipeline           │
│  Redis Streams publish · audit_events · encrypted alerts │
│  delivery_outbox → FMS webhook · SSE ticket fan-out      │
└───────────────┬────────────────────────────┬─────────────┘
                │                            │
                ▼                            ▼
┌─ TB-4 Data plane ──────┐    ┌─ TB-5 Egress ──────────────┐
│  Redis + Postgres      │    │  Bank FMS webhook (HTTPS)  │
│  KEK env / KMS-bound   │    │  STIX export               │
│  Per-row DEK + AAD     │    │  Analyst SSE (ticket auth) │
└────────────────────────┘    └────────────────────────────┘
IDBoundaryWhat “break” means
TB-1ClientExtract PII that should have been stripped; bypass allowlists; abuse local store
TB-2Partner authForge/replay JWT; confuse kid/issuer; escalate partner identity
TB-3GatewayUnauth access to alerts/SSE; demo signing oracle in hardened mode; SSRF via RDAP/URL; DoS via unbounded work
TB-4Data planeCross-tenant read; decrypt without KEK; AAD strip/swap; outbox injection; Streams idempotency bypass
TB-5EgressAlert tamper undetected; webhook SSRF from gateway; SSE data leak without ticket

4. In scope

4.1 Application / API

  • POST /api/v1/telemetry/ingest (authn, authz, replay jti, payload hash binding, rate limits)
  • Analyst auth → SSE ticket minting → GET alert stream
  • FMS delivery path (outbox claim → decrypt → POST) including fail-open vs fail-closed config
  • STIX export endpoints / serializers (if exposed on the tested deploy)
  • /health and any unauthenticated surfaces
  • Production boot guards: missing REDIS_URL / ALERT_DATA_KEK / gateway PEM must refuse boot in hardened/production mode

4.2 Cryptography & tenancy

  • Partner JWT verification (RS256, kid, expiry, issuer)
  • Gateway alert signatures (RSA-SHA256 from env PEM — no ephemeral keys in prod)
  • Per-row AES-256-GCM DEK, KEK wrap, AAD tenant_id:alert_id:field
  • Tenant isolation on alerts, audit_events, delivery_outbox, processed_events

4.3 Async durability

  • Redis Streams consumer-group behaviour and atomic processed_events claim (inline + consumer share one winner)
  • Outbox status machine (pendingin_flightsucceeded / failed / dead_lettered) with lease reaper for stale in_flight
  • Cross-replica SSE pub/sub (waspada:sse) — tenant-scoped fan-out (ADV-004); Redis messages are {v:1, tenant_id, payload} envelopes

4.4 Known residual (must be tested / confirmed)

  • No XAUTOCLAIM PEL sweep (B5) — confirm stuck Streams PEL behaviour after simulated worker crash; document as accepted risk or finding. (Outbox in_flight + event in_progress leases are reaped — retest those paths.)
  • Claim integrity (ADV-003) — public marketing/docs must match executive summary non-claims (no “RMiT-certified”, absolute zero-PII, or sub-second durable ingest). Retest landing / whitepaper / docs after each copy change.
  • Audit writes are 1 INSERT/event — abuse for storage/CPU amplification
  • Durable ingest latency ~2 s p99 under load is a design trade-off; DoS tests should still attempt amplification beyond published soak

4.5 Configuration review

  • Env matrix: REQUIRE_REDIS, ALLOW_MEMORY_STORE, FMS_DELIVERY_REQUIRED, FMS_WEBHOOK_URL, ALERT_DATA_KEK, gateway PEMs
  • Confirm demo / ephemeral signing paths are unreachable on the hardened target

5. Out of scope (unless FI expands SOW)

ItemReason
Partner bank FMS / core bankingThird-party; advisory only
Physical / social engineering of FI staffSeparate engagement
Full source-code audit of all monorepo packagesOptional add-on; default is grey-box on deployed SUT + provided design docs
Mobile OS / WebView browser engine CVEsPlatform; test our bridge/allowlist behaviour only
DDoS at network layer beyond agreed rateCoordinate with host (Railway / FI SOC)
Destruction of production customer dataUse staging / dedicated VAPT project only
Claiming RMiT certificationFI + regulator process; VAPT is an input

6. Methodology expectations

ModeRequired
Grey-boxYes — credentials for one test partner JWT keypair + analyst API key; architecture docs below
Black-boxOptional first 1–2 days without keys, then grey-box
AuthenticatedPartner ingest + analyst SSE
UnauthenticatedAll public routes, CORS, ticket guessing, webhook callbacks if any
Dependency / SCAInclude lockfile CVE review for gateway runtime
TransportTLS to staging endpoint; no requirement to break TLS itself

Rules of engagement

  • Target: staging / dedicated VAPT deploy only (never production partner traffic).
  • Provide 24h contact; stop on critical data-destruction risk.
  • No intentional ransomware / crypto-wipe.
  • Rate-limit / WAF may be raised for the window; document the final config in the report.
  • Timebox: recommend 5–8 working days grey-box + 2 days report (adjust to provider).

7. Priority test cases (control the narrative)

These are the cases we already red-teamed internally. Auditors should re-validate and attempt to go further.

#CaseBoundaryPass criteria (summary)
V-01Unauthenticated SSE / alert disclosureTB-3 / TB-5No alert payload without valid ticket
V-02Demo / ephemeral gateway signing in hardened modeTB-3Boot refuse or path absent
V-03JWT forge, kid confusion, expired/replayed jtiTB-2Reject; replay store shared via Redis
V-04Payload hash / signature binding bypassTB-3Mutated body rejected
V-05NRIC / phone / email egressTB-1 / TB-3Dual gate strips; no mule←NRIC confusion
V-06RDAP / URL SSRF (metadata, link-local, credentialed URLs)TB-3Blocked / capped
V-07Cross-tenant alert or outbox read / SSE fan-outTB-4 / TB-5DB reads scoped by tenant_id; SSE clients only receive alerts for their bound tenant scope
V-08Ciphertext swap / AAD mismatch decryptTB-4Decrypt fail; no silent success
V-09Outbox re-drive / idempotency key collisionTB-4 / TB-5Keyed by fms:${event_id}; no duplicate FMS enqueue; stale in_flight reaped by lease
V-10Streams + inline double-processTB-4Atomic lease-aware processed_events claim (in_progresscommitted); stale claims reaped; corroboration bumps only on new alert
V-11Worker crash → stuck PEL (no XAUTOCLAIM)TB-4Streams PEL still B5 residual; outbox in_flight + event in_progress leases are reaped so a future XAUTOCLAIM retry is not defeated
V-12Rate-limit / memory exhaustion via large bodiesTB-3Limits hold; no OOM under agreed budget
V-13Analyst key in query string / ticket theftTB-5Tickets short-lived; key not required in EventSource URL long-term
V-14FMS webhook SSRF from configurable URLTB-5HTTPS-only in prod; block private targets if enforced

8. Evidence pack (provide to provider on kickoff)

ArtifactLocation
Executive status / claims boundaryexecutive-summary.md
RMiT working tablermit-mapping.md
DPIA draftdpia.md
Data flowsdata-flows.md
B0 foundationsphase-b0-foundations.md
B1–B4 runtime + known gapsphase-b1-b4-runtime.md
Advisory contractadvisory-contract.md
Memory ingest soakload-test/REPORT.md
Durable + mock-FMS soakload-test/REPORT-durable.md
Extraction CI gateAvailable on request
AppSec hardening trail13 internal hardening sprints (credibility → B0 → eval → RMiT/B1–B4 → load-test)

Access to provide

  • Staging base URL + /health
  • One partner public key registered; corresponding private key for JWT signing (test-only)
  • Analyst API key
  • Read-only DB view or sanitized row samples for crypto/tenancy checks (optional but accelerates TB-4)
  • Redis ACL user limited to app key prefixes (optional)

9. Deliverables required from the provider

  1. Executive letter (1–2 pages) suitable for FI CISO attachment.
  2. Technical report with findings rated Critical / High / Medium / Low / Informational; each mapped to a TB-* ID and, where applicable, an RMiT cite (§11 / App. 5 / crypto / access).
  3. Reproduction steps and evidence (request/response, screenshots, PoC scripts).
  4. Retest window (recommend +10 working days after fixes) and updated letter.
  5. Explicit statement on V-11 (XAUTOCLAIM gap) — accepted risk vs finding.

Severity guidance we accept: OWASP / CVSS v3.1; privilege relative to partner vs anonymous.


10. Success criteria for Waspada

OutcomeMeaning
Ready for pilot attachmentNo open Critical/High on TB-2/TB-3/TB-4/TB-5 after retest; Mediums scheduled with owners
RMiT evidence inputLetter + report filed against §11 / Appendix 5 gap row in rmit-mapping.md
Score impactSupports moving production readiness narrative from ~7.5–7.6 toward 8.0+ once letter lands — does not by itself certify BNM/RMiT

11. Suggested SOW one-pager (paste into RFP)

Grey-box VAPT of Waspada AI staging gateway (Fastify) including partner JWT ingest, analyst SSE tickets, Redis Streams + Postgres durable path (encrypted alerts, audit log, FMS outbox), RDAP enrichment SSRF controls, and production boot guards. Edge SDK in-scope for PII-strip and telemetry allowlist only. Out of scope: bank FMS, production data, network DDoS. Provider delivers CISO letter + technical report mapped to supplied trust-boundary IDs, with retest. Kickoff pack includes RMiT mapping, DPIA, B1–B4 runtime notes, and load/soak reports.


Change log

DateChange
2026-07-11v0.1 — initial engagement brief for provider RFP / kickoff

Waspada AI: Enterprise infrastructure powering public defense.