Skip to main content

​
Objective

Commission an independent, authenticated penetration test of the CaseBender application, APIs, integrations, and supported on-premise deployment. The engagement must produce an evidence-backed report, remediation verification, and a retest letter suitable for customer due diligence.

​
Readiness

Schedule the engagement only when the release under test meets all of these:
  • pnpm security:policy and pnpm security:test pass on the tested commit.
  • The Runtime Security workflow passes on the same commit, including the Server Action probe and the ZAP baseline and OpenAPI scans.
  • Every Codex finding is verified-closed by an independent rescan.
  • The test environment runs with TENANT_GUARD_MODE=enforce, FIELD_ENCRYPTION_REQUIRE_ENCRYPTED=true, TLS to PostgreSQL, Redis, and OpenSearch, and the production Kubernetes or Compose profile.

​
In Scope

  • Web application and REST/tRPC APIs
  • Next.js Server Actions, called directly with forged Next-Action headers
  • Administrative, analyst, read-only, and deliberately cross-tenant test identities
  • Organization and team boundaries, RBAC, object-level authorization, and invitation flows
  • Authentication, MFA, sessions, password reset, SSO, and account recovery
  • Case, alert, observable, evidence, task, workflow, playbook, and reporting operations
  • File upload, archive, document, image, JSON, XML, CSV, and other parser paths
  • Outbound integrations, webhook callbacks, HTTP actions, URL enrichment, and SSRF controls
  • Secrets, connector credentials, license keys, logs, exports, and error responses
  • Audit-event integrity, attribution, ordering, deletion resistance, and privileged changes
  • Docker Compose and Kubernetes deployment defaults, service exposure, container privileges, and secrets handling
  • Published container images, SBOMs, provenance attestations, and signature verification
  • Workflow Python steps and the isolated Python runner
  • Organization purge, legal hold, and data export
  • Desktop installer update channel and signature checks
  • AI features: prompt injection, cross-tenant retrieval, and data sent to providers

​
Required Test Cases

  1. Attempt horizontal and vertical privilege escalation across every identifier-bearing API.
  2. Validate tenant isolation with paired organizations and intentionally overlapping object names.
  3. Test mass assignment, unsafe filtering, pagination abuse, race conditions, and replay.
  4. Exercise stored, reflected, and DOM XSS plus SQL/NoSQL/command/template injection.
  5. Test SSRF with redirects, DNS rebinding, IPv4/IPv6 variants, metadata endpoints, and alternate URL encodings.
  6. Fuzz uploads and parsers for traversal, decompression bombs, polyglots, XXE, and malicious filenames.
  7. Validate CSRF, CORS, cookie attributes, session rotation, logout invalidation, and token lifetime.
  8. Attempt audit suppression, tampering, log injection, and actions without attributable identity.
  9. Review default network boundaries, non-root execution, writable paths, capabilities, and exposed management services.
  10. Confirm no credentials or customer data appear in client bundles, images, logs, crash output, or build attestations.
  11. Bypass login MFA, step-up checks, account lockout, and rate limits, including through rotating source addresses.
  12. Escape the Python runner sandbox or reach the network, environment, or other tenants’ data from a workflow.
  13. Use one organization’s integration, webhook, or API key to read or change another organization’s data.

​
Test Environment and Accounts

Provide two organizations, A and B, with the same team, case, and alert names. In each organization create:
  • an organization admin enrolled in MFA
  • an analyst with write access
  • a read-only user
  • a case-scoped external collaborator
  • a delegated API key with limited scopes
Add one superadmin account for platform-level tests, plus an analyst who belongs to both organizations to test switching the active organization. Use synthetic data only, and rotate every credential after the engagement.

​
Remediation SLAs

Every fixed finding gets a regression test in pnpm security:test before the retest is requested. A finding may be accepted instead of fixed only with a written risk acceptance signed by the security owner, and it remains listed in the retest letter.

​
Rules of Engagement

  • Use a dedicated production-like environment with synthetic data only.
  • Provide written authorization, source IPs, test window, emergency contacts, and stop conditions.
  • Permit authenticated testing and safe proof-of-concept exploitation; prohibit destructive persistence and denial-of-service unless separately approved.
  • Record tool versions, timestamps, affected release digest, test identities, and complete reproduction steps.
  • Notify the CaseBender security contact immediately for Critical findings or evidence of cross-tenant access.

​
Deliverables and Acceptance

  • Executive and technical reports with CVSS, business impact, evidence, and remediation guidance
  • Coverage matrix mapping every in-scope area to tests performed and outcomes
  • Explicit limitations and untested areas
  • CaseBender triage response with owner and SLA for every finding
  • Independent retest of all Critical and High findings
  • Signed retest letter identifying the tested release and remaining accepted risks
  • Letter of attestation naming the tester, test dates, release digest, and scope
Repeat the engagement at least once a year and after any major change to authentication, tenancy, or the deployment model. The engagement is complete only after the retest artifacts are stored in the security evidence register and customer-facing claims are updated to match the verified result.