Report a security incident

How to report a compromised device, suspected abuse, or SDK vulnerability.

Acting fast on a security incident matters more than acting perfectly. Here is the escalation path.

1. Capture evidence (before touching anything)

Gather a diagnostic bundle — it is redacted by default:

musterbox diagnostics generate --include-logs --include-metrics
musterbox storage inspect --json
musterbox sdk version                  # record SDK 1.0.0 / ABI 1.2.0
musterbox security sbom -o incident-sbom.spdx.json

Keep timestamps and the affected:

• player identifier (hashed),
• environment (sandbox/staging/production),
• device/platform, SDK and engine versions,
• the pre-flight risks and level if a purchase was blocked.

2. Contain

• If you believe a credential leaked: rotate the game key in the MusterBox console.
• If a player session is suspect: the backend is the source of truth — tokens can be revoked server-side; do not ship a client “fix” under pressure.
• Disable the affected credential (session scope) until reviewed.

3. Report to MusterBox

Provide, in one message:

1. What happened (symptom, not diagnosis),
2. environment + affected gameId,
3. timestamps and the diagnostic bundle,
4. hashes of any malicious inputs,
5. whether any credentials or tokens were exposed.

4. Report client-side events via the SDK

For automated audit, best-effort security events land in the backend (POST /api/v1/security/events, acknowledged 202):

let _ = client.report_security_event(
  "SUSPICIOUS_ACTIVITY",
  serde_json::json!({ "detail": "...", "ts_ms": now }),
)?;

5. Post-incident

• Run musterbox certify --suite all --json to confirm your build still passes the certification gate.
• Update the affected docs/runbooks; keep your dependency pin exact.

Never

• paste tokens, PINs, mnemonics, or wallet keys in any report (SDK output is redacted; keep it that way),
• patch a client to “bypass” a blocked integrity check to make a purchase work — that defeats the entire trust model.

Next: Migrating SDK versions.