# HDGP 内核自查清单与测试设计 > 本文档用于社区基线发布前内核完善度检查及后续审计/测试设计，与《HDGP 自身伦理框架基线》第七节（防挟持）及《GOVERNANCE》基线原则/伦理变更多层治理一致。 > 使用方式：逐项勾选或标注 N/A，并可在“测试方案”下补充具体用例与自动化脚本。 --- ## 一、文档与表述一致性 | # | 检查项 | 参考文档 | 状态 | |---|--------|----------|------| | D1 | 全文与各节“保留补充权利”已在伦理基线开篇写明 | `HDGP_ETHICS_BASELINE.md` | ☑ | | D2 | 所有“HDGP 不是被监管对象”已改为“HDGP 亦为被监管对象，接受自我审计与人类社会监管” | 全仓库检索 | ☑ | | D3 | 基线原则/伦理/关键规则变更采用“多层治理”（系统自检 → 责任方 → 公告/公投），且“至少两名签署”不作为唯一门槛 | `GOVERNANCE.md` §6；`HDGP_ETHICS_BASELINE.md` §8 | ☑ | | D4 | 基线原则与伦理基线修改须公告时间窗、全球可收悉、可反馈，且多数决不足以保证通过 | `GOVERNANCE.md`；伦理基线 §8 | ☑ | | D5 | 关键规则变更须有“能承担法律后果”的指定责任人，且事后极端事件须有责任方 | `GOVERNANCE.md`；伦理基线 §8 | ☑ | --- ## 二、防挟持能力（伦理基线 §7） ### 2.1 只读内核与隔离（§7.1） | # | 检查项 | 建议落点 | 状态 | |---|--------|----------|------| | A1 | 内核代码与规则包的“只读来源”已约定（如只读挂载/镜像发布，运行实例不可在线写入） | `docs/HDGP_READONLY_POLICY_SOURCE_SPEC.md` | ☑ | | A2 | 生产环境禁用动态加载任意代码、不提供脚本/规则注入入口 | 部署文档、Engine 实现 | ☑ 实现已满足；部署文档待补 | | A3 | Engine 与外部仅通过限定 HTTP/JSON 端点交互，无任意 RPC/Exec | API 规范、代码审计 | ☑ | ### 2.2 密码学与多签（§7.2） | # | 检查项 | 建议落点 | 状态 | |---|--------|----------|------| | B1 | 规则包 schema 预留签名字段（公钥标识、签名值、算法） | `HDGP_CORE_MAPPING_SPEC` / 规则包格式 | ☐ | | B2 | 规范明确：加载规则包必须做签名校验，校验失败一律拒绝加载 | `spec/HDGP_POLICY_BUNDLE_VERIFICATION_REQUIREMENTS.md` | ☑（规范层） | | B3 | 治理文档明确“谁有权签名、须多签、记录至伦理 changelog” | `GOVERNANCE.md` | ☐ | ### 2.3 自我报警（§7.3） | # | 检查项 | 建议落点 | 状态 | |---|--------|----------|------| | C1 | “期望版本/签名清单”来源已定义（如配置、信任根） | `docs/HDGP_TRUST_SOURCE_AND_EXPECTED_VERSION_SPEC.md` | ☑ | | C2 | `GET /hdgp/v1/status` 返回的 `engine_version`、`policy.bundles` 真实反映当前加载状态 | 实现、API 规范 | ☑ | | C3 | 审计日志 schema 预留“完整性异常/挟持尝试”类字段（如 `integrity_events`） | `docs/HDGP_INTEGRITY_EVENTS_SCHEMA_SPEC.md` | ☑（规范层） | | C4 | 规范要求：严重完整性异常时 Engine 可拒绝服务或进入熔断/降级 | 伦理基线 §7.3、Engine 设计 | ☑ 规范已写明；实现待后续 | ### 2.4 制度与多实现（§7.4） | # | 检查项 | 建议落点 | 状态 | |---|--------|----------|------| | E1 | README/GOVERNANCE 鼓励多实现、多机构部署，反对“唯一官方实现”垄断叙事 | `README.md`、`GOVERNANCE.md` | ☑ | | E2 | 认证/品牌规范（若存在）预留：不得以合同禁止用户运行平行 HDGP 实现做交叉校验 | 认证规范草案 | N/A 认证规范尚未成立，成立时补入 | --- ## 三、数据与隐私（与防挟持相关） | # | 检查项 | 建议落点 | 状态 | |---|--------|----------|------| | P1 | 审计日志中用户/机构标识的脱敏规则已明确，防止防挟持机制被滥用为监控 | 数据规范、伦理基线 | ☐ | | P2 | 日志保留策略区分：完整性事件日志（可长保）与用户行为细节（限期删除或匿名化） | `docs/HDGP_AUDIT_DATA_RETENTION_POLICY.md` | ☑ | --- ## 四、治理流程（基线原则/伦理/关键规则） | # | 检查项 | 建议落点 | 状态 | |---|--------|----------|------| | G1 | 变更提案须经“系统自检”：与当前伦理基线比对，违背则挂起，由发起人修正或撤销 | `GOVERNANCE.md` §6；流程说明 | ☑ | | G2 | 关键规则变更须指定“实际负责人”（能承担法律后果的自然人），并在 changelog 中记录 | `GOVERNANCE.md` §6 | ☑ | | G3 | 基线原则/伦理基线修改须公告至少一个时间窗，全球用户可收悉并可反馈 | `GOVERNANCE.md` §6 | ☑ | | G4 | 基线原则/伦理基线修改可设公投；且“投票过半”不足以保证通过（如设超多数或双重多数） | `GOVERNANCE.md` §6 | ☑ | | G5 | 紧急变更仍须在时限内走复核；未评估风险/漏洞的须在责任方环节修补 | `GOVERNANCE.md` §6 | ☑ | --- ## 五、测试方案设计 ### 5.1 自动化 / 可重复测试 | 测试目标 | 方法 | 测试用例/脚本 | 状态 | |----------|------|----------------|------| | 状态端点一致性 | 调用 `GET /hdgp/v1/status`，校验 `engine_version`、`spec_version`、`policy.bundles` 与代码/配置一致 | `conformance-tests/cases/005_status.json`；`hdgp-conftest` 支持 `type: "status"` | ☑ | | 规则评估与触发记录 | 使用既有 conformance 用例，对 `/hdgp/v1/evaluate` 跑全量用例，校验 verdict 与 `rules_triggered` | `conformance-tests/cases/*.json`（含 evaluate 与 status）；见下方运行命令 | ☑ | | 规则冲突优先级 | 构造同时触发两条规则的请求，校验 verdict 为 modify 且两条规则均出现在 `rules_triggered` | `conformance-tests/cases/006_rule_conflict_priority.json` | ☑ | | 无规则注入入口 | 静态/人工审计：确认无 API 或配置项可在运行时注入、覆盖或追加规则 | `scripts/audit-no-rule-injection.ps1` + `docs/audit-reports/NO_RULE_INJECTION_AUDIT.md` | ☑（自动扫描+人工复核） | **运行命令**（需先启动 Engine）：`go run ./cmd/hdgp-engine` 后，在另一终端执行 `go run ./cmd/hdgp-conftest`。可选环境变量 `HDGP_ENGINE_URL=http://localhost:8080/hdgp/v1/evaluate`。 ### 5.2 人工 / 审计测试 | 测试目标 | 方法 | 测试用例/脚本 | 状态 | |----------|------|----------------|------| | 文档与 checklist 一致 | 用本文档第一节至第四节逐项检查，并更新 GAPS 文档中对应项状态 | `docs/HDGP_MANUAL_AUDIT_CONSISTENCY_TEMPLATE.md` | ☑（模板已落地） | | 防挟持红队思路 | 设想场景：篡改内存/配置、伪造 status、截断审计日志；检查是否有缓解与检测 | `docs/HDGP_REDTEAM_HIJACK_SCENARIOS_TEMPLATE.md` | ☑（模板已落地） | | 治理流程走通 | 模拟一次“基线原则/伦理基线修订提案”：自检 → 责任方指定 → 公告时间窗 → 反馈汇总；检查文档是否足以执行 | `docs/HDGP_GOVERNANCE_WALKTHROUGH_TEMPLATE.md` | ☑（模板已落地） | ### 5.3 后续可补充 - 独立“外部完整性自检”小工具：读 `/status` + 规则包签名，与期望清单比对（如 `scripts/check_integrity.sh` 或独立 CLI）。 - 在 GAPS 中明确“防挟持红队演练”为定期动作，并记录在治理或发布流程中。 --- ## 六、总览勾选表（快速核对） 社区基线发布前或发布前，可按下列 ID 逐项勾选，确保无遗漏。 | 类别 | 检查项 ID | 状态 | |------|-----------|------| | 文档与表述 | D1, D2, D3, D4, D5 | ☑ ☑ ☑ ☑ ☑ | | 防挟持·只读与隔离 | A1, A2, A3 | ☑ ☑ ☑（A1 规范已落地） | | 防挟持·密码学与多签 | B1, B2, B3 | ☐ ☑ ☐（B2 规范已落地，工程侧必选加载待下一步） | | 防挟持·自我报警 | C1, C2, C3, C4 | ☑ ☑ ☑ ☑（C1/C3 规范已落地，工程必选落地持续推进） | | 防挟持·制度与多实现 | E1, E2 | ☑ N/A（E2 认证规范成立时补入） | | 数据与隐私 | P1, P2 | ☐ ☑（P2 分层留存策略已落地） | | 治理流程 | G1, G2, G3, G4, G5 | ☑ ☑ ☑ ☑ ☑ | | 自动化测试 | 5.1 状态 / evaluate / 规则冲突 / 无注入 | ☑ ☑ ☑ ☑（无注入脚本已落地） | | 人工/审计测试 | 5.2 文档一致 / 红队 / 治理走通 | ☑ ☑ ☑（模板化已完成，按轮次执行） | --- ## 七、使用与更新 - **社区基线发布前**：至少完成第一节至第四节全部勾选（或明确标注 N/A 及理由），并跑通 5.1 中已有 conformance 与 status 相关测试。 - **每次涉及基线原则/伦理/关键规则或防挟持实现的变更**：复核本清单相关项并更新状态。 - **发现新缺口**：在对应节增加一行检查项，并在 `HDGP_GAPS_AND_CONSIDERATIONS.md` 中同步。 - **发布前执行入口**：优先按 `docs/HDGP_RELEASE_AUDIT_ONEPAGE.md` 执行 TM-A1/TM-A2/TM-A3，并留存本轮报告。 本文档与伦理基线、GOVERNANCE、GAPS 保持一致，随项目演进更新。 --- ## 八、威胁模型落地映射（下一轮可执行清单） > 目的：将“威胁模型落地计划”直接映射为可勾选执行项。 > 关联：`docs/HDGP_THREAT_MODEL_ROLLOUT_PLAN_INTERNAL.md`、`docs/HDGP_EXTERNAL_MESSAGING_TEMPLATES.md`。 ### 8.1 工程控制项（优先） | ID | 执行项 | 关联现有项 | 验收标准 | 状态 | |----|--------|------------|----------|------| | TM-E1 | 认证验签保持 fail-closed（缺公钥源/验签失败均拒绝） | B2, C4 | `/cert/verify` 在缺失 `HDGP_CERT_PUBLIC_KEYS_PATH` 时 `signature_valid=false` 且 `logo_allowed=false` | ☑ | | TM-E2 | 完整性事件标准化：关键失败类型稳定输出（key 缺失/签名失败/格式错误） | C3, C4 | `integrity_events.kind` 在上述场景均可复现且字段一致 | ☑ | | TM-E3 | 公开查询端点最小防护（限流或上游来源限制要求） | SH-A2, C1 | 文档明确公网部署必须经反向代理/WAF；并支持 `/cert/verify` 独立限流与来源白名单 | ☑ | | TM-E4 | 基线原则侧反篡改检查点（规则来源、版本、签名状态）纳入启动/发布检查 | A1, B1, B2, C1 | 启动日志输出完整性检查结果，并支持 `HDGP_STARTUP_INTEGRITY_STRICT=true`（兼容旧名 `HDGP_STARTUP_INTEGRITY_ENFORCE`）时失败阻断启动 | ☑ | ### 8.2 口径与展示项（必须同步） | ID | 执行项 | 关联现有项 | 验收标准 | 状态 | |----|--------|------------|----------|------| | TM-M1 | UI 显式声明：认证查询=技术/流程状态，非官方审计结论 | D1, D2 | 首页认证查询面板可见声明文案 | ☑ | | TM-M2 | 文档显式声明：认证≠法律担保/保险承诺 | D1, D2 | README + 对外说明文档 + FAQ 口径一致 | ☑ | | TM-M3 | 标准对齐表述固定为“aligned with/informed by” | D1, D2 | 对外模板不出现“已获官方认证”误导表达 | ☑ | ### 8.3 审计与治理项（持续） | ID | 执行项 | 关联现有项 | 验收标准 | 状态 | |----|--------|------------|----------|------| | TM-A1 | 每轮发布做“口径一致性审计”（UI、README、FAQ） | 5.2 文档一致 | 形成一份审计记录（可简版）；已产出 `docs/HDGP_MESSAGING_CONSISTENCY_AUDIT_2026-03-20.md` | ☑ | | TM-A2 | 每轮发布做“完整性事件抽样审计” | 5.2 红队思路 | 至少覆盖 3 类失败场景并留存结果；已产出 `docs/HDGP_INTEGRITY_EVENTS_SAMPLING_AUDIT_2026-03-20.md` | ☑ | | TM-A3 | 治理流程抽样演练：基线原则/关键规则变更走通一次 | G1–G5, 5.2 治理走通 | 演练记录可复核，含责任人与时间窗；已产出 `docs/HDGP_GOVERNANCE_DRILL_RECORD_2026-03-20.md` | ☑ | ### 8.5 G2 收尾证据（本轮） - 运行时心跳演练证据：`docs/audit-reports/HEARTBEAT_DRILL_2026-03-20_08-54-22.md`（PASS）。 - G2 完成快照：`docs/HDGP_G2_COMPLETION_SNAPSHOT.md`。 - 说明：当前 G2 已形成“哈希链 + 心跳 + 混沌演练 + 合规状态端点 + 沙箱未授权计数”的最小闭环。 ### 8.6 G3 收尾证据（本轮） - G3 完成快照：`docs/HDGP_G3_COMPLETION_SNAPSHOT.md`。 - 故障注入回归：`docs/operations/2026/Q1/release-gate/G3_FAILURE_INJECTION_REPORT_20260320194630.md`（10/20/30/40 全部 PASS）。 - 留存治理证据：`docs/operations/2026/Q1/evidence/RETENTION_DRY_RUN.md`、`docs/operations/2026/Q1/evidence/RETENTION_APPLY.md`、`docs/operations/2026/Q1/evidence/STORAGE_SUMMARY.md`。 - 说明：当前 G3 已形成“发布门禁强约束 + 红蓝演练 + 签名配置激活 + 证据索引 + 留存治理”的持续运营闭环。 ### 8.4 下一轮执行顺序（建议） 1. TM-E3 -> 2. TM-E4 -> 3. TM-A1 -> 4. TM-A2 -> 5. TM-A3 > 说明：TM-E1/2、TM-M1/2/3 已落地，下一轮重点补齐“公开面防护 + 基线原则侧检查点 + 审计节奏”。