【 14个概念 】
漏洞闭环
难易分类
简单概念
1 检测任务单
概念解释：记录授权、范围、时间、工具、联系人、影响控制和结果位置的文档。
实例：公司针对订单系统形成一份《检测任务单》，其中写明适用对象、执行内容、责任人员和结果证据。这份可以编号、查阅和归档的文件就是检测任务单。
易混淆：把“检测任务单”和“漏洞台账”混为一谈。检测任务单的关键是“记录授权、范围、时间、工具、联系人、影响控制和结果位置的文档”；漏洞台账关注的是另一种对象、位置、作用或处理关系。
2 漏洞
概念解释：系统、应用、组件、配置或流程中可能被利用的弱点。
实例：2026年7月23日10点05分，监控平台在订单系统中记录一项漏洞，工单中写明时间、对象、表现和状态。这是一项可以单独登记和追踪的漏洞。
易混淆：把“漏洞”和“安全缺陷”混为一谈。漏洞的关键是“系统、应用、组件、配置或流程中可能被利用的弱点”；安全缺陷关注的是另一种对象、位置、作用或处理关系。
3 安全缺陷
概念解释：弱口令、权限过宽、默认配置、过期组件和暴露端口等不足。
实例：2026年7月23日10点05分，监控平台在订单系统中记录一项安全缺陷，工单中写明时间、对象、表现和状态。这是一项可以单独登记和追踪的安全缺陷。
易混淆：把“安全缺陷”和“漏洞”混为一谈。安全缺陷的关键是“弱口令、权限过宽、默认配置、过期组件和暴露端口等不足”；漏洞关注的是另一种对象、位置、作用或处理关系。
4 漏洞台账
概念解释：记录漏洞资产、版本、等级、责任人、期限、状态和复测结果的清单。
实例：数据安全人员把订单系统的对象、责任、状态和检查结果逐项登记到一份表中，并持续更新。这份可查询的记录就是漏洞台账。
易混淆：把“漏洞台账”和“资产台账”混为一谈。漏洞台账的关键是“记录漏洞资产、版本、等级、责任人、期限、状态和复测结果的清单”；资产台账关注的是另一种对象、位置、作用或处理关系。
难懂概念
5 数据安全检测
概念解释：通过制度检查、配置核查、权限复核、日志审计和漏洞扫描发现风险。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：数据安全检测需要覆盖正常、异常和边界条件，并保存可复现证据。
6 漏洞扫描
概念解释：使用工具检测主机、应用、组件和配置中的已知风险。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：漏洞扫描需要覆盖正常、异常和边界条件，并保存可复现证据。
7 授权扫描
概念解释：在明确授权、范围、窗口和停止条件后开展的扫描。
主要对应的问题：谁在什么条件下可以访问什么对象、执行什么操作，权限何时复核、到期和回收？
特殊异常情况：人员已经离岗，隐藏权限和服务凭证仍然有效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：授权扫描需要覆盖正常、异常和边界条件，并保存可复现证据。
8 漏洞管理闭环
概念解释：漏洞从发现、登记、研判、修复、验证到归档的过程。
主要对应的问题：在订单系统的实际工作中，怎样确认“漏洞管理闭环”已经做到“漏洞从发现、登记、研判、修复、验证到归档的过程”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，漏洞管理闭环遗漏6个关键环节
2026年10月20日，一家企业在订单系统中执行漏洞管理闭环。常规抽查的20条记录均显示正常；当天新增第三方接口并处理8696条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“漏洞从发现、登记、研判、修复、验证到归档的过程”重新核查，才找到未被原流程覆盖的环节。这个实例说明：漏洞管理闭环需要在真实业务变化和边界条件下接受验证。
9 漏洞研判
概念解释：结合资产、暴露面、影响、利用条件和现有控制判断实际风险。
主要对应的问题：在订单系统的实际工作中，怎样确认“漏洞研判”已经做到“结合资产、暴露面、影响、利用条件和现有控制判断实际风险”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，漏洞研判遗漏7个关键环节
2026年10月21日，一家企业在订单系统中执行漏洞研判。常规抽查的20条记录均显示正常；当天新增第三方接口并处理8733条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“结合资产、暴露面、影响、利用条件和现有控制判断实际风险”重新核查，才找到未被原流程覆盖的环节。这个实例说明：漏洞研判需要在真实业务变化和边界条件下接受验证。
10 技术严重性
概念解释：漏洞本身可能造成影响的程度。
主要对应的问题：什么因素可能造成损害，发生可能性和后果有多大，现有措施能否把风险控制到可接受范围？
特殊异常情况：单项风险很低，多项条件汇聚后形成重大影响
某平台分别保存年龄区间、邮政编码、商品类别和分钟级下单时间，单个字段都很普通。分析人员把4类字段与公开信息关联后，在10万名顾客中锁定了3个人。这个实例说明：技术严重性会随数据组合、使用环境和利用条件发生变化。
11 业务风险
概念解释：漏洞结合实际业务、数据和环境后形成的真实风险。
主要对应的问题：什么因素可能造成损害，发生可能性和后果有多大，现有措施能否把风险控制到可接受范围？
特殊异常情况：单项风险很低，多项条件汇聚后形成重大影响
某平台分别保存年龄区间、邮政编码、商品类别和分钟级下单时间，单个字段都很普通。分析人员把4类字段与公开信息关联后，在10万名顾客中锁定了3个人。这个实例说明：业务风险会随数据组合、使用环境和利用条件发生变化。
12 补偿措施
概念解释：暂时不能彻底修复时，用限制、认证、审计和告警降低风险。
主要对应的问题：在订单系统的实际工作中，怎样确认“补偿措施”已经做到“暂时不能彻底修复时，用限制、认证、审计和告警降低风险”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，补偿措施遗漏3个关键环节
2026年10月24日，一家企业在订单系统中执行补偿措施。常规抽查的20条记录均显示正常；当天新增第三方接口并处理8844条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“暂时不能彻底修复时，用限制、认证、审计和告警降低风险”重新核查，才找到未被原流程覆盖的环节。这个实例说明：补偿措施需要在真实业务变化和边界条件下接受验证。
13 漏洞例外
概念解释：经审批在限定期限内接受未修复漏洞的剩余风险。
主要对应的问题：在订单系统的实际工作中，怎样确认“漏洞例外”已经做到“经审批在限定期限内接受未修复漏洞的剩余风险”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，漏洞例外遗漏4个关键环节
2026年10月25日，一家企业在订单系统中执行漏洞例外。常规抽查的20条记录均显示正常；当天新增第三方接口并处理8881条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“经审批在限定期限内接受未修复漏洞的剩余风险”重新核查，才找到未被原流程覆盖的环节。这个实例说明：漏洞例外需要在真实业务变化和边界条件下接受验证。
14 复测
概念解释：整改后重新验证问题是否已解决。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：复测需要覆盖正常、异常和边界条件，并保存可复现证据。