题干与适用场景
请设计一个面向软件供应链的透明证明服务。构建者可以声明构建环境和制品摘要，发布者可以声明版本与来源，集成商可以追加测试或合规结果；消费者需要验证声明是谁签的、是否通过注册策略、是否存在可校验的历史回执。
题目重点是“可验证的记录”与“业务数据库”边界：服务要证明某条声明在某时刻被登记并通过检查，但不负责替代对象存储、包仓库或完整的依赖解析器。
面试官考察点
信任边界
强回答会区分声明签发者、透明服务、审计者和依赖消费者，说明每个角色能证明什么，不能证明什么。
密码材料与可验证历史
候选人应解释签名声明、策略检查结果、不可变日志和回执之间的关系，避免把“写入数据库”当成防篡改证据。
可运营的治理流程
需要覆盖密钥轮换、撤销、重复提交、策略版本、租户隔离、隐私和灾备，而不只画一条写入链路。
可靠性与扩展
要说明登记幂等、批量验证、读取证明、跨区域复制和审计重放，处理高发布量与依赖方瞬时查询。
回答前需要澄清的问题
- 声明只服务软件制品，还是也包含硬件、模型和部署环境？
- 登记服务是单一组织运营，还是多个租户共享并可互相验证？
- 消费者要求强一致读取，还是允许看到“已登记但证明尚未同步”的状态？
- 哪些字段属于敏感信息，是否只公开摘要、时间和签发者标识？
- 撤销是撤销密钥、声明，还是仅更新策略判断？
- 目标吞吐、证明保留年限和跨区域恢复点分别是多少？
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 秒框架和故障追问，帮助候选人展示取舍而非背诵术语。