Skip to content

Pentest Summary

Statement

ClaimGuard has not yet engaged an external penetration-testing firm. A pentest is on the roadmap and is sequenced after the GCP posture work (Track A — HTTPS LB, IAM cleanup, OS Login, Secure Boot) so the test exercises the production-shape configuration rather than a transitional one. The internal application-security pass that informed the current posture was a Snyk-driven static analysis + manual review (Snyk remediation summary), which is rigorous for static / dependency findings but is not a substitute for an active pentest.

This page is the placeholder so a prospect or auditor can see the pentest is scheduled rather than indefinite, and so a future engagement summary has a reserved home.

Implementation

What has been done in lieu of a pentest

  • Snyk Open Source + Snyk Code: 188 findings disposed in .snyk or via direct fix during the 2026-04 remediation pass. See Snyk remediation summary.
  • Multi-agent code review (/ultrareview) of the security remediation branch before merge to main.
  • Manual review of the auth, authorization, outbound HTTP (safeFetch), and upload paths against the documented invariants in docs/security/README.md.
  • Cloud-posture review against an explicit P0/P1/P2 plan with per-step verification, recorded in docs/security/HARDENING-LOG.md.

These are valuable controls but they share a class of blind spots — they are all internal, mostly static, and largely tool-driven. A black-box external pentest is the right complement.

Scope an external pentester should expect

A target scope for the first engagement, when it lands:

  • Application surface: the production HTTPS endpoint (post-A1.3), the API auth path, the API-key path, the upload path, the AI-analysis path, role + org isolation between tenants, and the trust-portal hosting itself.
  • Cloud surface: the VM's exposed network, the IAP-SSH path, IAM posture, and the public-storage / GCS exposure surface.
  • AI surface: prompt-injection robustness against the master_tool Gemini integration. Cross-listed on Prompt guardrails which today calls out the absence of an automated red-team eval set.
  • Out of scope (initial engagement): denial-of-service, social engineering, physical access — same boundaries as the Vulnerability Disclosure Policy.

Sequencing

  • Wait for Track A P1 closure (HTTPS LB, OS Login, Secure Boot, IAM cleanup): the production network shape is stable, so the pentest exercises the real attack surface.
  • Wait for password_plain removal (see Authentication): so the pentest does not waste budget rediscovering a known gap.
  • After: engage a pentest firm. Initial engagement is expected to be a time-bound external black-box assessment with optional authenticated grey-box add-ons for the auth and AI surfaces.

Status

planned — target: after Track A P1 closure and before SOC 2 Type I fieldwork.

Roadmap

  • Vendor selection. Solicit proposals from at least two firms; evaluate for insurance/financial-services experience and AI-pentest capability.
  • Scope agreement. Cap the target list to the surface above; agree on a fixed-window grey-box authenticated test for the auth and API paths.
  • Engagement. First pentest. Output: an executive summary, a findings list with severities, and remediation guidance.
  • Remediation cycle. Triage and fix; re-test high/critical findings.
  • Publish a sanitized summary on this page — what was tested, the number of findings by severity, the remediation status. Detailed findings stay private.
  • Annual cadence thereafter, plus a re-test on any material architecture change.