5 SEPTEMBER 2026 · ROUND 8

Engineering review and hardening

Provider deployment policy, cryptographic key integrity and safe migration retries. Actual hardware custody and provider promotion remain open.

Previous review · Findings · Scores · Validation data

Latest follow-up: Round 9

trustweave

97.5/100

Previous review: 97/100

trustweave-saas

96/100

Previous review: 96/100

Assessment scope

Round 8 targeted review of provider maturity enforcement and browser custody. SDK architecture gains 0.5 for the tested deployment gate and catalog-metadata consistency. Wallet integrity fixes close concrete storage bugs but do not earn hardware-custody credit. SaaS remains 96: no new billing, staging or release validation occurred. Scores retain prior evidence for unchanged areas; this is not a fresh exhaustive audit.

Scores are engineering judgments against the same 30/25/20/15/10 rubric. They are not percentages of bug-free code or a security certification. Historical scores are preserved.

CategoryMaximumTrustWeaveSaaS
Security302929
Correctness252424.5
Architecture2019.519
Testing151514
Experience10109.5

Remaining deductions

trustweave

trustweave-saas

Validation evidence

AreaResultScope and limits
SDK common module430 tests passed; 0 failures/skips; ktlint passedIncludes two new provider-policy tests. Other SDK modules retain earlier evidence.
Wallet unit42 passed; 0 failuresFive new adversarial custody/migration cases; earlier issuance, disclosure, restore and recovery tests.
Wallet production/browserBuild/TypeScript and 11 Chromium regressions passedNative WebCrypto and IndexedDB persistence, reload, disclosure, restore/replacement and CSP.
Provider documentationGenerated capability drift check passedNo supported-provider promotion or external cloud/hardware claim.
SaaS integration boundaryReviewed local fingerprint updated and verifiedNo new SaaS runtime change or backend/full-stack rerun; immutable release pairing remains open.
SDK fingerprint verifier2 tests passed; fingerprint matches reviewed local source5de202557972a1ab6498deda3591d01492485fcd47a727384e87684d8f6235dd; not an immutable release attestation.
HTML reportAll local links and four filters passed; desktop/mobile visually checked; no mobile overflowFive findings; screenshots recorded in this report directory.

Results distinguish local database/HTTP fixtures from hosted-service validation. Optional tests that did not run remain reported as skips. Timing excludes fixture setup.

Build and test logs

Implemented improvements and remaining gaps

trustweave · TW-R8-01 · verified

Provider deployment maturity fails closed

Added a public deployment gate combining maturity, operations and formats. Production accepts supported catalog entries only; explicit experimental opt-in never admits stubs or unknown modules. The internal registry can require supported providers, and catalog maturity cannot be promoted through plugin metadata. Documentation separates API support labels from deployment evidence.

Evidence: 430 common-module tests passed, including production rejection, experimental opt-in, unsupported operation/format rejection, metadata-promotion refusal and non-registration after rejection. Common ktlint and generated-document drift check passed.

Limit: No provider was promoted. The catalog currently contains no supported entries. Existing callers remain compatible; production domain/direct-client wiring must invoke the public gate. The internal registry strict option is opt-in.

Source and tests
trustweave · TW-R8-02 · verified

Cryptographic custody integrity and safe migration retries

Each load validates private key properties, proves signing-key binding to the DID and checks agreement-key binding with ephemeral Diffie-Hellman. Imports use insert-only storage, validate existing keys on retry and clear seed buffers on every exit. Fixed IndexedDB rejection timing that previously surfaced null before transaction abort.

Evidence: 42 wallet unit tests passed, including five new substituted signing/agreement key, malformed record, migration retry/overwrite and invalid-seed cleanup cases. Production build/TypeScript and 11 Chromium regressions passed.

Limit: Checks protect against stored-key corruption/substitution with trusted code; they do not prevent malicious same-origin signing or replacement of both identity and keys. Browser/OS compromise and hardware/user verification remain outside this custody profile. Each load adds cryptographic work; no latency SLA measured.

Source and tests
trustweave · PROVIDER-CUSTODY · remaining

Actual production provider and hardware custody qualification

Production policy and software custody are hardened. Hosted cloud/HSM providers still require assessment evidence. The current browser Ed25519/X25519 wallet has no hardware/user-verification signing integration. A custody-model choice was requested to determine the remaining implementation.

Evidence: No hardware, hosted KMS or new external provider run occurred. Round 7 local Accountly validation remains the available deployed-provider evidence.

Limit: Device-bound passkey and server HSM custody have different identity, authorization and recovery protocols. A passkey unlock prompt cannot be presented as hardware protection for a separate browser key. This finding is partially remediated, not closed.

Source and tests
trustweave-saas · SA13 · remaining

Published exact-pair Linux/staging validation

The reviewed SDK runtime changed locally; the fingerprint was deliberately updated and verified. The immutable revision remains the prior commit. Coordinate a new SDK commit and SaaS pin, publication and exact-pair remote Linux/staging validation.

Evidence: No publication or staging execution is claimed.

Limit: A matching local fingerprint cannot substitute for a reviewed, published and tested immutable pair.

Source and tests
trustweave-saas · BILLING-OPERATIONS · remaining

Live billing workflow and hosted alert delivery

Real local Accountly/Kill Bill application, tenant, subscriber and payment-metadata behavior is now verified. External PSP setup/collection, settlement, service-account authentication, hosted alerts and the supported legacy Stripe cutover still require validation.

Evidence: Dedicated deployed contract passed. Original two Accountly tests requiring the PSP stand-in remain unexecuted in this pass.

Limit: The supported Accountly cutover/legacy Stripe workflow needs to be defined and exercised before claiming completeness.

Source and tests

Operational handoff

docs/api-reference/provider-deployment-profiles.md defines the deployment policy, browser custody guarantees, enforcement boundaries and completion criteria for passkey or HSM custody.