LifeOS ThreatModel 技能实战用确定性 CLI 运维持久化风险登记册 RiskRegister【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS风险登记册Risk Register是安全威胁建模闭环里的长期账本SensitiveDataMap 回答数据在哪里CompromiseScenario 回答被攻破会发生什么而 RiskRegister 负责把每一笔真实风险记录、打分、分配责任人、设置评审日期并持续滚动评审——让风险被看过而不是被忘记。本文基于 LifeOS 开源仓库中的 RiskRegister.md 与配套 CLI 源码 RiskRegister.ts 展开读完你将掌握注册表的数据目录与安全边界设计、全部子命令与参数语义、likelihood×impact 评分体系、以及从录入到评审到关闭的完整运维节奏。一、RiskRegister 的定位威胁建模工作流的收口账本在 LifeOS 的 ThreatModel 技能见 SKILL.md中共编排了四个工作流RiskRegister 是其中的收口环节工作流触发意图产出SensitiveDataMap我们的敏感数据在哪EstateDataMap.md数据分类地图CompromiseScenario如果 X 被攻破会怎样场景文档 落库的风险条目ThreatModelTarget对 X 做威胁建模目标威胁模型 分级风险RiskRegister加一条风险 / 做风险评审 / 接受 / 关闭风险持久化风险登记册从源码结构看RiskRegister 是唯一一个长期有状态的组件其他工作流的产出是一次性文档而风险条目会跨会话存活等待下一次review。这也是为什么它被单独做成一个确定性 CLI——文档中明确强调 no model judgment in the data path即数据路径上不允许模型自由发挥所有写入、改分、状态变更都必须经过固定参数的命令完成保证账本可审计、可复现。数据目录默认位于用户私有树~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/在 LifeOS 中该 USER 树发布时被排除参见 SECURITY/README.md可通过环境变量THREATMODEL_DATA_DIR覆盖。二、代码与数据分离数据目录的安全边界RiskRegister 最核心的安全设计是代码与数据严格分离。在 RiskRegister.ts 中resolveDataDir()的解析逻辑为export function resolveDataDir(): string { const dir resolve( process.env.THREATMODEL_DATA_DIR ?? join(homedir(), .claude, LIFEOS, USER, SECURITY, THREATMODEL), ); // Structural code/data separation: never allow the register inside a skill tree. const probe existsSync(dir) ? realpathSync(dir) : dir; if (probe.split(sep).includes(skills)) { console.error(ERROR: data dir ${probe} is inside a skills/ path — code and data stay separate. ...); process.exit(2); } return dir; }要点解读优先级THREATMODEL_DATA_DIR环境变量优先未设置时回退到默认的 USER 私有路径结构校验解析结果若落在任何skills/目录下直接以退出码 2 拒绝运行。原因很直白——技能目录是公开代码仓库发布时随项目分发而风险登记册包含你个人资产的信息必须留在私有 USER 树中注册表的数据路径一旦确定会同时承载risk-register.json系统记录源与生成视图RiskRegister.mdinit还会在该目录下额外创建Scenarios/子目录对应 init 分支供 CompromiseScenario 工作流存放场景文档。三、存储模型JSON 是唯一事实源Markdown 只是生成视图init后数据目录内会生成risk-register.json其结构对应 Store 与 Risk 接口如下{ version: 1, updated: 2026-09-15T00:00:00.000Z, risks: [] }每一条Risk记录的字段与约束字段类型说明idstring自动编号R-001、R-002…由 nextId() 基于现有最大编号递增生成titlestring风险短标题add必填threatstring威胁描述add必填assetsstring[]受影响资产如 Atlas key、域名、工作节点data_classesstring[]涉及的数据分类沿用 SensitiveDataMap 的分类credentials、pii、financial、health、customer-data、source-private、internal-only、publiclikelihood/impactnumber1–5 整数越界会被 scoreRisk() 直接抛错scorenumberlikelihood × impact自动计算levelstringLow / Medium / High / Critical由 score 推导statusstringopen/mitigating/accepted/closedownerstring责任人可为空但评审时会被标记mitigationsstring[]缓解措施列表responsestring响应计划/场景文档引用如Scenarios/asset-slug.mdnotesstring备注接受风险时写理由created/updatedstringISO 时间戳每次变更自动刷新updatedreview_bystringISO 日期评审截止日history{ts,event}[]不可变审计轨迹记录每次创建/更新/关闭事件risk-register.json是系统记录源system of record而数据目录下的RiskRegister.md只是 exportMarkdown() 生成的视图包含 Open 表按 score 降序、Closed 表按更新时间降序以及每条未关闭风险的详情代码块文件头明确标注 GENERATED by ThreatModel/Tools/RiskRegister.ts — edit via the CLI, not here。任何add/update/close成功后都会自动重新生成该视图因此永远不要手改 Markdown否则下次写入即被覆盖。四、完整命令参考八个子命令逐一拆解CLI 本体是 RiskRegister.ts以 bun 运行。建议先设置别名Tbun ~/.claude/skills/ThreatModel/Tools/RiskRegister.ts4.1init— 初始化数据目录与空登记册$T init # 输出: Initialized ~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/ (0 risks)创建Scenarios/子目录、写入空的risk-register.jsonversion 1并生成初始RiskRegister.md视图。4.2add— 新增风险--title与--threat必填缺失时程序报错并以退出码 1 终止见 add 分支$T add --title Analytics worker has no auth on its KV \ --threat Unauthenticated read of customer-data KV \ --assets analytics-worker,cust-kv \ --data-classes customer-data,pii \ --likelihood 4 --impact 4 \ --owner you \ --mitigation Restrict KV to VPC \ --response Scenarios/analytics-worker.md \ --review-by 2026-10-15参数说明--assets a,b、--data-classes x,y逗号分隔列表源码中经 list() 拆分、去空格、过滤空项--mitigation可重复出现多次构成缓解措施数组--likelihood/--impact必须为 1–5 整数scoreRisk()会在计算前校验否则抛出must be an integer 1-5--status可选默认open取值必须是四种状态之一--review-by建议在创建时即给出约束见后文--notes追加备注。4.3list— 查看开放风险$T list # 未关闭风险score 降序 $T list --all # 包含已关闭 $T list --level Critical # 仅过滤某等级 $T list --status mitigating $T list --json # 机器可读输出默认行为只显示非closed的风险并按 score 降序排序加--status会做精确状态过滤--level不区分大小写匹配等级见 list 分支。行内格式为R-001 [Critical ] 16 open review:2026-10-15 Analytics worker has no auth on its KV4.4show id— 查看单条详情$T show R-001 $T show r-001 # ID 匹配不区分大小写 $T show R-001 --json输出完整字段含 mitigations 逐条列出、response 引用、评审/创建/更新时间、notes。ID 不存在时报错并以退出码 1 终止见 findRisk()。4.5update id— 更新与重新打分$T update R-001 --likelihood 5 --impact 5 # 重打分自动重算 score/level $T update R-001 --status mitigating --owner you $T update R-001 --add-mitigation Rotate KV token # 追加缓解措施 $T update R-001 --review-by 2026-12-01 # 顺延评审日期 $T update R-001 --title ... --threat ... $T update R-001 --response Scenarios/new.md --notes ...可更新字段覆盖title、threat、owner、response、notes、review-by、status、likelihood、impact、assets、data-classes其中--likelihood或--impact任一出现即触发重新打分未传的一方沿用原值--add-mitigation可重复追加。每次更新都会在history中追加一条updated: 变更摘要事件见 update 分支。4.6close id— 关闭风险$T close R-002 --reason Control implemented: KV now VPC-restricted and audited--reason必填缺失时报错退出见 close 分支。关闭后状态变为closed并从list默认视图中隐藏历史轨迹记录closed: reason。4.7review— 找出到期/缺失评审日期的风险$T review # 按 score 降序列出所有 overdue $T review --json判定逻辑见 review 分支未关闭 且review_by为空 或review_by 今天的风险按 score 降序输出缺失评审日期的行尾追加(no review date)标记。无到期项时输出(nothing due for review)。4.8stats— 姿态快照$T stats # 输出 total / open / byLevel / byStatus / overdue_review / updated / data_dir $T stats --jsonbyLevel按 Critical/High/Medium/Low 统计开放风险byStatus按四种状态统计全量overdue_review统计到期未评审数量见 stats 分支。这是回答我们现在有多少个 Critical的唯一权威命令。4.9export— 重新生成 Markdown 视图$T export # 输出: Wrote ~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/RiskRegister.md正常流程下无需手动执行——每次数据变更都会自动触发此命令用于数据目录被手动恢复或视图被误删后的重建。五、意图到命令映射一句话触达任意操作原文档给出的映射表完整复刻如下这也是日常通过对话驱动本工作流时的标准翻译用户说执行命令加一条风险、记下这个风险add --title … --threat … --likelihood N --impact N [--assets a,b --data-classes x,y --owner O --mitigation M --response REF --review-by DATE]我们有哪些风险、展示登记册list加--all包含已关闭加--level Critical过滤跑一次风险评审、哪些过期了review更新 / 重新评分 R-001update R-001 [--likelihood N --impact N --status S --add-mitigation M --owner O --review-by DATE]接受 R-001update R-001 --status accepted --notes accepted by owner: rationale关闭 / 退役 R-001close R-001 --reason …姿态快照、有多少个 Criticalstats六、评分体系likelihood × impact 的五级量化评分公式与分档文档原文 levelFor() 的边界实现完全一致score likelihood(1-5) × impact(1-5) Low 1-4 · Medium 5-9 · High 10-14 · Critical 15-25scoreRisk()在校验时要求两个因子都是 1–5 的整数Number.isInteger检查浮点与越界直接抛错分档实现score 15→ Critical 10→ High 5→ Medium否则 Low分档的语义锚点见 CompromiseScenario.mdimpact 不按资产规模而按暴露了什么 能触达什么打分——5 分对应可触达多系统的凭据、大规模客户数据或金融/健康 PII4 分对应可触达单个含数据系统的凭据或私有数据存储以此类推likelihood 依据暴露面公网 URL、认证边界、补丁/凭据卫生、现有检测手段估算。七、安全约束四条不可妥协的护栏原文档明列的四条约束是使用本工具的前提逐条展开JSON 存储是唯一事实源RiskRegister.md只是生成视图——绝不手改 Markdown任何数据变更必须走 CLI下次任何写入都会覆盖手改内容。禁止写入任何秘密值——凭据只能以环境变量名形式引用如$DATABASE_TOKEN绝不存 token、key、cookie 本身。这既是本工作流的硬约束也贯穿整个 ThreatModel 技能见 SKILL.md 的 Data/Code Separation 一节。每条风险必须有review_by——没有评审节奏的登记册比没有更糟它制造假的安全感false assurance。创建即带评审日定期review处理过的风险顺手把日期向前推。接受accept是一种决策不是删除——用--status accepted--notes写明accepted by owner: rationale让被接受的风险保持可见、可追溯而不是从账本上消失。八、评审节奏让登记册活起来review只是列出该看的真正的评审是人的决策。原文档给出了标准操作流程执行$T review拉出到期清单含缺失评审日期的逐条走处置三问仍然成立已被缓解还是应该接受——成立则保留并重打分已缓解可追加--add-mitigation或视情况close接受则update --status accepted --notes处理完的条目把review_by向前推一个周期update R-001 --review-by 新日期对无 owner 或无缓解措施的 Critical/High 风险必须显式标记出来要求立即处理。stats中的overdue_review字段可以量化账本腐烂程度如果该值持续增长说明评审节奏没有落地。九、收尾报告一次会话结束时的标准输出完成录入/评审后按原文档要求向用户汇报三件事变更清单新增/更新/关闭的风险 ID含各自 score 与等级当前姿态来自stats的 Critical/High 数量遗留决策仍然到期、还缺人拍板的风险列表。十、与其它工作流的协作闭环RiskRegister 不是孤岛它与其他三个工作流形成闭环SensitiveDataMap输出数据分类credentials/pii/financial/health/…这些分类正是add --data-classes的取值来源未分类资产在登记时即带上了证据缺口标记CompromiseScenario写场景文档后用文档给出的标准落库命令把风险写入登记册见 CompromiseScenario.mdbun ~/.claude/skills/ThreatModel/Tools/RiskRegister.ts add \ --title short risk --threat threat \ --assets atlas-key --data-classes classes \ --likelihood 1-5 --impact 1-5 \ --response Scenarios/asset-slug.md --review-by YYYY-MM-DD \ --mitigation controlThreatModelTarget是编排层最终按分数排名、Critical/High 必须有具名 owner 和review_by的要求直接落在本登记册上见 ThreatModelTarget.md。十一、从源码看实现细节五个值得注意的行为对照 RiskRegister.ts 全文补充几个文档未明说但实际生效的行为add自动打分与自动导出add内部先调scoreRisk()计算 score/level随后saveStore()落盘并立即exportMarkdown()重建视图——所有变更命令init/add/update/close都遵循写 JSON → 重建 MD的两步模式保证视图永不过期ID 自增逻辑nextId()遍历现有编号取最大值 1因此删除/关闭不会复用旧编号审计友好list的过滤叠加--status与--level可同时使用先状态过滤再等级过滤且都作用于全量数据--all只影响是否排除 closed--json全命令支持list/show/review/stats均支持--json方便接入脚本与自动化流水线做断言参数解析器parseArgs() 要求所有 flag 以--开头布尔 flag如--all会被记为true多值 flag 取最后一次赋值——了解了这一点就能避免在 shell 别名中写出歧义参数。使用前提说明以上命令路径~/.claude/skills/ThreatModel/Tools/RiskRegister.ts与默认数据目录~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/均为 LifeOS 安装到用户主目录后的运行时约定在阅读本仓库时源码位于 LifeOS/install/skills/ThreatModel/Tools/RiskRegister.ts工作流文档位于 LifeOS/install/skills/ThreatModel/Workflows/。另外本技能定位于防御性威胁建模与风险治理不用于主动渗透测试见 SKILL.md 的 NOT FOR 边界执行时务必保持只读分析不发起任何扫描或破坏性操作。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LifeOS ThreatModel 技能实战：用确定性 CLI 运维持久化风险登记册 RiskRegister
LifeOS ThreatModel 技能实战用确定性 CLI 运维持久化风险登记册 RiskRegister【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS风险登记册Risk Register是安全威胁建模闭环里的长期账本SensitiveDataMap 回答数据在哪里CompromiseScenario 回答被攻破会发生什么而 RiskRegister 负责把每一笔真实风险记录、打分、分配责任人、设置评审日期并持续滚动评审——让风险被看过而不是被忘记。本文基于 LifeOS 开源仓库中的 RiskRegister.md 与配套 CLI 源码 RiskRegister.ts 展开读完你将掌握注册表的数据目录与安全边界设计、全部子命令与参数语义、likelihood×impact 评分体系、以及从录入到评审到关闭的完整运维节奏。一、RiskRegister 的定位威胁建模工作流的收口账本在 LifeOS 的 ThreatModel 技能见 SKILL.md中共编排了四个工作流RiskRegister 是其中的收口环节工作流触发意图产出SensitiveDataMap我们的敏感数据在哪EstateDataMap.md数据分类地图CompromiseScenario如果 X 被攻破会怎样场景文档 落库的风险条目ThreatModelTarget对 X 做威胁建模目标威胁模型 分级风险RiskRegister加一条风险 / 做风险评审 / 接受 / 关闭风险持久化风险登记册从源码结构看RiskRegister 是唯一一个长期有状态的组件其他工作流的产出是一次性文档而风险条目会跨会话存活等待下一次review。这也是为什么它被单独做成一个确定性 CLI——文档中明确强调 no model judgment in the data path即数据路径上不允许模型自由发挥所有写入、改分、状态变更都必须经过固定参数的命令完成保证账本可审计、可复现。数据目录默认位于用户私有树~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/在 LifeOS 中该 USER 树发布时被排除参见 SECURITY/README.md可通过环境变量THREATMODEL_DATA_DIR覆盖。二、代码与数据分离数据目录的安全边界RiskRegister 最核心的安全设计是代码与数据严格分离。在 RiskRegister.ts 中resolveDataDir()的解析逻辑为export function resolveDataDir(): string { const dir resolve( process.env.THREATMODEL_DATA_DIR ?? join(homedir(), .claude, LIFEOS, USER, SECURITY, THREATMODEL), ); // Structural code/data separation: never allow the register inside a skill tree. const probe existsSync(dir) ? realpathSync(dir) : dir; if (probe.split(sep).includes(skills)) { console.error(ERROR: data dir ${probe} is inside a skills/ path — code and data stay separate. ...); process.exit(2); } return dir; }要点解读优先级THREATMODEL_DATA_DIR环境变量优先未设置时回退到默认的 USER 私有路径结构校验解析结果若落在任何skills/目录下直接以退出码 2 拒绝运行。原因很直白——技能目录是公开代码仓库发布时随项目分发而风险登记册包含你个人资产的信息必须留在私有 USER 树中注册表的数据路径一旦确定会同时承载risk-register.json系统记录源与生成视图RiskRegister.mdinit还会在该目录下额外创建Scenarios/子目录对应 init 分支供 CompromiseScenario 工作流存放场景文档。三、存储模型JSON 是唯一事实源Markdown 只是生成视图init后数据目录内会生成risk-register.json其结构对应 Store 与 Risk 接口如下{ version: 1, updated: 2026-09-15T00:00:00.000Z, risks: [] }每一条Risk记录的字段与约束字段类型说明idstring自动编号R-001、R-002…由 nextId() 基于现有最大编号递增生成titlestring风险短标题add必填threatstring威胁描述add必填assetsstring[]受影响资产如 Atlas key、域名、工作节点data_classesstring[]涉及的数据分类沿用 SensitiveDataMap 的分类credentials、pii、financial、health、customer-data、source-private、internal-only、publiclikelihood/impactnumber1–5 整数越界会被 scoreRisk() 直接抛错scorenumberlikelihood × impact自动计算levelstringLow / Medium / High / Critical由 score 推导statusstringopen/mitigating/accepted/closedownerstring责任人可为空但评审时会被标记mitigationsstring[]缓解措施列表responsestring响应计划/场景文档引用如Scenarios/asset-slug.mdnotesstring备注接受风险时写理由created/updatedstringISO 时间戳每次变更自动刷新updatedreview_bystringISO 日期评审截止日history{ts,event}[]不可变审计轨迹记录每次创建/更新/关闭事件risk-register.json是系统记录源system of record而数据目录下的RiskRegister.md只是 exportMarkdown() 生成的视图包含 Open 表按 score 降序、Closed 表按更新时间降序以及每条未关闭风险的详情代码块文件头明确标注 GENERATED by ThreatModel/Tools/RiskRegister.ts — edit via the CLI, not here。任何add/update/close成功后都会自动重新生成该视图因此永远不要手改 Markdown否则下次写入即被覆盖。四、完整命令参考八个子命令逐一拆解CLI 本体是 RiskRegister.ts以 bun 运行。建议先设置别名Tbun ~/.claude/skills/ThreatModel/Tools/RiskRegister.ts4.1init— 初始化数据目录与空登记册$T init # 输出: Initialized ~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/ (0 risks)创建Scenarios/子目录、写入空的risk-register.jsonversion 1并生成初始RiskRegister.md视图。4.2add— 新增风险--title与--threat必填缺失时程序报错并以退出码 1 终止见 add 分支$T add --title Analytics worker has no auth on its KV \ --threat Unauthenticated read of customer-data KV \ --assets analytics-worker,cust-kv \ --data-classes customer-data,pii \ --likelihood 4 --impact 4 \ --owner you \ --mitigation Restrict KV to VPC \ --response Scenarios/analytics-worker.md \ --review-by 2026-10-15参数说明--assets a,b、--data-classes x,y逗号分隔列表源码中经 list() 拆分、去空格、过滤空项--mitigation可重复出现多次构成缓解措施数组--likelihood/--impact必须为 1–5 整数scoreRisk()会在计算前校验否则抛出must be an integer 1-5--status可选默认open取值必须是四种状态之一--review-by建议在创建时即给出约束见后文--notes追加备注。4.3list— 查看开放风险$T list # 未关闭风险score 降序 $T list --all # 包含已关闭 $T list --level Critical # 仅过滤某等级 $T list --status mitigating $T list --json # 机器可读输出默认行为只显示非closed的风险并按 score 降序排序加--status会做精确状态过滤--level不区分大小写匹配等级见 list 分支。行内格式为R-001 [Critical ] 16 open review:2026-10-15 Analytics worker has no auth on its KV4.4show id— 查看单条详情$T show R-001 $T show r-001 # ID 匹配不区分大小写 $T show R-001 --json输出完整字段含 mitigations 逐条列出、response 引用、评审/创建/更新时间、notes。ID 不存在时报错并以退出码 1 终止见 findRisk()。4.5update id— 更新与重新打分$T update R-001 --likelihood 5 --impact 5 # 重打分自动重算 score/level $T update R-001 --status mitigating --owner you $T update R-001 --add-mitigation Rotate KV token # 追加缓解措施 $T update R-001 --review-by 2026-12-01 # 顺延评审日期 $T update R-001 --title ... --threat ... $T update R-001 --response Scenarios/new.md --notes ...可更新字段覆盖title、threat、owner、response、notes、review-by、status、likelihood、impact、assets、data-classes其中--likelihood或--impact任一出现即触发重新打分未传的一方沿用原值--add-mitigation可重复追加。每次更新都会在history中追加一条updated: 变更摘要事件见 update 分支。4.6close id— 关闭风险$T close R-002 --reason Control implemented: KV now VPC-restricted and audited--reason必填缺失时报错退出见 close 分支。关闭后状态变为closed并从list默认视图中隐藏历史轨迹记录closed: reason。4.7review— 找出到期/缺失评审日期的风险$T review # 按 score 降序列出所有 overdue $T review --json判定逻辑见 review 分支未关闭 且review_by为空 或review_by 今天的风险按 score 降序输出缺失评审日期的行尾追加(no review date)标记。无到期项时输出(nothing due for review)。4.8stats— 姿态快照$T stats # 输出 total / open / byLevel / byStatus / overdue_review / updated / data_dir $T stats --jsonbyLevel按 Critical/High/Medium/Low 统计开放风险byStatus按四种状态统计全量overdue_review统计到期未评审数量见 stats 分支。这是回答我们现在有多少个 Critical的唯一权威命令。4.9export— 重新生成 Markdown 视图$T export # 输出: Wrote ~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/RiskRegister.md正常流程下无需手动执行——每次数据变更都会自动触发此命令用于数据目录被手动恢复或视图被误删后的重建。五、意图到命令映射一句话触达任意操作原文档给出的映射表完整复刻如下这也是日常通过对话驱动本工作流时的标准翻译用户说执行命令加一条风险、记下这个风险add --title … --threat … --likelihood N --impact N [--assets a,b --data-classes x,y --owner O --mitigation M --response REF --review-by DATE]我们有哪些风险、展示登记册list加--all包含已关闭加--level Critical过滤跑一次风险评审、哪些过期了review更新 / 重新评分 R-001update R-001 [--likelihood N --impact N --status S --add-mitigation M --owner O --review-by DATE]接受 R-001update R-001 --status accepted --notes accepted by owner: rationale关闭 / 退役 R-001close R-001 --reason …姿态快照、有多少个 Criticalstats六、评分体系likelihood × impact 的五级量化评分公式与分档文档原文 levelFor() 的边界实现完全一致score likelihood(1-5) × impact(1-5) Low 1-4 · Medium 5-9 · High 10-14 · Critical 15-25scoreRisk()在校验时要求两个因子都是 1–5 的整数Number.isInteger检查浮点与越界直接抛错分档实现score 15→ Critical 10→ High 5→ Medium否则 Low分档的语义锚点见 CompromiseScenario.mdimpact 不按资产规模而按暴露了什么 能触达什么打分——5 分对应可触达多系统的凭据、大规模客户数据或金融/健康 PII4 分对应可触达单个含数据系统的凭据或私有数据存储以此类推likelihood 依据暴露面公网 URL、认证边界、补丁/凭据卫生、现有检测手段估算。七、安全约束四条不可妥协的护栏原文档明列的四条约束是使用本工具的前提逐条展开JSON 存储是唯一事实源RiskRegister.md只是生成视图——绝不手改 Markdown任何数据变更必须走 CLI下次任何写入都会覆盖手改内容。禁止写入任何秘密值——凭据只能以环境变量名形式引用如$DATABASE_TOKEN绝不存 token、key、cookie 本身。这既是本工作流的硬约束也贯穿整个 ThreatModel 技能见 SKILL.md 的 Data/Code Separation 一节。每条风险必须有review_by——没有评审节奏的登记册比没有更糟它制造假的安全感false assurance。创建即带评审日定期review处理过的风险顺手把日期向前推。接受accept是一种决策不是删除——用--status accepted--notes写明accepted by owner: rationale让被接受的风险保持可见、可追溯而不是从账本上消失。八、评审节奏让登记册活起来review只是列出该看的真正的评审是人的决策。原文档给出了标准操作流程执行$T review拉出到期清单含缺失评审日期的逐条走处置三问仍然成立已被缓解还是应该接受——成立则保留并重打分已缓解可追加--add-mitigation或视情况close接受则update --status accepted --notes处理完的条目把review_by向前推一个周期update R-001 --review-by 新日期对无 owner 或无缓解措施的 Critical/High 风险必须显式标记出来要求立即处理。stats中的overdue_review字段可以量化账本腐烂程度如果该值持续增长说明评审节奏没有落地。九、收尾报告一次会话结束时的标准输出完成录入/评审后按原文档要求向用户汇报三件事变更清单新增/更新/关闭的风险 ID含各自 score 与等级当前姿态来自stats的 Critical/High 数量遗留决策仍然到期、还缺人拍板的风险列表。十、与其它工作流的协作闭环RiskRegister 不是孤岛它与其他三个工作流形成闭环SensitiveDataMap输出数据分类credentials/pii/financial/health/…这些分类正是add --data-classes的取值来源未分类资产在登记时即带上了证据缺口标记CompromiseScenario写场景文档后用文档给出的标准落库命令把风险写入登记册见 CompromiseScenario.mdbun ~/.claude/skills/ThreatModel/Tools/RiskRegister.ts add \ --title short risk --threat threat \ --assets atlas-key --data-classes classes \ --likelihood 1-5 --impact 1-5 \ --response Scenarios/asset-slug.md --review-by YYYY-MM-DD \ --mitigation controlThreatModelTarget是编排层最终按分数排名、Critical/High 必须有具名 owner 和review_by的要求直接落在本登记册上见 ThreatModelTarget.md。十一、从源码看实现细节五个值得注意的行为对照 RiskRegister.ts 全文补充几个文档未明说但实际生效的行为add自动打分与自动导出add内部先调scoreRisk()计算 score/level随后saveStore()落盘并立即exportMarkdown()重建视图——所有变更命令init/add/update/close都遵循写 JSON → 重建 MD的两步模式保证视图永不过期ID 自增逻辑nextId()遍历现有编号取最大值 1因此删除/关闭不会复用旧编号审计友好list的过滤叠加--status与--level可同时使用先状态过滤再等级过滤且都作用于全量数据--all只影响是否排除 closed--json全命令支持list/show/review/stats均支持--json方便接入脚本与自动化流水线做断言参数解析器parseArgs() 要求所有 flag 以--开头布尔 flag如--all会被记为true多值 flag 取最后一次赋值——了解了这一点就能避免在 shell 别名中写出歧义参数。使用前提说明以上命令路径~/.claude/skills/ThreatModel/Tools/RiskRegister.ts与默认数据目录~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/均为 LifeOS 安装到用户主目录后的运行时约定在阅读本仓库时源码位于 LifeOS/install/skills/ThreatModel/Tools/RiskRegister.ts工作流文档位于 LifeOS/install/skills/ThreatModel/Workflows/。另外本技能定位于防御性威胁建模与风险治理不用于主动渗透测试见 SKILL.md 的 NOT FOR 边界执行时务必保持只读分析不发起任何扫描或破坏性操作。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考