SECURITY
安全说明 / how this is built & how to report issues
写给做供应商安全审查的人。下面每一条都对应可当场验证的机制，不是安全承诺书式的形容词。逐条给出验证方法。
1 · 账本完整性 / ledger integrity
| 机制 | 验证方法 |
|---|---|
| Append-only 哈希链：每条记录带 prev_hash / hash / global_hash，任何人（包括运营方）不能改、不能删 | 下载 公开账本 registry.jsonl，本地重放全链哈希 |
| 每日比特币锚定：链头每日经 OpenTimestamps 写入比特币区块链；已确认的凭证内含区块高度与该区块的 merkle root | GET /v1/anchors 取 bitcoin_block → ots info <file> 离线读 attestation → 用区块浏览器核对同高度的 merkle root（详见 /anchors） |
| 报告签名：核验报告带 ed25519 签名 + 内容哈希 | 报告页「验签通过」可独立复算（公钥与算法在报告页脚给出） |
| 自助申报隔离：公开写入的申报（/v1/declare）归类 declared，不计入真实观测、不参与行情统计、不能使法律用途过闸门 | resolve 输出的 data_quality 块分列 real / declared 计数 |
2 · 数据最小化 / data minimization
3 · 接口防护 / API posture
公开写入按 IP 限频（申报 12 条/小时、遥测 60 条/小时）；高价值写入（抵押登记 / 生命周期事件 / 升级）要求 trustee 密钥；设备侧动作（认领 / 密钥轮换）要求设备私钥签名——防冒充的核心不是口令，是「签名只有持钥者能给」。查询侧零鉴权、零 Cookie、无第三方追踪器。
4 · 漏洞披露 / disclosure
发现安全问题请走 security.txt（RFC 9116，含联系与加密通道）。我们承诺：① 报告 72 小时内人工确认；② 修复前不公开细节；③ 修复后在 治理页如实记录（selftest 与部署检查的失败记录也原样保留在台账——包括我们自己断言写错触发回滚的那些）。历史例证：公开写入通道的注入测试串曾被如实写入台账（只增不减），随后在写入口加了消毒——错误不删除，修正可见。