【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本文以.changeset/archived/fix-3120-secure-phase-empty-register.md记录的变更PR #3142关闭 issue #3120为核心剖析 GSD Core 安全阶段工作流secure-phase中一个隐蔽的审计绕过缺陷当threats_open: 0时工作流无法区分所有威胁都已缓解与根本没有编写任何威胁模型。通过register_authored_at_plan_time标记与 retroactive-STRIDE 模式修复后遗留阶段在threat_model块成为规范之前编写的 PLAN不再被盖章放行干净的空 SECURITY.md。读完本文你将掌握 secure-phase 的完整状态机、短路门控规则、审计器约束差异以及如何用仓库源码与测试验证这一安全契约。一、问题本质threats_open: 0的双重语义1.1 secure-phase 工作流在做什么/gsd-secure-phase是 GSD Core 中对一个已完成阶段进行威胁缓解验证的复核命令其完整执行契约定义在 gsd-core/workflows/secure-phase.md命令入口在 commands/gsd/secure-phase.md。它的职责是从该阶段的PLAN.md中提取threat_model块信任边界 STRIDE 威胁登记簿从SUMMARY.md中提取## Threat Flags执行期新出现的攻击面校验每个威胁的处置mitigate/accept/transfer是否已在实现中落实更新或生成{phase}-SECURITY.md并在存在未缓解阻断性威胁时阻止阶段推进。工作流首先检测输入状态Step 1状态判定条件行为State ASECURITY.md已存在审计并复核既有缓解措施State B无SECURITY.md但PLAN.md与SUMMARY.md存在从阶段产物出发生成安全文档State C无SUMMARY.md阶段未执行直接退出并提示先运行/gsd-execute-phase {N}1.2 旧短路逻辑的漏洞在 PR #3142 修复之前secure-phase工作流的 Step 3 威胁分类存在一个条件过宽的短路只要threats_open: 0就直接跳过审计、跳到 Step 6 写出一份干净的SECURITY.md。threats_open: 0在数学上看起来是无害的——没有未缓解威胁。但它在语义上是歧义的Case A合法的零计划期编写的threat_model中的所有威胁都已被实现代码缓解或记录为接受/转移风险审计确实无话可说Case B虚假的零阶段是遗留阶段其 PLAN 编写于threat_model块成为规范之前PLAN 中根本没有任何威胁模型。此时登记簿为空是因为从未写过而非全部处理完。旧逻辑把 Case B 也当作 Case A 处理零威胁 → 直接写一份threats_open: 0的干净SECURITY.md。这正是 changeset 中 rubber-stamps SECURITY.md橡皮图章式盖章放行一词的含义——审计零执行却产出零威胁的结论整个安全门形同虚设。二、修复方案给登记簿来源加上可追溯标记2.1 Step 2c追踪register_authored_at_plan_time修复的核心是在工作流的Step 2c构建威胁登记簿引入一个新的布尔标记register_authored_at_plan_time其判定规则gsd-core/workflows/secure-phase.md若该阶段至少一个PLAN 文件包含可解析的threat_model块 →register_authored_at_plan_time: true若没有任何 PLAN 文件含threat_model块即遗留阶段早于正式威胁建模规范→register_authored_at_plan_time: false。与此同时Step 2c 中每个威胁的登记簿条目形状为{ threat_id, category, component, severity, disposition, mitigation_pattern, files_to_check }——severity字段是后来 #1626 引入的按威胁严重度门控的基础审计器正是依据它结合block_on阈值计算threats_open的。2.2 Step 3短路门控从单条件变为双条件修复后Step 3 的短路规则被改写为以下四个分支这是 changeset 与工作流原文共同确立的核心契约条件行为threats_open: 0且register_authored_at_plan_time: true且asvs_level 1直接跳到 Step 6。登记簿完整且 L1 grep 深度足够无阻断性威胁剩余threats_open: 0且register_authored_at_plan_time: true且asvs_level 2不跳过进入 Step 5 派发审计器。初步分类是 grep 级L1 深度对 L2/L3 不足——跳过会破坏 ASVS 等级在干净阶段上的缩放threats_open: 0且register_authored_at_plan_time: false不跳过进入 Step 5 的retroactive-STRIDE 模式——空登记簿不能盖章放行干净 SECURITY.mdthreats_open 0进入 Step 4向用户呈现威胁处理计划关键点在于零威胁本身不再构成跳过的充分条件只有零威胁 登记簿确实来源于计划期建模同时成立且 ASVS 等级仅为 L1 时才允许短路。两个维度威胁数量 × 登记簿来源现在都被显式检查。三、retroactive-STRIDE 模式从实现文件反推登记簿3.1 审计器的两种约束Step 5 负责派发gsd-security-auditor子代理其约束随登记簿来源register_authored_at_plan_time而变化计划期登记簿true审计器只验证已声明的缓解措施是否存在于实现中不扫描新威胁——登记簿视为完整retroactive-STRIDE 模式false审计器先从实现文件构建 STRIDE 登记簿再验证缓解措施。因为阶段在正式威胁建模之前编写审计器必须从零构造登记簿。retroactive-STRIDE 模式在审计器 agent 的analyze_threats步骤中也有对应处理当 PLAN.md 中没有threat_model块需要追溯构建登记簿时审计器需要为每个自行构造的威胁按影响 × 可能性分配严重度agents/gsd-security-auditor.md。3.2 审计器如何工作gsd-security-auditor是 secure-phase 工作流唯一允许派发的子代理类型工作流available_agent_types中明确不允许回退到 general-purpose。其关键设计agents/gsd-security-auditor.md只读契约工具集为Read / Bash / Glob / Grep不含 Write 与 Edit#2119 单写者契约SECURITY.md 由编排器写回实现文件只读审计器只返回结构化判决不修补实现对抗立场默认假设每个缓解措施都不存在直到 grep 匹配证明其在正确位置存在按处置类型验证mitigate→ 在缓解计划引用的文件中 grep 缓解模式accept→ 核对 SECURITY.md 已接受风险日志transfer→ 核对转移文档保险、供应商 SLA 等存在验证深度随asvs_level缩放L1 只查模式存在grep 级L2 验证缓解措施确实针对威胁向量且位于正确边界L3 端到端追踪数据流、检查边界情况与顺序确认无旁路。3.3threats_open的严重度感知计算审计器返回的threats_open是 SECURITY.md frontmatter 中的门控字段其计算规则严重度序critical high medium lowthreats_open 状态为 OPEN且严重度等级 ≥block_on等级的威胁数block_on: none→ 永不阻断恒为 0block_on: low→ 所有 OPEN 威胁都阻断block_on: high默认→ 仅 high 与 critical 阻断低于阈值的 OPEN 威胁记为open — below {block_on} threshold (non-blocking)不计入threats_open缺失严重度的失败关闭策略OPEN 威胁若无严重度或严重度无法解析如早于 Severity 列的遗留登记簿按critical处理并计入threats_open——绝不静默丢弃未分级的 OPEN 威胁。四、完整流程回顾Step 0 到 Step 8结合 gsd-core/workflows/secure-phase.md 的原始流程修复后的 secure-phase 全链路为Step 0 初始化解析phase_dir等参数通过gsd_run query config-get读取workflow.security_asvs_level默认1与workflow.security_block_on默认high通过loop render-hooks verify:post解析能力钩子——若无ref.skill secure-phase的活动步骤钩子则退出并提示 Security enforcement disabled. Enable via /gsd:settings.Step 1 输入状态检测判定 State A / B / CStep 2 发现2a 读 PLAN 提取threat_model2b 读 SUMMARY 的## Threat Flags2c 构建威胁登记簿并设置register_authored_at_plan_timeStep 3 威胁分类按上文的四分支短路规则处理Step 4 呈现威胁计划文本模式workflow.text_mode: true或--text标志下用纯文本编号列表替代AskUserQuestion提供三个选项验证全部 OPEN 威胁 / 全部接受并记录到已接受风险日志 / 取消Step 5 派发审计器打印◆ Spawning security auditor...子代理运行约 1–5 分钟无输出属正常按运行时类型解析派发#2508模型参数在inherit或为空时省略#2517处理三种返回## SECURED/## OPEN_THREATS/## ESCALATEStep 6 写入/更新 SECURITY.mdState B 从 gsd-core/templates/SECURITY.md 模板生成State A 追加审计日志表Threats found / Closed / Open若所有选项用尽后threats_open 0触发强制执行门输出GSD PHASE {N} SECURITY BLOCKED明确Do NOT emit next-phase routing阻止阶段推进Step 7 提交gsd_run query commit提交 SECURITY.mdStep 8 结果与路由成功threats_open: 0时输出GSD PHASE {N} THREAT-SECURE并给出/gsd-validate-phase {N}与/gsd-verify-work {N}的后续路由建议。五、仓库证据链工作流、模板、命令与回归测试5.1 SECURITY.md 模板的结构gsd-core/templates/SECURITY.md 是 State B 生成阶段安全文档的骨架其 frontmatter 包含门控字段phase、slug、status、threats_open注释注明其为达到或超过workflow.security_block_on严重度的 OPEN 威胁计数即阻断门、asvs_level、created。正文包含五个部分Trust Boundaries信任边界表边界、描述、穿越数据Threat RegisterThreat ID / Category / Component / Severity / Disposition / Mitigation / Status七列登记表附状态、严重度、处置三项语义注释Accepted Risks Log已接受风险日志Accepted risks do not resurface in future audit runs.Security Audit Trail审计轨迹表审计日期、威胁总数、已关闭、开放、执行者Sign-Off签署清单含threats_open: 0确认与status: verified设置。5.2 命令入口与文档commands/gsd/secure-phase.mdfrontmatter 声明name: gsd:secure-phase、allowed-tools列表Read / Write / Edit / Bash / Glob / Grep / Agent / AskUserQuestion注意编排器本身持有 Write 权限与审计器只读形成对照、requires: [phase]objective明确三状态模型docs/COMMANDS.md/gsd-secure-phase的三种运行模式SECURITY.md 存在则复核 / 无 SECURITY.md 但 PLAN 有威胁模型则从产物生成 / 阶段未执行则退出默认审计最后完成的阶段产物为{phase}-SECURITY.mddocs/explanation/security-model.md解释 GSD Core 的纵深防御安全模型secure-phase 属于其中对已完成阶段验证威胁缓解的验证层。5.3 回归测试bug-3120折叠用例本次修复的直接回归保障位于 tests/secure-phase.test.cjs 末尾折叠的folded:bug-3120-secure-phase-empty-register测试组注释中完整复述了问题与修复语义。该组对gsd-core/workflows/secure-phase.md的文本内容做结构性断言验证四项契约Step 2c 追踪register_authored_at_plan_time工作流源码必须包含该标识Step 3 短路要求双条件必须包含threats_open: 0 AND register_authored_at_plan_time门控遗留阶段记录 retroactive-STRIDE 模式工作流必须包含retroactive/Retroactive字样Step 5 审计器约束随模式变化必须同时包含 Verify mitigations计划期与 Retroactive追溯期两种约束表述。同文件还包含对审计器 agent 的工具集断言必须含 Read/Bash/Glob/Grep必须不含 Write/Edit即 #2119 单写者契约、对 config.json 默认值的断言workflow.security_enforcement: true、workflow.security_asvs_level: 1、workflow.security_block_on: high、以及对 VALIDATION.md 模板Threat Ref与Secure Behavior列的断言。这些测试遵循仓库 source-text-is-the-product 的测试规则工作流 / agent / 命令 Markdown 文本本身就是运行时加载的契约测试文本内容即测试部署后的契约。六、配置参数与实操建议secure-phase 相关的三个核心配置项默认值来自 gsd-core/templates/config.json与测试断言一致配置键默认值语义workflow.security_enforcementtrue安全强制开关置为false时工作流会退出并提示通过/gsd:settings开启workflow.security_asvs_level1验证深度L1 grep 存在性 / L2 边界位置 / L3 端到端追踪也决定threats_open: 0时是否允许短路workflow.security_block_onhigh阻断阈值criticalhighmediumlownone只有达到或超过该严重度的 OPEN 威胁计入threats_open实际使用建议运行/gsd-secure-phase {N}前先确认阶段已执行State C 会干净退出并给出引导对新项目gsd-planner在security_enforcement启用时要求每个 PLAN 必须包含threat_model块agents/gsd-planner.md 中的强制要求因此新阶段天然满足register_authored_at_plan_time: true对历史遗留阶段本次修复意味着不再能依赖空 PLAN 快速过关——审计器会以 retroactive-STRIDE 模式从实现文件重建登记簿这是刻意的安全代价而非缺陷若阶段推进被threats_open 0阻断只能通过补实现缓解措施后重跑/gsd-secure-phase {N}或在 SECURITY.md 中记录已接受风险后重跑——工作流明确禁止在此状态下发出下一阶段路由。七、总结PR #3142 对 issue #3120 的修复本质上是一次语义消歧把threats_open: 0从单一布尔条件拆解为威胁数量与登记簿来源两个独立维度。register_authored_at_plan_time使工作流能够回答这个零威胁结论是审计出来的还是从未审计过的这一问题从而堵住遗留阶段绕开安全审计的路径。整个契约由工作流原文、审计器 agent 定义、SECURITY.md 模板与折叠回归测试共同锚定任何人修改 secure-phase 的行为都会在这些结构断言中现形。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐get-shit-done 如何用 /gsd-secure-phase 对已完成 phase 做威胁验证并配置 ASVS 级别get shit done 如何用 /gsd secure phase 对已完成 phase 做威胁验证并配置 ASVS 级别 在 get shit done人工智能AI 应用提示工程开发工具工作流自动化AI Agentgsd-core W002 误报修复详解/gsd:health 为何不再为已归档 Phase 报错gsd core W002 误报修复详解/gsd:health 为何不再为已归档 Phase 报错 本文围绕 gsd core 仓库中的一个变更集记录chagsd-core /gsd-discuss-phase 模式路由修复让 workflow.discuss_mode: assumptions 在 shim-only 安装下也能被正确遵守gsd core /gsd discuss phase 模式路由修复让 workflow.discuss_mode: assumptions 在 shim o上一篇探索未来视觉体验gl-react 深度解析与实践下一篇标题【开源推荐】Bi ShengReact驱动的Markdown静态网站构建工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考