security-requirement-extraction（安全需求提取）Skill 是什么？如何下载安装？

安全需求提取Skill：把威胁模型一键转化为可测试、可追溯的安全需求

核心定位：security-requirement-extraction（安全需求提取）是一个把“威胁分析结论”翻译成“可落地安全需求”的 AI 技能，技能 ID 为 13182。
主要产出：安全需求条目、验收标准、安全测试用例、安全用户故事、合规映射矩阵、威胁可追溯矩阵与安全史诗（Epic）。
方法论基础：内置 STRIDE 威胁类别到安全领域的映射规则，覆盖认证、授权、数据保护、审计日志、输入校验、错误处理、会话管理、加密、网络安全、可用性十大领域。
自动化能力：根据威胁的影响程度与发生可能性自动计算需求优先级，并为每条需求生成配套验收标准与测试用例，避免“写了但测不了”。
合规友好：内置 PCI DSS、HIPAA、GDPR、SOC2、NIST CSF、ISO 27001、OWASP 等框架的控制项映射，可做差距分析（Gap Analysis）。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

security-requirement-extraction（安全需求提取），技能 ID：13182。它要解决的问题非常具体：安全团队做完威胁建模后，往往得到一堆“可能被冒充”“可能被篡改”“可能信息泄露”的描述，但研发团队拿到这些描述后无从下手——不知道该写什么需求、需求怎么验收、测试怎么写用例、上线前怎么证明合规。这个技能就是把“威胁语言”转成“研发语言”和“测试语言”。

在传统流程里，从威胁模型到安全需求再到测试用例，往往需要安全工程师逐条人工翻译，一份中等规模的系统动辄几十条威胁，耗时数天且容易遗漏。AI 技能化后的思路是“一键装配”：把威胁清单作为输入，由技能按既定模板与方法论批量生成结构化需求，人只做复核与裁剪。

安装思路与步骤（通用流程）：

确认安装前提：需要一个支持 AI 技能（Skill）机制的运行环境，例如具备技能市场或技能目录的 AI 编程助手、IDE 插件或智能体平台；同时准备一份可用于输入的威胁模型或威胁清单（STRIDE 分类最佳）。
获取技能：在所用平台的技能市场、技能库或以官方提供的分发入口检索技能名 security-requirement-extraction 或技能 ID 13182；具体的 marketplace 地址、CLI 命令与安装参数以官方说明为准。
完成安装/启用：按平台提示添加技能，或在项目配置中声明引用该技能；若平台采用“技能目录 + 配置文件”的方式，将技能放入指定目录并在配置中登记即可，具体路径以官方说明为准。
验证是否生效：向助手提出“请用安全需求提取技能，把我这份 STRIDE 威胁清单转成安全需求”，若返回内容包含需求编号（如 SR-001）、需求类型、安全领域、优先级、验收标准、测试用例与威胁引用，说明技能已正常工作；也可要求其输出“威胁到需求的可追溯性矩阵”做进一步确认。
沉淀为团队资产：把生成结果按需求编号纳入 Jira、需求管理工具或安全架构文档，并在后续迭代中持续补充新威胁，形成可复用的需求库。

该技能的主要功能和特点

需求分级链条清晰：遵循“业务需求 → 安全需求 → 技术控制”的推导结构。例如业务需求是“保护客户数据”，安全需求是“加密静态 PII”，技术控制才是“AES-256 加密配合 KMS 密钥轮换”。这种三层拆解避免了把实现手段直接当需求写。
三类需求类型划分：功能性（系统必须做什么，如“系统必须认证用户”）、非功能性（系统必须如何执行，如“认证必须在 2 秒内完成”）、约束（施加的限制，如“必须使用批准的加密库”）。
四类需求属性自带治理能力：可追溯性（链接到威胁与合规条目）、可测试性（可验证）、优先级（业务重要性）、风险级别（未满足时的影响）。
安全需求数据模型（模板 1）：以结构化对象定义每条需求，包含编号、标题、描述、类型、领域、优先级、理由、验收标准、测试用例、威胁引用、合规引用、依赖、状态、负责人与创建时间；并支持转换为用户故事格式与测试规范格式，支持按领域、优先级、威胁筛选，支持导出 Markdown 需求文档与生成威胁可追溯矩阵。
威胁到需求提取器（模板 2）：内置 STRIDE 六类威胁（冒充、篡改、抵赖、信息泄露、拒绝服务、权限提升）到安全领域与需求模式的双向映射，为每类威胁预置多条需求句式，并自动生成验收标准与测试用例。
优先级自动计算：按影响程度与发生可能性的乘积打分，映射为“严重/高/中/低”四档，帮助团队在资源有限时先做关键项。
合规映射与差距分析（模板 3）：把需求按安全领域映射到 PCI DSS、HIPAA、GDPR、OWASP 等框架的具体控制项，可反向查询“某个控制项由哪些需求满足”，并输出缺口清单（缺失控制、覆盖薄弱控制）。
安全用户故事与史诗生成（模板 4）：按安全领域套用“作为……我希望……以便……”的叙事模板，自动附加完成定义（实施完成、安全测试通过、代码审查、安全审查批准、文档更新）与安全测试用例，方便直接贴进迭代看板。
内置最佳实践纪律：强调威胁可追溯、需求具体化、必带验收标准、尽早映射合规、定期复审；同时明确反对“把‘安全’当需求”“跳过理由”“忽略优先级”“忘记可测试性”“闭门造车”等反模式。

与普通工具相比，它的差异点在于“不是给你一份通用安全清单”，而是围绕你已有的威胁生成带追溯关系与验收标准的定制需求集合；与纯聊天式提问相比，它输出的是结构一致、字段齐全、可批量复用的需求对象，而非散落的文字段落。

如何使用该技能？

第 1 步：准备输入。 整理威胁清单，每条威胁至少包含：编号、STRIDE 类别、标题、描述、目标对象、影响程度、发生可能性。示例（中文表述即可）：

编号 T-01，类别：信息泄露，标题：“订单查询接口返回明文手机号”，目标：订单服务，影响：高，可能性：中。
编号 T-02，类别：权限提升，标题：“普通用户可通过修改 URL 参数访问他人订单”，目标：订单详情接口，影响：严重，可能性：高。
编号 T-03，类别：抵赖，标题：“后台删除操作无操作人记录”，目标：管理后台，影响：中，可能性：高。

第 2 步：发起调用。 在对话或工作流中明确指令，例如：“使用安全需求提取技能，基于以下威胁清单，为订单系统生成安全需求集合，版本 1.0，要求包含验收标准与测试用例，并输出威胁可追溯矩阵。”随后粘贴上述威胁清单。

第 3 步：指定输出格式。 可以要求三种形态之一或全部：结构化需求对象（便于入库）、安全用户故事（便于进迭代）、测试规范（便于测试同学执行）；也可要求“按安全领域分组导出 Markdown”。

第 4 步：读取输出。 典型输出会包含：

需求条目：如 SR-001「加密订单服务中的敏感数据」，类型为功能性，领域为数据保护，优先级为严重（因影响高×可能性中经打分后判定），理由为“缓解威胁：订单查询接口返回明文手机号”，威胁引用 T-01。
验收标准：敏感数据已加密、对敏感数据的访问被记录、错误消息不暴露敏感信息。
测试用例：验证订单数据在传输时加密、在静态时加密、错误消息已净化。
可追溯矩阵：威胁 T-01 对应需求 SR-001、SR-002……，一眼看出哪条威胁还没被覆盖。

第 5 步：做合规映射。 追加指令：“把上述需求映射到 PCI DSS 与 OWASP，并给出差距分析。”技能会返回各控制项对应的需求编号，以及“缺失控制”和“覆盖薄弱（少于 2 条需求支撑）”两类缺口。

第 6 步：人工复核与落库。 逐条确认需求是否具体、可测、优先级合理，剔除与业务不符的模板句式，补充负责人与状态，再导入需求管理工具；后续每轮威胁建模后增量更新。

第 7 步：接入研发流程。 将用户故事贴入迭代，将测试用例交给测试团队转为自动化用例，将可追溯矩阵作为安全评审与合规审计的举证材料。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
security-requirement-extraction（本技能）	威胁到安全需求的自动化翻译器	STRIDE 映射、需求模型、优先级打分、验收标准与测试用例生成、合规映射与差距分析、可追溯矩阵、用户故事与史诗生成	需支持 Skill 的运行环境，按平台入口安装，具体命令与入口以官方说明为准；输入需具备基本威胁清单	已做威胁建模、需要快速产出安全需求与测试用例的研发/安全团队	优势：结构化、可追溯、模板完整、与合规框架打通；不足：依赖输入质量，模板句式需人工裁剪，深度业务语义仍需专家把关
人工编写安全需求文档	传统安全工程流程	由安全工程师基于经验与清单逐条撰写	无需工具，但需资深人力；周期以人日计	小规模系统、强监管行业的正式文档	优势：贴合业务、责任清晰；不足：慢、易遗漏、不同人产出质量差异大、难以批量维护追溯关系
通用大模型对话式生成	用聊天方式让模型“写安全需求”	自由问答、可生成任意文本	门槛最低，打开即用	临时性、探索性需求草稿	优势：灵活、无需安装；不足：输出结构不稳定、字段缺失、难以批量与复用，缺少优先级模型、合规映射与可追溯机制
威胁建模/风险管理平台	图形化威胁建模与风险登记	数据流图建模、威胁库、风险评估、部分平台含需求与合规模块	需采购与部署，学习曲线较陡，价格以官方说明为准	企业级安全体系、需要统一治理的组织	优势：可视化、治理能力强；不足：需求文本生成与测试用例细化能力有限，落地到研发迭代仍需二次加工
需求管理工具的安全模板	在 Jira/需求库中套用安全需求模板	需求条目管理、状态流转、报表	需已有工具与模板配置	已有成熟需求管理体系的团队	优势：与研发流程天然集成；不足：只提供“容器”，不提供从威胁推导需求的推导逻辑与自动生成能力

该技能的典型应用场景与实际体验情况

场景一：敏捷团队的安全左移落地。 角色是研发团队的安全负责人。痛点：每个迭代都在赶功能，安全需求只停留在“注意 XSS”“注意越权”这种口号层面，测试同学无法据此写用例。使用方式：在迭代规划会上把上一轮威胁建模的清单输入技能，要求按领域生成用户故事，直接贴进看板。实际体验：上手难度低，几乎不需要额外学习成本，因为输出就是团队熟悉的故事格式；效果最明显的是“完成定义”一栏，把安全测试通过与安全审查批准写进验收，安全动作不再靠人盯；注意事项是要对模板句式做业务化改写，避免出现“作为一个安全意识强的系统”这类生硬表述直接进入正式文档。

场景二：合规审计前的举证准备。 角色是安全合规专员。痛点：审计时要回答“这条 PCI DSS 控制项你们是怎么满足的”，需要从控制项倒查需求、再从需求倒查实现与测试。使用方式：把已有需求集合输入技能，要求生成合规矩阵与差距分析。实际体验：差距分析的“覆盖薄弱”提示非常实用，能快速发现某控制项只有一条需求支撑、证据不足；注意事项是技能给出的控制编号为框架级映射，正式审计仍需对照官方条文逐条确认，具体条款以各框架官方发布为准。

场景三：老系统改造的安全需求补齐。 角色是架构师。痛点：系统运行多年，安全需求从未正式沉淀，改造时无法判断“哪些安全能力必须保留”。使用方式：用 STRIDE 逐类梳理威胁后交给技能批量生成需求，再按优先级筛选出严重与高优先级项作为改造必做清单。实际体验：自动优先级打分显著减少了团队争论，影响与可能性的打分一旦对齐，排序就客观得多；注意事项是打分依赖输入的准确性，建议由安全与业务共同确认威胁的影响程度，避免“全都填高”。

场景四：把安全需求写成可执行的测试用例。 角色是测试工程师。痛点：安全测试往往靠渗透测试兜底，常规回归里没有安全用例。使用方式：要求技能输出“测试规范”格式，把每条需求的测试用例抽出来纳入自动化回归。实际体验：生成的用例偏向验证方向（如“未认证访问被拒绝”“篡改数据被检测并拒绝”），适合作为用例设计起点，需要测试同学补充具体请求构造与断言；注意事项是不要把生成用例当作渗透测试的替代，它覆盖的是需求验证而非漏洞挖掘。

该技能能为用户带来的价值

把“威胁”变成“待办”：以往威胁建模报告常被束之高阁，现在每条威胁都能落到带编号、带优先级、带负责人的需求条目上，安全工作的可见度显著提升。
效率层面的直接收益：原本需要安全工程师逐条人工翻译并撰写验收标准的环节，可由技能批量生成初稿，人只需复核与裁剪；对于几十条威胁的中型系统，这一环节的投入从“以天计”压缩到“以小时计”，具体节省幅度取决于团队规模与威胁数量。
降低专业门槛：没有专职安全工程师的团队，也能沿着“威胁清单 → 需求 → 验收标准 → 测试用例”的路径走完流程，方法论由技能内置，减少“不知道从哪写起”的困境。
可追溯与可审计：威胁可追溯矩阵与合规矩阵让“为什么做这条需求”“这条控制项谁来满足”都有据可查，安全评审与合规审计的举证成本大幅下降。
口径统一：需求类型、安全领域、优先级、验收标准格式全部标准化，跨团队、跨迭代的需求质量不再取决于“谁写的”，长期看有利于沉淀组织级安全需求基线。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ 在支持 AI 技能机制的平台上检索技能名 security-requirement-extraction 或技能 ID 13182 即可获取，安装入口、命令与是否需要付费均以官方说明为准。安装后建议先用一份小规模威胁清单试跑，确认输出包含需求编号、优先级、验收标准与测试用例后再正式使用。

Q2：它适不适合没有安全背景的团队？ 适合作为起点。技能内置了 STRIDE 到安全领域的映射、需求句式、验收标准与测试用例模板，即使没有专职安全工程师也能产出成体系的需求初稿。但它替代不了安全专家：威胁识别是否全面、需求是否贴合业务、优先级打分是否合理，仍需要人判断。

Q3：它和直接问通用大模型“帮我写安全需求”有什么区别？ 通用对话输出的是自由文本，结构不稳定、字段常缺失、难以批量复用；本技能输出的是带编号、类型、领域、优先级、威胁引用、验收标准、测试用例的结构化需求，还额外提供可追溯矩阵、合规映射与差距分析，并且遵循统一的推导链条与最佳实践纪律，便于入库和长期维护。

Q4：生成的合规映射能直接用于审计吗？ 不能直接作为审计结论。技能提供的是“需求—控制项”的映射关系与覆盖情况分析，属于准备材料；正式审计仍需对照各框架官方条文核验，具体条款编号与解释以官方发布为准，建议由合规负责人复核后使用。

Q5：适合谁用？和传统威胁建模平台怎么选？ 最适合已完成威胁建模、急需把威胁转成研发与测试可执行项的团队，包括研发负责人、架构师、测试工程师与安全合规人员。若组织更需要图形化建模与统一风险管理，可继续用威胁建模平台，并把本技能作为“需求生成与合规映射”的下游环节配合使用，两者并不冲突。