Lesson 10.2 · 16 min read
Reference design review
The findings an officer should raise, with severity and remediation.
Findings
| # | Finding | Severity | Remediation | Module |
|---|---|---|---|---|
| 1 | Dataset keys released to the VM service account without attestation; the operator can read them | Critical | Each bank holds its own key in its own KMS and releases it only on attestation (measurements, debug off, TCB) via workload identity federation or SKR | 6 |
| 2 | SSH enabled into the trusted workload | Critical | Remove interactive access; use attested, structured diagnostics; SSH changes the effective TCB to include whoever can log in | 1, 4 |
| 3 | Training logs include sample rows and leave the boundary | High | Log only aggregate, non-sensitive metrics; review log output as part of the measured code | 1, 7 |
| 4 | GPU confidential computing mode not verified at runtime | High | Composite attestation: verify GPU evidence (CC-On, approved driver) and bind it to CVM evidence before key release | 7 |
| 5 | Image built only by the operator's CI; banks cannot verify the hash | High | Reproducible build both banks (or an auditor) can rerun; publish provenance | 8 |
| 6 | No process for updating approved measurements | Medium | Reference-value approval requiring sign-off by both banks, with rollout windows and removal dates | 6, 8 |
| 7 | No minimum TCB or advisory response plan | Medium | Define minimum TCB per platform; subscribe to AMD and NVIDIA advisories; rehearse TCB recovery | 9 |
| 8 | Output (fraud scores) not reviewed for leakage of the other bank's data | Medium | Define allowed outputs; review model and outputs for membership inference risk | 7 |
Key takeaways
- Start every review at key release and interactive access: they usually decide whether the design works at all.
- Each multi-party participant should control its own key and approve measurements.
- Logs and outputs are data flows across the boundary and need the same review as inputs.