题干与适用场景
平台可以为二进制文件和容器镜像生成构建来源证明，消费者使用 CLI 验证证明与制品摘要是否匹配。安全团队要求生产部署必须验证；开发团队担心旧流水线、外部构建器和离线环境无法立即接入。请提出产品决策和发布方案，明确 Artifact Attestation 解决的风险、不能解决的风险、用户分层、默认策略、迁移路径、指标与回退。核心考察产品取舍和发布治理，因此归为 product。
面试官考察点
第一，能否把“证明存在”与“证明可信”区分开：来源声明还需要验证签名、制品摘要、工作流身份和策略上下文。
第二，能否识别不同用户的风险与能力，避免用一个强制开关覆盖个人项目、企业生产和受监管环境。
第三，能否设计渐进式迁移：观测、警告、选择性阻断、默认阻断，并保留可审计的豁免。
第四，能否用安全、开发者体验、覆盖率和业务结果衡量价值，而非只看生成证明数量。
第五，能否说明威胁模型边界，例如受损构建环境、错误策略、镜像重打包和离线验证。
回答前需要澄清的问题
- 目标客户是开源项目、普通 SaaS，还是受监管生产平台？
- 当前构建来自 GitHub Actions、第三方 CI、开发者本地，还是多种来源？
- 生产部署是否能读取在线证明，是否存在离线或隔离网络？
- 失败时允许临时豁免吗，谁批准，多久过期？
- 证明验证由平台、集群 admission，还是客户自己的流水线负责？
- 主要目标是供应链审计、阻止未授权制品，还是降低事件响应时间？
30 秒回答框架
“我先把 attestation 定义为可验证的构建来源信号，而非自动保证源码安全。按风险和迁移能力把客户分为生产关键、普通生产、开发和外部构建四层；先提供观测与警告，再对高风险生产默认阻断，支持带原因和期限的豁免。指标同时看有效验证覆盖率、误阻断率、部署延迟、豁免率和供应链事件处置时间。对受损构建环境、重打包和离线验证单独设计威胁模型，灰度期间保留快速回退与审计。”
分步骤深入解答
第一步：定义用户问题和信任边界
Artifact Attestation 将制品摘要与构建来源绑定，帮助消费者判断制品由哪个工作流、提交和构建环境产生。它不能证明源码没有漏洞，也不能自动修复被攻陷的构建器。产品文案和策略必须把 provenance、签名验证、漏洞扫描与部署授权分开表达。
第二步：建立用户分层
把生产关键服务、普通生产服务、开发预览和外部贡献者分开。生产关键服务通常需要强验证和短豁免；开发环境更看重反馈速度；外部构建可能只能提交证明包或使用受信任的重建流程。分层决定默认策略、支持成本和迁移顺序。
第三步：设计验证闭环
生成端在构建完成后写入证明，消费端按制品摘要验证，并检查工作流仓库、提交、分支、构建器和签发者是否满足策略。验证结果应返回可操作原因，例如缺少证明、摘要不匹配、来源不在允许集合或证明已过期，而不是只有一个布尔值。
第四步：规划渐进式策略
先以只读方式统计覆盖率和失败原因；第二阶段对非生产环境发出警告；第三阶段对选定生产服务阻断；第四阶段扩大到默认阻断。每阶段设退出条件，包括误阻断率、验证延迟、旧流水线迁移率和支持工单量。豁免需要负责人、原因、范围和过期时间。
第五步：处理多种构建来源
GitHub Actions 可以直接生成证明，但第三方 CI、外部构建器和离线构建需要导入证明或采用受信任签发流程。产品要提供清晰的证据格式、摘要绑定和验证命令，避免用户误以为上传一个 JSON 文件就等于可信证明。
第六步：定义指标与护栏
核心指标包括生产制品有效验证覆盖率、未授权制品阻断率、误阻断率、部署延迟 p95、迁移完成时间和豁免到期率。护栏包括构建失败率、回滚耗时、支持工单、离线客户阻断数和安全事件中的证明可用率。证明生成数量只能作为使用量指标，不能代表安全效果。
第七步：准备灰度和回退
按组织、仓库或服务逐步开启，保留策略版本和每次决策日志。若验证服务不可用，应区分 fail-closed 与受控 fail-open：生产关键路径可短时阻断并提供人工审批，低风险环境可记录后继续。回退只撤销强制策略，不删除已有证明和审计记录。
高质量示范回答
“我会把产品目标定为阻止来源不符合策略的制品进入生产，而不是宣称证明能保证代码安全。先按风险和构建能力分层，针对 GitHub Actions、第三方 CI、离线构建分别提供证据路径。发布采用观测、警告、选择性阻断、默认阻断四阶段，只有在误阻断率、部署延迟和迁移率达标后扩大范围。验证结果要解释缺少证明、摘要不匹配、来源不允许等原因；豁免必须有审批、期限和审计。核心指标是有效验证覆盖率、未授权制品阻断率、误阻断率和事件处置时间，并为验证服务故障设计受控回退。”
常见错误
- 把证明数量当安全效果 → 可能生成大量无效或未验证证明 → 衡量有效验证和阻断结果。
- 第一天全量强制 → 旧流水线和离线客户被同时阻断 → 采用分层灰度与迁移窗口。
- 只验证签名不看来源策略 → 任意受信任签发者都可能通过 → 检查工作流、提交、仓库和构建器。
- 把 provenance 当漏洞扫描 → 用户误解保护范围 → 分开表达来源、漏洞和授权控制。
- 没有可解释失败原因 → 开发者无法修复 → 返回结构化原因和修复链接。
- 豁免永久有效 → 强制策略逐渐失效 → 限定范围、审批人和过期时间。
- 忽略验证服务故障 → 一次故障造成大面积发布中断 → 定义 fail-closed、受控 fail-open 和回退。
- 只支持单一 CI → 多源构建用户无法迁移 → 提供导入、证明包和受信任签发路径。
追问及应对
追问一：证明能否证明代码没有被篡改？
它能把制品摘要与声明的构建来源绑定，并让消费者验证两者是否匹配；它不能证明构建环境、依赖或源码绝对安全，需要结合权限、扫描和可复现构建。
追问二：为什么不直接全量 fail-closed？
客户能力、构建来源和网络条件不同。全量阻断可能制造业务中断并促使团队关闭策略；先观测和灰度可以用真实失败数据校准规则。
追问三：如何衡量误阻断？
记录每次阻断的原因、服务、策略版本和后续人工批准；将确认的合法制品恢复率与总阻断量结合，按客户层级观察，不把所有豁免都视为误报。
追问四：离线客户如何验证？
允许下载证明包和必要的信任根，在隔离环境本地验证制品摘要与来源；产品要明确信任根更新、撤销和证明过期处理。
追问五：如果构建器被攻陷怎么办？
证明只能说明声明的来源，不能自动证明来源未被攻陷。应限制工作流权限、使用隔离构建器、轮换签发身份，并把异常来源和策略变更纳入监控。
追问六：如何避免豁免成为常态？
把豁免设为有期限的异常，显示到期倒计时和责任人，按团队统计到期率与重复原因；持续修复迁移缺口，而不是永久放宽规则。