C10
用签名透明日志给学校软件采购生成“更新来源收据”
Signed Update-Provenance Receipts for School Software Procurement
1 · 创新命题
中 面向没有安全团队的学校 IT 采购者，做一个更新来源收据：检查下载包哈希、发布签名、构建 provenance 与透明日志记录，把“官网下的应该没问题”变成可核实的证据链，并对缺失环节明确显示 unknown； 相对要求管理员阅读 Sigstore/SLSA 原始证明，收据只回答“谁发布、对应哪个源码、何时记录、哪一步缺证”。 EN A software-update provenance receipt for school IT buyers that verifies hashes, signatures, build provenance and transparency-log entries, translating Sigstore/SLSA evidence into four plain questions: who released it, which source it came from, when it was logged, and what remains unknown.
2 · 背景与空白
Sigstore cosign/Rekor、SLSA provenance 和 in-toto 已提供签名与供应链证明；Homebrew、GitHub Actions 等 生态的采用程度不同，需逐项目核实。GUAC 聚合供应链元数据，企业平台也提供策略，但小学校采购者很少 能解读 DSSE、OIDC 身份和 transparency inclusion proof。空白在：不是新密码学，而是把可验证证明 映射为采购工作流的“证据/未知/失败”收据，并测试普通 IT 人员是否少做错误信任决策。
3 · 可检验假设
H1 对 ≥ 40 个公开软件发布物，收据对有效签名、错误身份、哈希篡改、缺失日志四类状态的判定 与 cosign verify/人工专家标签一致率 ≥ 95%，篡改样本召回 100%。 H2（采纳）≥ 10 名学校/非营利 IT 志愿者使用收据后，对 12 个采购情景的正确允许/隔离/拒绝决策 提高 ≥ 30 个百分点，完成时间不增加超过 25%。
4 · 量化验收标准
- 【方法学校验 · 硬门槛】 用自建验证器复现 Sigstore cosign 官方至少 12 个签名、身份约束、 Rekor inclusion 与篡改失败算例，退出状态和证据字段 100% 一致。此条不过，后续全部结论无效。
- ≥ 40 个固定版本发布物，含有证明、部分证明和无证明三组；不把“无证明”自动判为恶意。
- 不平衡异常判定报 PR-AUC、篡改召回、错误拒绝精确率，明确不报 accuracy；按软件项目划分， 同项目版本不得跨集。
- 对哈希篡改、签名者替换、过期证书/身份、日志不可用做故障注入；离线缓存必须显示新鲜度。
- 基线为 cosign 原始 CLI 与人工 checklist；用户研究只记录决策，不收集学校真实采购数据。
5 · 数据与工具
| 用途 | 来源 / 工具 |
|---|---|
| 验证 | Sigstore cosign、Rekor 公共日志；网络不可用时只能验证缓存证据 |
| 标准 | SLSA provenance、in-toto attestation、DSSE；支持范围需限定并逐项核实 |
| 样本 | Sigstore 官方 examples、公开 GitHub Releases/容器镜像 —— 官方 examples 仅用于校验 |
| 原型 | 本地 CLI + 静态 HTML/PDF 收据；不托管二进制 |
| 用户 | 学校 IT、图书馆或非营利组织志愿者；人数不足则标“需核实”而非编造 |
能力边界：有效签名只证明某身份签了某物，不证明软件无恶意。致命错误是把 provenance 写成安全 认证；收据必须把“来源已验证”和“内容已审计”分成不同字段。
采购情景必须包含两种容易误判的反例：一个无公开证明但来自可核实传统签名渠道的正常软件，以及一个 证明完整但权限需求与学校用途不符的软件。只有用户能把“来源证据”“功能适配”“内容安全”分开， 收据才没有制造新的自动信任。证明服务器临时不可达时显示待复核，不得把网络故障当篡改。 每张收据还要保存验证器版本、信任根、身份约束与 Rekor 索引；否则数月后无法解释“当时为何通过”。 密钥轮换和项目移交应作为独立情景，旧身份签名不能因维护者更换就自动变成恶意。 收据措辞须经目标用户复述测试，无法复述的术语一律改写或附解释。
6 · 赛季执行路径
- 第 1–2 周：12 个 cosign 算例，完成硬门槛。
- 第 3 周：冻结威胁模型和收据四问；第 4 周接 SLSA/in-toto。
- 第 5–6 周：40 发布物标签与四类故障注入。
- 第 7 周：按项目划分评估；第 8 周设计普通语言收据。
- 第 9–10 周：用户情景盲测；第 11 周修正措辞与缓存新鲜度。
- 第 12 周：单位经济、简述与现场演示。
7 · 新颖性边界
不声称：不发明签名、透明日志或 SLSA；不证明软件没有后门；不取代供应商尽调。 已有工作：Sigstore cosign/Rekor、SLSA、in-toto、GUAC 提供证明与聚合；GitHub Artifact Attestations 提供平台能力。本项目贡献是学校采购场景的证据翻译、未知态与用户决策验证。 护城河类型：工作流替换（D）+ 极端具体（G）；学校常用软件的已核实证明覆盖表与错误案例库是资产。
8 · go/no-go
第 3 周末：若能找到的有证明公开发布物 < 15 个，具名降级为 Sigstore 教学镜像仓库的采购情景 实验，保留证据解释主结论，不声称市场覆盖。 第 7 周末：判定一致率 < 85%，收窄为 cosign keyless 单一流程；第 10 周若正确决策提升 < 10 个百分点， 降级为机器可读审计导出，不声称改善非专家理解。