題幹與適用場景
請設計一個面向軟體供應鏈的透明證明服務。建置者可以聲明建置環境與制品摘要，發布者可以聲明版本與來源，整合商可以追加測試或合規結果；消費者需要驗證聲明由誰簽署、是否通過登記策略，以及是否存在可校驗的歷史回執。
題目重點是「可驗證的記錄」與「業務資料庫」的邊界：服務要證明某條聲明在某時刻被登記並通過檢查，但不負責取代物件儲存、套件倉庫或完整的依賴解析器。
面試官考察點
信任邊界
高品質回答會區分聲明簽發者、透明服務、稽核者與依賴消費者，說明每個角色能證明什麼，以及不能證明什麼。
密碼材料與可驗證歷史
候選人應解釋簽名聲明、策略檢查結果、不可變日誌與回執的關係，避免把「寫入資料庫」當成防竄改證據。
可營運的治理流程
需要涵蓋金鑰輪替、撤銷、重複提交、策略版本、租戶隔離、隱私與災備，而不只是畫一條寫入鏈路。
可靠性與擴展
要說明登記冪等、批次驗證、讀取證明、跨區複製與稽核重播，處理高發布量與依賴方瞬時查詢。
回答前需要釐清的問題
- 聲明只服務軟體制品，還是也包含硬體、模型與部署環境？
- 登記服務是單一組織營運，還是多租戶共享並可互相驗證？
- 消費者要求強一致讀取，還是允許看到「已登記但證明尚未同步」的狀態？
- 哪些欄位屬於敏感資訊，是否只公開摘要、時間與簽發者識別？
- 撤銷是撤銷金鑰、聲明，還是僅更新策略判定？
- 目標吞吐、證明保留年限與跨區復原點分別是多少？
30 秒回答框架
「我把系統分成聲明登記 API、策略檢查器、透明日誌、回執服務與驗證 SDK。簽發者提交帶 COSE 簽名的聲明，服務先依版本化策略檢查，再以冪等鍵登記到追加式日誌；日誌回傳包含 Merkle 證明的回執。消費者拿聲明、回執與稽核路徑離線驗證簽名、日誌包含性、策略版本與時間。私密欄位只保存摘要或加密參照，金鑰輪替與撤銷透過信任根與狀態清單處理，跨區複製先複製日誌和檢查結果再開放讀取。」
分步驟深入解答
第一步：定義聲明與角色
聲明包含 subject（制品或元件識別）、issuer、statement type、有效時間、策略版本與內容摘要；簽發者用 COSE_Sign1 簽名。透明服務只接受已驗證的 issuer，並把聲明與租戶、命名空間及來源關聯。消費者、稽核者與策略管理員是不同權限主體。
第二步：設計登記流程
客戶端呼叫 POST /statements，攜帶簽名聲明、冪等鍵與策略提示。服務驗證簽名、時間視窗、schema 與 issuer 狀態，再執行策略檢查。通過後寫入追加式透明日誌；相同內容與冪等鍵回傳原回執，衝突則回傳目前登記結果，不靜默覆蓋。
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor
{ signedStatement, policyVersion }第三步：產生可驗證回執
透明服務為登記項目產生 receipt，包含日誌樹版本、葉節點摘要、證明路徑與服務簽名。讀取方用服務公鑰驗證回執，再重新計算聲明摘要並檢查包含性。回執只證明「服務在某時刻登記並承諾這筆記錄」，不證明制品本身安全。
第四步：處理策略、撤銷與時間
策略按版本發布並固定到每筆登記記錄；後續策略變化不會改寫舊結論，而是產生新的評估聲明。金鑰輪替保留舊公鑰與生效時間，撤銷清單標記 issuer、金鑰或聲明狀態。驗證器必須檢查聲明時間、回執時間與信任根是否在可接受視窗內。
第五步：隔離隱私與多租戶
公開日誌只放摘要、類型、issuer 識別與必要時間；原始碼、內部網域與漏洞細節放在加密物件儲存，聲明攜帶內容尋址參照。租戶策略、配額與讀取授權在 API 層執行，日誌索引按租戶分區，但證明格式保持跨租戶可驗證。
第六步：擴展、災備與營運
寫入路徑按日誌分片與批次提交擴展，讀取路徑快取公鑰、schema 與回執。跨區複製採用順序日誌與檢查點，目標區在日誌、策略結果與金鑰狀態達到一致前標記為唯讀。指標包括登記成功率、策略拒絕率、回執產生延遲、複製落後、驗證失敗率與金鑰撤銷傳播時間。
高品質示範回答
「我會提供一個聲明登記 API 和離線驗證 SDK。建置系統提交帶 COSE_Sign1 的聲明，聲明包括制品 digest、issuer、類型、時間與策略版本。服務先驗證簽名與 schema，再按租戶策略檢查，成功後把摘要寫入追加式透明日誌，並回傳包含性證明回執。登記使用冪等鍵，重複請求回傳同一回執。
消費者下載聲明、回執與信任根，在本地驗證簽名、日誌包含性、issuer 狀態與策略版本；驗證結果可以再作為新的簽名聲明登記，形成可追溯鏈。敏感內容只保留加密參照，公開日誌不洩露原始碼。金鑰輪替保留歷史信任根，撤銷透過狀態聲明傳播。跨區先複製順序日誌、檢查點和策略結果，復原後再開放強驗證讀取。系統證明的是登記與可追溯性，不能取代惡意程式掃描或執行時安全判斷。」
常見錯誤
- 直接把聲明寫入可修改資料表 → 管理員可改歷史 → 使用追加式日誌、簽名回執與獨立驗證路徑。
- 把透明回執當成安全結論 → 登記不等於制品沒有漏洞 → 分離來源、策略結果與執行時風險。
- 策略更新覆蓋舊記錄 → 稽核無法重現 → 固定策略版本，追加新的評估聲明。
- 只輪替目前金鑰 → 舊聲明無法驗證 → 保留帶生效時間的歷史公鑰與信任根。
- 公開全部聲明欄位 → 原始碼和漏洞元資料洩露 → 公開摘要，敏感內容使用加密參照。
- 重試造成重複登記 → 日誌膨脹且結果不穩定 → 冪等鍵綁定簽名內容與租戶。
- 跨區複製後立即開放讀取 → 證明路徑不完整 → 複製日誌、檢查點與金鑰狀態後再切換可讀。
- 只做中心 API 驗證 → 離線稽核無法工作 → 提供聲明、回執、信任根與離線驗證器。
追問及應對
追問一：如何證明日誌沒有刪除中間記錄？
讓稽核者定期取得並比較簽名檢查點；驗證器檢查樹大小單調增長、歷史根一致與包含性證明，發現分叉時停止信任該日誌。
追問二：兩個透明服務的回執可以互相驗證嗎？
可以共享聲明摘要與標準化回執格式，但每個服務仍由自己的信任根簽名。跨服務等價性需要額外的交叉聲明，不能把一個服務的公鑰當成另一個服務的信任。
追問三：撤銷一條已登記的聲明怎麼辦？
保留原聲明與回執，追加一條撤銷或風險狀態聲明；驗證器按時間與策略決定目前是否接受，稽核者仍能看到原始登記事實。
追問四：登記服務不可用時發布流水線怎麼辦？
允許客戶端本地快取待登記的簽名聲明和內容摘要，流水線明確標記「尚未取得透明回執」；復原後按冪等鍵補登記，禁止把缺少回執偽裝成已驗證。
追問五：如何避免日誌成為單點隱私洩露源？
只登記最小公開欄位，使用租戶級存取策略與加密參照；對時間、issuer 與制品類型做必要聚合，同時保留稽核所需的可驗證摘要。
來源一：RFC 9943 SCITT 架構
RFC 9943 定義簽名聲明、透明服務、回執與可驗證資料結構證明，並明確登記服務證明的是聲明被記錄和檢查，不負責取代制品儲存或依賴解析。本文的角色邊界、登記流程與回執設計據此展開。
來源二：SCITT 專案說明
SCITT 專案說明其目標是讓供應鏈聲明具備可稽核、可追溯與可驗證歷史。本文的跨租戶驗證、策略治理與跨區營運將這個目標落到系統設計取捨。
來源三：軟體工程技術面試研究
關於軟體工程候選人技術面試準備的研究強調，回答需要在溝通、限制釐清和技術推理之間取得平衡。本文保留釐清問題、30 秒框架與故障追問，幫助候選人展示取捨而非背誦術語。