尧图网站建设 
LifeOS CompromiseScenario 工作流用资产图爆炸半径与风险登记册回答资产被攻破后会怎样【免费下载链接】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导读本文讲解 LifeOS 中 ThreatModel 技能的核心工作流 CompromiseScenario当你说出如果 X 被黑客攻破会发生什么时它如何借助 Atlas 资产图asset graph计算真实的爆炸半径blast radius、推演攻击者的一跳信任one hop of trust、按数据暴露而非资产体量给影响打分并把落地风险写入可持久化、可复审的风险登记册。读完本文你将掌握资产图三条取证命令blast/owns/exposed的语义与底层 SQL 遍历、影响/可能性评分的锚定规则、Scenarios/asset-slug.md场景文档的七要素写法以及RiskRegister.ts确定性 CLI 的完整用法。该工作流定义于 CompromiseScenario.md技能总体约定见 SKILL.md配套的登记册 CLI 见 RiskRegister.ts。工作流定位什么时候触发 CompromiseScenarioThreatModel 技能共有四条工作流由 SKILL.md 中的路由表统一分派工作流触发语文件SensitiveDataMap我们的敏感数据在哪、数据分类、哪些资产持有敏感数据SensitiveDataMap.mdCompromiseScenario如果 X 被攻破、入侵场景、X 的爆炸半径本文主题ThreatModelTarget对 X 做威胁建模、对整个资产做风险评估ThreatModelTarget.mdRiskRegister风险登记册、添加风险、风险复审、接受风险RiskRegister.mdCompromiseScenario 的核心定位是防御性建模只推演若某资产被攻破会暴露什么、能触达什么、如何检测与响应绝不执行任何利用、扫描或破坏性动作。主动渗透测试属于单独的 offensive-security 技能。执行入口与语音通知按 SKILL.md 约定每次执行工作流时需同时完成语音通知与文本通知curl -s -X POST http://localhost:31337/notify -H Content-Type: application/json \ -d {message: Running CompromiseScenario in ThreatModel} /dev/null 21 同时在终端输出一行Running CompromiseScenario in ThreatModel...便于用户感知 Agent 正在执行哪条工作流。Step 0 — 充分性检查Sufficiency Check工作流要求先锚定一个具体的资产可以是 Atlas 中的 key、一个应用、一个域名或一个 worker。若用户没有给出资产且无法从上下文推断则必须反问用户选哪个资产否则直接进入正题。这一步防止对整个资产这种过宽范围做漫无目的的推演——宽范围建模应交给 ThreatModelTarget.md 的组合式流程。理想产出物可执行的场景文档Scenarios/asset-slug.mdCompromiseScenario 的最终交付物是一份写入私有数据目录的 Markdown 场景文档Scenarios/asset-slug.md让应急响应人员拿到即可行动。文档必须包含以下七要素资产与信任Asset trust— 资产是什么、持有哪些数据依据 SensitiveDataMap / 数据分类、能触达什么凭证、服务绑定、部署密钥至少一跳信任。爆炸半径Blast radius— 谁依赖它、它拥有什么来自资产图且作为派生证据对待。入侵推演Compromise walk— 合理的入口、攻击者读取/写入/横向移动的路径、最坏的现实结局。暴露面Exposure— 具体暴露的数据类别以及大致多少条记录/多少个系统。检测Detection— 什么信号能捕获这次入侵日志、扫描器、异常以及该信号今天是否已存在。响应Response— 遏制步骤、凭证轮换指引指向事件响应 runbook 而非重复其内容、恢复方案。残余风险Residual risk— 即便按计划响应后仍暴露在外的部分。要素 1 中提到的数据分类对应 DataClassification.md 定义的 RESTRICTED / CONFIDENTIAL / INTERNAL / PUBLIC 四类SensitiveDataMap 工作流则用credentials · pii · financial · health · customer-data · source-private · internal-only · public这组类别为每个持有数据的资产打标。场景文档中的暴露面描述应复用这两套分类词汇保证与登记册、数据地图口径一致。爆炸半径资产图三条取证命令Atlas 是 LifeOS 的资产图 CLI入口见 Atlas.tsSQLite 作为系统记录schema 见 Store.ts。CompromiseScenario 用它把爆炸半径多大从拍脑袋变成可重复的查询bun ~/.claude/LIFEOS/ATLAS/Atlas.ts blast key # inbound: 谁依赖 X bun ~/.claude/LIFEOS/ATLAS/Atlas.ts owns key # outbound: X 拥有什么 / 删除 X 会孤儿化什么 bun ~/.claude/LIFEOS/ATLAS/Atlas.ts exposed key # X 会泄露哪些凭证, compromise-tier 优先三条命令的语义差异在 Store.ts 的查询实现中一目了然blast入站沿OPERATIONAL_EDGE_KINDSSERVES、ROUTE、CALLS、DEPENDS_ON、RUNS_ON、OWNS、DEPLOYED_FROM、HOLDS反向递归回答哪些资产在运行上依赖 X。注意HOLDS也在其中——凭证被轮换时持有它的资产会坏掉所以blast credential:X能返回所有需要新值的系统。owns出站沿OWNS边正向递归回答删除/丢失 X 会孤儿化orphan什么。exposed泄露方向沿OWNSHOLDS双向递归只返回kind credential的资产并按凭证优先级排序。它回答的是事件响应的方向问题——这个资产被攻破了它泄露了什么——与blast我轮换 X 会弄坏什么正好互补。exposed的输出还会额外打印两条关键信息暴露的凭证总数、其中 compromise-tierCRITICAL的数量以及一句重要的处置提示——先遏制资产再轮换凭证否则轮换只是把新值交到还活着的立足点上见 Atlas.ts 中exposed命令实现。另一半信任继承DEPENDS_ON 数据存储查询凭证之外资产还能通过数据存储触达数据。工作流给出了配套的只读 SQL 查询找出 X 依赖的活动数据存储bun ~/.claude/LIFEOS/ATLAS/Atlas.ts sql SELECT a.kind, a.canonical_key FROM edge e JOIN asset a ON a.ide.dst WHERE e.kindDEPENDS_ON AND e.statusactive AND e.src(SELECT id FROM asset WHERE canonical_keykey)atlas sql在实现上是结构性只读的——Atlas.ts 以readonly: true打开数据库连接结构上无法写入。exposed加上这条 DEPENDS_ON 查询就让要素 1 的一跳信任从主观判断变成确定性的枚举。为什么这条查询重要一个自身没有任何数据的 worker通常正是通过它的绑定bindings把影响继承到了 5 分。所以工作流明确要求在打分影响之前两条查询都跑完不要用眼睛估。这正是 SKILL.md 中 gotchas 所强调的场景影响包含资产能触达的而不仅是它存储的。Atlas 不可用时的回退如果当前安装没有 Atlas工作流退回到用户枚举 仓库/配置检查来构建爆炸半径并且必须在输出中明确声明这一点——绝不允许凭空编造资产清单Never invent an inventory。同理SensitiveDataMap 在没有资产图时也必须声明覆盖率是用户枚举的而非图完备的。凭证集中它本身就是一个独立发现工作流给出了一条容易被忽略的高价值规则当exposed在单个资产上返回了多于一个compromise-tier 凭证类别时这种集中本身就是一条独立的发现。举个例子一个资产上同时持有两类凭证且分别触达两个不同的信任域那它把本来应该存在的信任边界击穿了。此时应该把它写成一条独立风险而不是并进该资产主场景的分数里——因为缓解方式不同前者需要拆分凭证split而不是轮换rotate。从源码看exposed的排序逻辑把CRITICAL, HIGH, MEDIUM, LOW, DEFER, ORPHAN, UNKNOWN作为固定优先级序见 Atlas.ts所以多个 compromise-tier 类别落在同一资产这种集中信号可以直接从输出中机械化识别不需要人工翻找。图是派生证据不是权威工作流反复强调一个认知边界高风险的场景在把爆炸半径当作完整结论之前必须用供应商的权威 APIproviders authority API复核关键边——因为图可能滞后或欠建模graph can lag or under-model edges。图看不到的东西必须点名vendor-only 的 OAuth 授权、SSH 密钥、浏览器会话、密码管理器里的内容——这些要作为场景的一部分写出来而不是当作遗漏跳过。这个边界在数据收集层面同样成立凭证收集器Secrets.ts只读取凭证注册表名字 分类绝不读值它明确记录了一个故意不伪造的已知盲区只存在于供应商侧、从未落到本地任何文件的凭证如 OAuth 授权、控制台签发的 token对任何收集器都不可见必须走供应商自己的审计面。这与 SecurityModel.md 的贯穿性问题一脉相承到这份数据的真实路径是什么——图给出的是当前状态快照而权威永远在平台侧。影响与可能性评分喂给登记册影响Impact 1-5锚定暴露了什么 触达了什么影响打分不取决于资产的体量而取决于资产被攻破后暴露与触达的后果分数判定标准5触及多个系统的凭证、规模化客户数据或金融/健康类 PII4触及一个持有数据的系统的凭证或一个私有数据存储3仅内部数据或对公共面有写权限2有限的内部暴露1仅公开数据无横向移动可能对照 DataClassification.md 的四级分类可发现其一致性RESTRICTED凭证、第三方 PII、客户数据、财务/健康源文档和 CONFIDENTIAL个人健康、财务、安全态势直接对应影响 4–5INTERNAL 对应影响 2–3PUBLIC 对应影响 1。可能性Likelihood 1-5锚定暴露面可能性由以下因素决定是否公开 URL、认证边界的强度、补丁/凭证卫生状况、是否已有检测手段。分数换算确定性无模型判断SKILL.md 与 RiskRegister.ts 中scoreRisk()/levelFor()共同定义了换算规则score likelihood(1-5) × impact(1-5) Low 1-4 · Medium 5-9 · High 10-14 · Critical 15-25scoreRisk()会先校验两个维度必须是 1–5 的整数否则直接抛错levelFor()按 15 / 10 / 5 三个阈值切分等级。这意味着分数计算在数据路径上完全确定——模型不参与算术只提供两个锚定后的输入。落地风险RiskRegister 确定性 CLI场景推演出的每一条真实风险都要落进登记册。工作流给出了add命令的完整形态bun ~/.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 control其中--response指向本工作流生成的场景文档——这是场景文档 ↔ 登记册的双向引用场景文档说明风险为何成立登记册条目负责跟踪处置与复审。登记册的完整命令面RiskRegister.md 给出了意图到命令的完整映射这里按场景流程常用顺序整理Tbun ~/.claude/skills/ThreatModel/Tools/RiskRegister.ts $T init # 初始化数据目录 空登记册同时创建 Scenarios/ 子目录 $T stats # 态势快照总数、开放数、按等级/状态分布、逾期复审数 $T list # 列出开放风险, 按分数从高到低 $T list --all # 含已关闭 $T list --level Critical # 按等级过滤 $T show R-001 # 查看单条详情 $T update R-001 --status accepted --notes accepted by owner: rationale # 接受风险是决策不是删除 $T update R-001 --likelihood N --impact N --add-mitigation M --review-by DATE # 重新打分/追加缓解/顺延复审 $T close R-001 --reason … # 关闭必须给理由 $T review # 列出逾期或缺失复审日期的风险 $T export # 重新生成 RiskRegister.md 视图数据结构与安全门源码级从 RiskRegister.ts 的实现可以看到几个关键设计JSON 存储是系统记录risk-register.json是唯一事实来源RiskRegister.md是由exportMarkdown()生成的视图文件头明确写着GENERATED请通过 CLI 编辑不要在此编辑——下次导出会覆盖手改内容。代码/数据强制隔离resolveDataDir()默认数据目录为~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/可用THREATMODEL_DATA_DIR覆盖且结构上拒绝任何解析到skills/路径内的数据目录检测到即exit 2。这保证了公开代码树永不包含数据。无密钥值凭证一律按环境变量名引用Risk类型里根本没有存放值的字段注册表条目的历史事件history: [{ts, event}]只记录变更语义不记录值。每条风险必有review_byreview命令会列出review_by为空或已到期的未关闭风险。正如 SKILL.md 的告诫——没人复审的登记册比没有更糟它制造虚假的安全感。复审节奏建议的处置循环是review拉取到期清单 → 逐条判定仍成立已缓解接受→update状态并把review_by顺延 → 对无负责人或无缓解的 Critical/High 单独上抛。关闭风险必须使用close并给出--reason保持审计轨迹。约束与安全门Constraints工作流明确列出三条红线与整个 ThreatModel 技能的安全模型一致只读建模只推演入侵场景绝不执行利用、扫描或破坏性动作主动进攻性测试属于独立的 offensive-security 技能。文档与登记册中无密钥值任何 token、key、cookie 都不允许出现在威胁模型输出中凭证仅以环境变量名引用。只写数据目录场景文档与登记册条目只能写入数据目录THREATMODEL_DATA_DIR默认~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/永不写入技能树。这三点在 SecurityModel.md 的代理与安全机制一节有系统化支撑外部内容一律视为数据而非指令egress 扫描拦截 secret 形状的字符串发布管线是私有安装通向公共面的唯一通道且 fail-closed。收尾Close一次场景推演的交付清单工作流结束时的总结必须覆盖最坏的现实结局worst realistic outcome是什么暴露度最高的数据类别有哪些检测今天是否已存在对应场景文档要素 5且要区分应有信号与现有信号落地的风险清单ID 分数任何 Critical 风险都要标记为需要立即关注。至此一次如果 X 被攻破会怎样的提问闭环为资产图爆炸半径blast/owns/exposed DEPENDS_ON 查询→ 七要素场景文档 → 锚定数据暴露的影响评分 → 登记册条目addreview_by→ 复审循环。整条链路在数据路径上是确定性的、可审计的这正是 ThreatModel 技能区别于让模型自由发挥的核心——推演允许模型判断但事实、分数与记录由代码与证据决定。进一步阅读技能总览见 SKILL.md资产图 CLI 实现见 Atlas.ts图数据模型与遍历查询见 Store.ts凭证收集器的边界见 Secrets.ts数据分类口径见 DataClassification.md安全模型总纲见 SecurityModel.md。【免费下载链接】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 CompromiseScenario 工作流：用资产图爆炸半径与风险登记册回答“资产被攻破后会怎样“
LifeOS CompromiseScenario 工作流用资产图爆炸半径与风险登记册回答资产被攻破后会怎样【免费下载链接】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导读本文讲解 LifeOS 中 ThreatModel 技能的核心工作流 CompromiseScenario当你说出如果 X 被黑客攻破会发生什么时它如何借助 Atlas 资产图asset graph计算真实的爆炸半径blast radius、推演攻击者的一跳信任one hop of trust、按数据暴露而非资产体量给影响打分并把落地风险写入可持久化、可复审的风险登记册。读完本文你将掌握资产图三条取证命令blast/owns/exposed的语义与底层 SQL 遍历、影响/可能性评分的锚定规则、Scenarios/asset-slug.md场景文档的七要素写法以及RiskRegister.ts确定性 CLI 的完整用法。该工作流定义于 CompromiseScenario.md技能总体约定见 SKILL.md配套的登记册 CLI 见 RiskRegister.ts。工作流定位什么时候触发 CompromiseScenarioThreatModel 技能共有四条工作流由 SKILL.md 中的路由表统一分派工作流触发语文件SensitiveDataMap我们的敏感数据在哪、数据分类、哪些资产持有敏感数据SensitiveDataMap.mdCompromiseScenario如果 X 被攻破、入侵场景、X 的爆炸半径本文主题ThreatModelTarget对 X 做威胁建模、对整个资产做风险评估ThreatModelTarget.mdRiskRegister风险登记册、添加风险、风险复审、接受风险RiskRegister.mdCompromiseScenario 的核心定位是防御性建模只推演若某资产被攻破会暴露什么、能触达什么、如何检测与响应绝不执行任何利用、扫描或破坏性动作。主动渗透测试属于单独的 offensive-security 技能。执行入口与语音通知按 SKILL.md 约定每次执行工作流时需同时完成语音通知与文本通知curl -s -X POST http://localhost:31337/notify -H Content-Type: application/json \ -d {message: Running CompromiseScenario in ThreatModel} /dev/null 21 同时在终端输出一行Running CompromiseScenario in ThreatModel...便于用户感知 Agent 正在执行哪条工作流。Step 0 — 充分性检查Sufficiency Check工作流要求先锚定一个具体的资产可以是 Atlas 中的 key、一个应用、一个域名或一个 worker。若用户没有给出资产且无法从上下文推断则必须反问用户选哪个资产否则直接进入正题。这一步防止对整个资产这种过宽范围做漫无目的的推演——宽范围建模应交给 ThreatModelTarget.md 的组合式流程。理想产出物可执行的场景文档Scenarios/asset-slug.mdCompromiseScenario 的最终交付物是一份写入私有数据目录的 Markdown 场景文档Scenarios/asset-slug.md让应急响应人员拿到即可行动。文档必须包含以下七要素资产与信任Asset trust— 资产是什么、持有哪些数据依据 SensitiveDataMap / 数据分类、能触达什么凭证、服务绑定、部署密钥至少一跳信任。爆炸半径Blast radius— 谁依赖它、它拥有什么来自资产图且作为派生证据对待。入侵推演Compromise walk— 合理的入口、攻击者读取/写入/横向移动的路径、最坏的现实结局。暴露面Exposure— 具体暴露的数据类别以及大致多少条记录/多少个系统。检测Detection— 什么信号能捕获这次入侵日志、扫描器、异常以及该信号今天是否已存在。响应Response— 遏制步骤、凭证轮换指引指向事件响应 runbook 而非重复其内容、恢复方案。残余风险Residual risk— 即便按计划响应后仍暴露在外的部分。要素 1 中提到的数据分类对应 DataClassification.md 定义的 RESTRICTED / CONFIDENTIAL / INTERNAL / PUBLIC 四类SensitiveDataMap 工作流则用credentials · pii · financial · health · customer-data · source-private · internal-only · public这组类别为每个持有数据的资产打标。场景文档中的暴露面描述应复用这两套分类词汇保证与登记册、数据地图口径一致。爆炸半径资产图三条取证命令Atlas 是 LifeOS 的资产图 CLI入口见 Atlas.tsSQLite 作为系统记录schema 见 Store.ts。CompromiseScenario 用它把爆炸半径多大从拍脑袋变成可重复的查询bun ~/.claude/LIFEOS/ATLAS/Atlas.ts blast key # inbound: 谁依赖 X bun ~/.claude/LIFEOS/ATLAS/Atlas.ts owns key # outbound: X 拥有什么 / 删除 X 会孤儿化什么 bun ~/.claude/LIFEOS/ATLAS/Atlas.ts exposed key # X 会泄露哪些凭证, compromise-tier 优先三条命令的语义差异在 Store.ts 的查询实现中一目了然blast入站沿OPERATIONAL_EDGE_KINDSSERVES、ROUTE、CALLS、DEPENDS_ON、RUNS_ON、OWNS、DEPLOYED_FROM、HOLDS反向递归回答哪些资产在运行上依赖 X。注意HOLDS也在其中——凭证被轮换时持有它的资产会坏掉所以blast credential:X能返回所有需要新值的系统。owns出站沿OWNS边正向递归回答删除/丢失 X 会孤儿化orphan什么。exposed泄露方向沿OWNSHOLDS双向递归只返回kind credential的资产并按凭证优先级排序。它回答的是事件响应的方向问题——这个资产被攻破了它泄露了什么——与blast我轮换 X 会弄坏什么正好互补。exposed的输出还会额外打印两条关键信息暴露的凭证总数、其中 compromise-tierCRITICAL的数量以及一句重要的处置提示——先遏制资产再轮换凭证否则轮换只是把新值交到还活着的立足点上见 Atlas.ts 中exposed命令实现。另一半信任继承DEPENDS_ON 数据存储查询凭证之外资产还能通过数据存储触达数据。工作流给出了配套的只读 SQL 查询找出 X 依赖的活动数据存储bun ~/.claude/LIFEOS/ATLAS/Atlas.ts sql SELECT a.kind, a.canonical_key FROM edge e JOIN asset a ON a.ide.dst WHERE e.kindDEPENDS_ON AND e.statusactive AND e.src(SELECT id FROM asset WHERE canonical_keykey)atlas sql在实现上是结构性只读的——Atlas.ts 以readonly: true打开数据库连接结构上无法写入。exposed加上这条 DEPENDS_ON 查询就让要素 1 的一跳信任从主观判断变成确定性的枚举。为什么这条查询重要一个自身没有任何数据的 worker通常正是通过它的绑定bindings把影响继承到了 5 分。所以工作流明确要求在打分影响之前两条查询都跑完不要用眼睛估。这正是 SKILL.md 中 gotchas 所强调的场景影响包含资产能触达的而不仅是它存储的。Atlas 不可用时的回退如果当前安装没有 Atlas工作流退回到用户枚举 仓库/配置检查来构建爆炸半径并且必须在输出中明确声明这一点——绝不允许凭空编造资产清单Never invent an inventory。同理SensitiveDataMap 在没有资产图时也必须声明覆盖率是用户枚举的而非图完备的。凭证集中它本身就是一个独立发现工作流给出了一条容易被忽略的高价值规则当exposed在单个资产上返回了多于一个compromise-tier 凭证类别时这种集中本身就是一条独立的发现。举个例子一个资产上同时持有两类凭证且分别触达两个不同的信任域那它把本来应该存在的信任边界击穿了。此时应该把它写成一条独立风险而不是并进该资产主场景的分数里——因为缓解方式不同前者需要拆分凭证split而不是轮换rotate。从源码看exposed的排序逻辑把CRITICAL, HIGH, MEDIUM, LOW, DEFER, ORPHAN, UNKNOWN作为固定优先级序见 Atlas.ts所以多个 compromise-tier 类别落在同一资产这种集中信号可以直接从输出中机械化识别不需要人工翻找。图是派生证据不是权威工作流反复强调一个认知边界高风险的场景在把爆炸半径当作完整结论之前必须用供应商的权威 APIproviders authority API复核关键边——因为图可能滞后或欠建模graph can lag or under-model edges。图看不到的东西必须点名vendor-only 的 OAuth 授权、SSH 密钥、浏览器会话、密码管理器里的内容——这些要作为场景的一部分写出来而不是当作遗漏跳过。这个边界在数据收集层面同样成立凭证收集器Secrets.ts只读取凭证注册表名字 分类绝不读值它明确记录了一个故意不伪造的已知盲区只存在于供应商侧、从未落到本地任何文件的凭证如 OAuth 授权、控制台签发的 token对任何收集器都不可见必须走供应商自己的审计面。这与 SecurityModel.md 的贯穿性问题一脉相承到这份数据的真实路径是什么——图给出的是当前状态快照而权威永远在平台侧。影响与可能性评分喂给登记册影响Impact 1-5锚定暴露了什么 触达了什么影响打分不取决于资产的体量而取决于资产被攻破后暴露与触达的后果分数判定标准5触及多个系统的凭证、规模化客户数据或金融/健康类 PII4触及一个持有数据的系统的凭证或一个私有数据存储3仅内部数据或对公共面有写权限2有限的内部暴露1仅公开数据无横向移动可能对照 DataClassification.md 的四级分类可发现其一致性RESTRICTED凭证、第三方 PII、客户数据、财务/健康源文档和 CONFIDENTIAL个人健康、财务、安全态势直接对应影响 4–5INTERNAL 对应影响 2–3PUBLIC 对应影响 1。可能性Likelihood 1-5锚定暴露面可能性由以下因素决定是否公开 URL、认证边界的强度、补丁/凭证卫生状况、是否已有检测手段。分数换算确定性无模型判断SKILL.md 与 RiskRegister.ts 中scoreRisk()/levelFor()共同定义了换算规则score likelihood(1-5) × impact(1-5) Low 1-4 · Medium 5-9 · High 10-14 · Critical 15-25scoreRisk()会先校验两个维度必须是 1–5 的整数否则直接抛错levelFor()按 15 / 10 / 5 三个阈值切分等级。这意味着分数计算在数据路径上完全确定——模型不参与算术只提供两个锚定后的输入。落地风险RiskRegister 确定性 CLI场景推演出的每一条真实风险都要落进登记册。工作流给出了add命令的完整形态bun ~/.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 control其中--response指向本工作流生成的场景文档——这是场景文档 ↔ 登记册的双向引用场景文档说明风险为何成立登记册条目负责跟踪处置与复审。登记册的完整命令面RiskRegister.md 给出了意图到命令的完整映射这里按场景流程常用顺序整理Tbun ~/.claude/skills/ThreatModel/Tools/RiskRegister.ts $T init # 初始化数据目录 空登记册同时创建 Scenarios/ 子目录 $T stats # 态势快照总数、开放数、按等级/状态分布、逾期复审数 $T list # 列出开放风险, 按分数从高到低 $T list --all # 含已关闭 $T list --level Critical # 按等级过滤 $T show R-001 # 查看单条详情 $T update R-001 --status accepted --notes accepted by owner: rationale # 接受风险是决策不是删除 $T update R-001 --likelihood N --impact N --add-mitigation M --review-by DATE # 重新打分/追加缓解/顺延复审 $T close R-001 --reason … # 关闭必须给理由 $T review # 列出逾期或缺失复审日期的风险 $T export # 重新生成 RiskRegister.md 视图数据结构与安全门源码级从 RiskRegister.ts 的实现可以看到几个关键设计JSON 存储是系统记录risk-register.json是唯一事实来源RiskRegister.md是由exportMarkdown()生成的视图文件头明确写着GENERATED请通过 CLI 编辑不要在此编辑——下次导出会覆盖手改内容。代码/数据强制隔离resolveDataDir()默认数据目录为~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/可用THREATMODEL_DATA_DIR覆盖且结构上拒绝任何解析到skills/路径内的数据目录检测到即exit 2。这保证了公开代码树永不包含数据。无密钥值凭证一律按环境变量名引用Risk类型里根本没有存放值的字段注册表条目的历史事件history: [{ts, event}]只记录变更语义不记录值。每条风险必有review_byreview命令会列出review_by为空或已到期的未关闭风险。正如 SKILL.md 的告诫——没人复审的登记册比没有更糟它制造虚假的安全感。复审节奏建议的处置循环是review拉取到期清单 → 逐条判定仍成立已缓解接受→update状态并把review_by顺延 → 对无负责人或无缓解的 Critical/High 单独上抛。关闭风险必须使用close并给出--reason保持审计轨迹。约束与安全门Constraints工作流明确列出三条红线与整个 ThreatModel 技能的安全模型一致只读建模只推演入侵场景绝不执行利用、扫描或破坏性动作主动进攻性测试属于独立的 offensive-security 技能。文档与登记册中无密钥值任何 token、key、cookie 都不允许出现在威胁模型输出中凭证仅以环境变量名引用。只写数据目录场景文档与登记册条目只能写入数据目录THREATMODEL_DATA_DIR默认~/.claude/LIFEOS/USER/SECURITY/THREATMODEL/永不写入技能树。这三点在 SecurityModel.md 的代理与安全机制一节有系统化支撑外部内容一律视为数据而非指令egress 扫描拦截 secret 形状的字符串发布管线是私有安装通向公共面的唯一通道且 fail-closed。收尾Close一次场景推演的交付清单工作流结束时的总结必须覆盖最坏的现实结局worst realistic outcome是什么暴露度最高的数据类别有哪些检测今天是否已存在对应场景文档要素 5且要区分应有信号与现有信号落地的风险清单ID 分数任何 Critical 风险都要标记为需要立即关注。至此一次如果 X 被攻破会怎样的提问闭环为资产图爆炸半径blast/owns/exposed DEPENDS_ON 查询→ 七要素场景文档 → 锚定数据暴露的影响评分 → 登记册条目addreview_by→ 复审循环。整条链路在数据路径上是确定性的、可审计的这正是 ThreatModel 技能区别于让模型自由发挥的核心——推演允许模型判断但事实、分数与记录由代码与证据决定。进一步阅读技能总览见 SKILL.md资产图 CLI 实现见 Atlas.ts图数据模型与遍历查询见 Store.ts凭证收集器的边界见 Secrets.ts数据分类口径见 DataClassification.md安全模型总纲见 SecurityModel.md。【免费下载链接】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），仅供参考