安全测试计划模板:资产范围与风险分级字段
安全测试计划模板的核心是两张表:一张逐项登记资产范围,一张按影响程度与发生可能性做风险分级。本文直接给出可复制的空白表、字段填写口径、必填规则和一份完整填写示例,并说明模板在资产变更和复评时如何维护,帮助团队把测试深度与退出准则落到可验收的计划里。
Table of Contents
要点总览(TL;DR)
- 模板由计划头信息、资产范围清单、风险分级评分表、依赖约束与退出准则四张表组成,用资产编号和风险编号互相引用。
- 资产范围表逐项记录资产名称、类型、所属系统、数据敏感级别、网络暴露面、责任人和是否纳入测试,排除项必须写明理由。
- 风险分级按影响程度与发生可能性各1–3分相乘,7–9分为高、4–6分为中、1–3分为低,阈值调整需在计划中写明。
- 风险等级决定测试深度与复测要求:高风险做深度测试并必须复测,中风险标准测试加抽检复测,低风险基础核查随版本回归。
- 资产编号、名称、类型、责任人、是否纳入测试为必填;纳入测试的资产缺敏感级别或暴露面时退回补充,不进入风险评分。
可复制空白模板:资产范围表与风险分级表
模板由三块组成:计划头信息确定这份计划的身份和边界,资产范围清单确定测什么、不测什么,风险分级评分表确定每项资产测多深、是否复测。三张表用资产编号和风险编号互相引用,复制到文档或表格工具后即可填写。
表一:计划头信息
| 字段 | 填写内容 |
|---|---|
| 计划名称 | |
| 版本 | |
| 编制人 | |
| 评审人 | |
| 生效日期 | |
| 适用范围 |
表二:资产范围清单
| 资产编号 | 资产名称 | 资产类型 | 所属系统/业务 | 数据敏感级别 | 网络暴露面 | 责任人 | 是否纳入测试 | 排除理由 |
|---|---|---|---|---|---|---|---|---|
表三:风险分级评分表
| 风险编号 | 关联资产编号 | 威胁场景 | 影响程度 | 发生可能性 | 风险分值 | 风险等级 | 测试深度 | 复测要求 |
|---|---|---|---|---|---|---|---|---|
表四:依赖约束与退出准则
| 类别 | 条目 | 说明 | 责任方 | 确认状态 |
|---|---|---|---|---|
| 依赖 | ||||
| 约束 | ||||
| 退出准则 |
字段说明:每个字段填什么、怎么判
同一份模板由不同团队填写时,结果能否比较,取决于每个字段是否有统一的取值口径。下表给出字段字典,重点在判定依据,而不在字段名称本身。
| 字段名 | 填写说明 | 取值范围 | 判定依据 |
|---|---|---|---|
| 资产类型 | 按资产的存在形态归类 | Web应用、移动应用、API接口、数据库、主机与中间件、云资源、第三方服务 | 以资产实际部署形态为准,一个资产只选一个主类型 |
| 数据敏感级别 | 按资产承载数据的敏感程度定级 | 公开、内部、敏感、核心 | 看数据泄露后的直接后果:公开数据无实质影响;内部数据影响内部秩序;敏感数据涉及个人信息或商业机密;核心数据涉及资金、身份认证或监管要求 |
| 网络暴露面 | 按资产可被访问的范围判断 | 互联网可达、内网可达、仅本地 | 互联网可达指无需内网接入即可访问;内网可达指需通过内网或VPN访问;仅本地指运行在单机或隔离环境 |
| 影响程度 | 威胁发生后对业务和数据的损害程度 | 1–3分:1轻微、2较重、3严重 | 结合数据敏感级别和业务中断时长判断,核心数据泄露或核心业务中断记3分 |
| 发生可能性 | 该威胁场景被利用的现实概率 | 1–3分:1低、2中、3高 | 结合暴露面和历史缺陷情况判断,互联网可达且无前置认证的场景记3分 |
| 风险分值 | 影响程度与发生可能性相乘 | 1–9分 | 由前两项计算得出,不单独主观调整 |
| 风险等级 | 由分值映射为等级 | 高、中、低 | 7–9分为高,4–6分为中,1–3分为低;团队可按合规要求调整阈值,但需在计划中写明 |
| 测试深度 | 该风险对应的测试投入程度 | 深度测试、标准测试、基础核查 | 高风险做深度测试,覆盖主要攻击路径;中风险做标准测试;低风险做基础核查 |
| 复测要求 | 修复后是否需要再次验证 | 必须复测、抽检复测、不复测 | 高风险必须复测并留存记录;中风险抽检复测;低风险随版本回归覆盖 |
风险等级与测试深度的联动是模板的关键:等级决定投入,投入决定退出条件。高风险项未完成深度测试和复测,计划不能判定通过;低风险项完成基础核查即可关闭。这样,资产范围表回答“测什么”,风险分级表回答“测到什么程度算完成”。
必填与选填:哪些字段不能空
必填字段的作用是保证每条记录可追溯、可分配、可验收。字段空缺时,模板应视为未填写完成,而不是默认通过。
| 字段 | 必填/选填 | 空缺处理 |
|---|---|---|
| 资产编号 | 必填 | 不可空缺,编号需唯一 |
| 资产名称 | 必填 | 不可空缺 |
| 资产类型 | 必填 | 不可空缺 |
| 责任人 | 必填 | 不可空缺,需为具体人员 |
| 是否纳入测试 | 必填 | 不可空缺,只能填是或否 |
| 数据敏感级别 | 纳入测试时必填 | 未定级则退回补充,不进入风险评分 |
| 网络暴露面 | 纳入测试时必填 | 未判断则退回补充 |
| 威胁场景 | 风险表必填 | 不可空缺,需描述具体场景 |
| 影响程度 | 风险表必填 | 不可空缺,取1–3分 |
| 发生可能性 | 风险表必填 | 不可空缺,取1–3分 |
| 风险等级 | 风险表必填 | 由分值映射,不手工留空 |
| 排除理由 | 条件必填 | 仅当是否纳入测试为否时必填 |
| 备注、参考文档 | 选填 | 可空缺,用于补充说明 |
空缺处理规则建议写进计划头信息的适用范围:纳入测试的资产缺少敏感级别或暴露面时,该资产不进入风险评分,计划评审不通过;排除项缺少排除理由时,视为范围未确认,同样退回补充。
填写示例:一份完整的安全测试计划片段
以下为演示情景,用于说明资产记录如何推导出风险等级、测试深度和退出准则,数据为示例值。
计划头信息:计划名称为“订单系统V3.2上线前安全测试”,版本V1.0,编制人为测试负责人,评审人为安全负责人与研发负责人,生效日期为上线前两周,适用范围为订单系统及其依赖的支付接口。
| 资产编号 | 资产名称 | 资产类型 | 所属系统/业务 | 数据敏感级别 | 网络暴露面 | 责任人 | 是否纳入测试 | 排除理由 |
|---|---|---|---|---|---|---|---|---|
| A-01 | 订单提交接口 | API接口 | 订单系统 | 核心 | 互联网可达 | 张工 | 是 | |
| A-02 | 订单管理后台 | Web应用 | 订单系统 | 敏感 | 内网可达 | 李工 | 是 | |
| A-03 | 订单日志库 | 数据库 | 订单系统 | 内部 | 仅本地 | 王工 | 是 | |
| A-04 | 旧版报表服务 | Web应用 | 报表系统 | 内部 | 内网可达 | 赵工 | 否 | 已停止对外服务,下季度下线 |
| 风险编号 | 关联资产编号 | 威胁场景 | 影响程度 | 发生可能性 | 风险分值 | 风险等级 | 测试深度 | 复测要求 |
|---|---|---|---|---|---|---|---|---|
| R-01 | A-01 | 未授权调用接口提交订单 | 3 | 3 | 9 | 高 | 深度测试 | 必须复测 |
| R-02 | A-02 | 后台越权查看他人订单 | 3 | 2 | 6 | 中 | 标准测试 | 抽检复测 |
| R-03 | A-03 | 日志中留存明文敏感字段 | 2 | 1 | 2 | 低 | 基础核查 | 不复测 |
由示例可推导退出准则:R-01为高风险,必须完成深度测试并复测通过,否则计划不通过;R-02为中风险,完成标准测试并抽检复测;R-03为低风险,完成基础核查即可关闭。A-04已排除,需在计划中保留排除理由,评审时确认其下线时间与本次上线无依赖。
当资产清单和风险条目需要在多个角色之间流转时,可以放到工作项和文档中管理。ONES 测试管理支持测试计划的规划和执行,并可多维度概览全部测试计划;测试用例可与需求、任务关联,测试计划与迭代关联,便于把风险条目对应的测试任务分配到责任人和迭代中。资产敏感级别、暴露面这类安全属性是否能用自定义字段承载,建议在实际试用时核验字段配置能力。
调整与维护:模板随项目变化怎么改
模板一次成型后容易与实际情况脱节,维护的重点是明确什么变化触发更新、谁来评审、如何留痕。
- 资产新增、下线、归属变更时更新:新增资产在进入测试范围前补录资产记录;资产下线时在是否纳入测试中改为否并填写排除理由;归属系统变更时同步修改所属系统/业务和责任人。
- 风险等级复评的周期与触发条件:建议每个迭代或每个上线窗口复评一次;出现新的外部暴露面、数据敏感级别提升、历史缺陷集中出现时立即复评,并更新风险分值与等级。
- 字段增删的评审与版本记录:字段调整需经测试负责人和安全负责人评审,在计划头信息的版本号中递增,并在版本记录中写明变更内容和生效日期。
- 与测试计划评审、退出验收的衔接:评审时核对必填字段是否完整、排除项理由是否充分;退出验收时按风险等级核对测试深度和复测记录是否齐全。
| 版本 | 变更日期 | 变更内容 | 变更人 | 评审人 |
|---|---|---|---|---|
维护规则与计划评审结合后,模板才能持续反映真实资产范围和风险状况。测试报告环节,ONES 测试管理支持自定义组装测试报告模板,可把风险等级、测试深度和复测结果按团队口径汇总,供退出验收时对照检查。
常见问题
资产范围清单里,哪些资产可以不纳入本次安全测试?
是否纳入测试是必填字段,填“否”时必须写明排除理由。常见情形包括已停止对外服务、计划下线的系统,或本次上线不依赖的旧服务。排除理由要具体到可核验的事实,例如“已停止对外服务,下季度下线”,并在计划评审时确认该资产与本次上线无依赖关系。理由空泛或缺失时,视为范围未确认,应退回补充。
风险分值的阈值可以按团队情况调整吗?
可以。模板给出的7–9分为高、4–6分为中、1–3分为低是常见分档,团队可以按合规要求或业务特点调整阈值。调整时需要满足两个条件:一是在计划头信息或字段说明中写明所用阈值,保证评审和验收时口径一致;二是调整后仍保持等级与测试深度、复测要求的对应关系,避免出现高风险项只做基础核查的情况。
同一资产对应多个威胁场景时,风险记录怎么填?
按威胁场景逐条建风险记录,每条记录用关联资产编号指回同一资产,风险编号保持唯一。例如一个订单提交接口可能同时存在未授权调用和数据篡改两个场景,就分别建两条风险记录,各自评分并映射等级。测试深度和复测要求按每条记录自身的等级确定,退出验收时逐条核对,避免用一条记录合并多个场景导致高风险被平均掉。
计划执行中途新增资产或暴露面变化,模板怎么处理?
新增资产在进入测试范围前补录资产记录,补齐必填字段后再做风险评分;资产下线时把是否纳入测试改为“否”并填写排除理由;出现新的外部暴露面或数据敏感级别提升时立即复评相关风险,更新分值与等级,并同步调整测试深度和复测要求。字段或范围调整需经测试负责人和安全负责人评审,在版本号中递增并记录变更内容与生效日期。
资产清单和风险条目在多个角色之间流转,用什么方式承载比较合适?
可以把资产记录和风险条目放到工作项与文档中管理,让责任人、测试任务和复测记录挂在同一条目下。ONES 测试管理支持测试计划的规划和执行,并可多维度概览全部测试计划;测试用例可与需求、任务关联,测试计划与迭代关联,便于把风险条目对应的测试任务分配到责任人和迭代中。资产敏感级别、暴露面这类安全属性能否用自定义字段承载,建议在实际试用时核验字段配置能力。



