Seven fixed findings; one release blocker and three explicit evidence/design gaps. Priorities express impact, not proof of exploitability in a deployed environment.
trustweave · TW-R3-01 · P1 · fixed
Ambiguous SD-JWT disclosure parsing and placement
Malformed tuples were coerced to strings, and nested commitments could be treated as top-level claims. Visible claims could be shadowed.
Implemented: Strict tuple/name checks; reject reserved names, duplicate digests, visible-claim collisions and unsupported nested commitments. Keep supported top-level claims bound to issuer-signed digests.
Evidence: Adversarial import-profile unit tests and real browser issuer/import/presentation tests.
Boundary: Nested SD-JWT and array disclosures remain unsupported and fail closed.
Source and test references
trustweave · TW-R3-02 · P1 · fixed
Plain VC holder binding trusted mutable local metadata
Changing a stored record's subjectDid could satisfy the wallet's local holder-selection check despite a different signed subject.
Implemented: Read holder binding from the credential payload; reject contradictory JWT and VC subject identifiers. Issuer signature verification still occurs before import and presentation.
Evidence: Forged metadata and contradictory subject regression tests.
Boundary: A downstream verifier must still independently validate holder binding.
Source and test references
trustweave · TW-R3-03 · P1 · fixed
Demo issuers leaked claims advertised as selective
Student identifiers and other profile claims appeared both in disclosures and in the always-visible issuer payload. Withholding the disclosure did not hide the claim.
Implemented: Remove overlaps in university, CAC, FAA and spatial issuers. Reject duplicate selective claims and attempts to override issuer/holder binding through alwaysVisible.
Evidence: All four real issuer routes checked for visible/selective overlap; imported credentials can withhold claims.
Boundary: Old credentials with overlapping claims require reissuance; existing stored data is preserved.
Source and test references
trustweave · TW-R3-04 · P2 · fixed
Wallet lacked framing and referrer protections
Wallet pages could be embedded by another origin and invitation URLs could be exposed through browser referrers.
Implemented: Add frame denial, restrictive frame-ancestors/object/base directives, no-referrer, nosniff and camera/microphone/geolocation permissions policy.
Evidence: Production HTTP header browser test and production build.
Boundary: The CSP is not a nonce-based script policy and does not remove same-origin script risk.
Source and test references
trustweave · TW-R3-05 · P2 · fixed
Recovery export failures and repeated resets lacked feedback
Storage errors during export escaped without useful feedback; repeated reset actions stayed enabled.
Implemented: Show a preservation-focused export error, disable reset while pending, and defer blob URL revocation so downloads can start.
Evidence: Typecheck/build and existing production recovery-page browser test; export-error/reset timing branches reviewed in code.
Boundary: Credential export cannot recover a lost non-extractable holder key.
Source and test references
trustweave-saas · SA-R3-01 · P1 · fixed
Timeouts released tenant capacity before providers stopped
A provider ignoring interruption retained a worker while its tenant/session reservation was removed. Repeated requests could consume capacity beyond the per-tenant budget.
Implemented: Release reservations when the callable actually exits, including cancelled-before-start and rejected task handling. Preserve timeout responses without treating interruption as proof of completion.
Evidence: Non-cooperative provider regression verifies 504 deadline, 409 duplicate, 429 tenant capacity and another tenant's successful work.
Boundary: Reservations are per process; finite database session leases are not cluster-wide tenant admission control.
Source and test references
trustweave-saas · SA-R3-02 · P2 · fixed
SDK fingerprint omitted dependency catalogs and runtime resources
Changing version catalogs, SPI descriptors or other build inputs could leave the old source fingerprint unchanged.
Implemented: Include TOML catalogs, lockfiles, runtime resources and Gradle wrapper inputs; preserve binary bytes and normalize text line endings. Add a regression test and run it in CI.
Evidence: Temporary Git repository regression checks additions/changes to build inputs and resources, cross-platform text normalization, and exclusion of test-only changes.
Boundary: The stronger fingerprint was recorded for the reviewed local source inventory. The old SDK commit pin remains unresolved.
Source and test references
trustweave-saas · SA13 · P2 · release-pending
Published SDK/SaaS pair and staging evidence remain outstanding
The working tree uses reviewed but uncommitted SDK changes while .trustweave-revision still references the older commit. Local success cannot validate that published pair.
Next step: Keep the fail-closed parity gate. Publish the reviewed SDK revision, pin its full SHA and run exact-pair Linux CI plus staging checks.
Evidence: No publication, remote Linux CI or staging deployment performed in this pass.
Boundary: Do not deploy the old pin or update the fingerprint solely to bypass parity checks.
Source and test references
trustweave · GAP-TW-PROVIDERS · P2 · evidence-gap
Provider coverage and production-scale storage evidence
Most plugin modules are unassessed. Live cloud-provider behavior and large-scale storage performance are not established by the local tests.
Next step: Next validation: provider-specific contract suites against supported services, realistic data volumes, latency/memory budgets and failure injection.
Evidence: Prior round: 515 targeted SDK tests, PostgreSQL paging/index eligibility and bounded H2 paging. Not rerun as a full SDK suite in this pass.
Boundary: Legacy list APIs materialize complete results. File mutation locks are JVM-local.
Source and test references
trustweave · GAP-TW-CUSTODY · P2 · design-limit
Browser custody and supported-format boundaries
Non-extractable browser keys do not enforce user presence, survive profile loss or resist hostile same-origin scripts. Imports support a limited issuer/disclosure profile.
Next step: For production custody, select a supported hardware/user-presence or external-wallet approach and validate recovery and interoperability against that profile.
Evidence: Real Chromium persistence, cross-tab mutations, non-extractability and signed presentation tests pass.
Boundary: A hardware-wallet redesign is not claimed as completed.
Source and test references
trustweave-saas · GAP-SA-OPERATIONS · P2 · evidence-gap
Cluster admission and webhook recovery require operational validation
Per-instance worker budgets do not establish cluster-wide tenant quotas. Failed webhook replay relies on operator-driven authenticated redelivery; queue monitoring is documented rather than validated in staging.
Next step: Exercise two or more instances with shared ingress quotas and slow providers; rehearse a signed webhook failure, alert, parser repair and deduplicated redelivery.
Evidence: Local worker regression and backend tests; no distributed load run or operational recovery drill.
Boundary: Stripe invoice-paid/payment-failed handlers also remain logging-only for transaction-cost settlement/notifications; completion needs a defined billing workflow.
Source and test references