安全需求分析流程：识别安全需求、编写安全用例、确定验收标准

安全需求分析是 PBL 安全引导阶段的核心环节，旨在将模糊的安全关注转化为可落地、可验证的结构化需求。本章按照固定 SOP 组织正文，确保流程可重复、责任可追溯、验收有依据。

适用场景

• 项目进入需求分析阶段，需同步识别安全约束条件。
• 系统涉及用户数据、网络通信、访问控制、隐私合规等安全属性。
• 需要对安全功能（认证、审计、加密、完整性）进行优先级排序的场景。

前置条件

1. 已获得经过批准的《系统需求规格说明书》或《用户故事清单》。
2. 已完成威胁建模（STRIDE / 攻击树），并输出了威胁列表。
3. 安全引导组已与产品负责人、开发组长完成职责对齐会议。

操作步骤

步骤编号	活动	关键输入	执行角色
1	从威胁列表中提取不可接受的风险项，转化为安全需求语句	威胁列表、业务上下文	安全分析师
2	为每条安全需求编写安全用例（用户目标层级）	安全需求语句	安全分析师 + 测试代表
3	为每个安全用例定义通过/失败验收标准	安全用例、合规要求	产品负责人 + 安全引导组
4	将安全需求、用例、验收标准写入《安全需求规格》文档	以上全部	安全分析师（归档）

输入输出物

类型	名称	示例 / 备注
输入	威胁列表	包含威胁ID、描述、影响等级
输入	系统需求规格（基线版）	功能需求 + 非功能指标
输出	《安全需求规格》文档	含安全需求表、安全用例表、验收标准清单
输出	安全需求评审记录	会议纪要、确认签字

责任边界

• 安全分析师：主导安全需求提取和用例编写，确保每条需求可追溯到具体威胁。
• 产品负责人：审核安全需求与业务目标的冲突，批准验收标准。
• 开发组长：评估安全用例的实现可行性，反馈技术限制。
• 测试代表：为安全用例编写测试脚本提供边界条件。

记录材料

需求ID: SR-001
需求来源: 威胁 T-003（未授权 API 访问）
安全需求: 系统必须对所有 REST API 调用执行基于 JWT 的身份验证。
优先级: 高
所属组件: API 网关
验收标准: 未携带有效 JWT 的请求返回 401，并记录审计日志。

异常处理

异常情况	处理措施	升级路径
威胁列表中找不到对应安全需求	回退至威胁建模步骤，补充遗漏威胁	安全引导组长介入
验收标准无法量化	分解为“必须 / 应当 / 建议”层级，优先满足“必须”	产品负责人与安全引导组协商
安全需求与业务需求冲突	启动风险接受流程，记录在《风险登记册》	项目决策委员会

验收标准

1. 输出文档包含至少 1 条可追溯到威胁的需求。
2. 每个安全需求对应至少 1 个安全用例，且用例包含前置条件、正常流程、异常流程。
3. 验收标准通过/失败判定条件明确，且经产品负责人签字确认。
4. 未出现安全需求与功能需求相互矛盾而未记录的例外。