先登记发现的问题
每个漏洞先进入台账。
安全人员
“配方服务器发现一个过期组件。”
小白
“先让运维升级吗？”
师傅
“先登记。”
小白
“登记什么？”
师傅
“资产、位置、版本、责任人、发现时间和当前状态。”
【 第 2 步 】
漏洞扫描室
师傅：“昨天的基础检测发现了一批弱口令、开放端口和过期组件，今天我们进入漏洞管理。漏洞不是扫出来以后交给技术人员改一下就结束，而要形成一个完整的漏洞管理闭环：发现、登记、研判、修复、验证、归档。
判断漏洞风险时，还要同时看资产重要性、是否对外暴露、影响范围、利用条件、现有控制和修复对业务的影响。正式扫描前必须先完成授权扫描，明确目标、时间、工具、联系人和停止条件；
修复完成以后还要进行复测验证。同一个技术漏洞放在互联网系统和隔离测试环境中，实际风险可能完全不同，所以技术严重程度不能代替业务研判。”
01 · 现场对话
漏洞扫描室的知识任务
再判断实际风险
不能只看扫描等级。
小白
“工具显示‘高危’，那就是最高优先级吗？”
师傅
“先看这台服务器承载什么。”
小白
“里面是30份核心配方。”
师傅
“再看它是否对外暴露、利用条件是什么、已有控制能不能降低风险。”
小白
“所以要结合业务一起判断。”
修复也要控制风险
整改本身可能影响生产。
运维人员
“升级组件需要重启服务。”
小白
“那不能直接白天重启。”
师傅
“对。要安排维护窗口，准备备份和回退。”
小白
“修漏洞也属于一次受控变更。”
师傅
“对。”
修完以后重新验证
“已修复”不是闭环终点。
运维人员
“升级已经完成。”
小白
“现在重新扫描原问题。”
师傅
“还要确认业务正常。”
小白
“问题消失、业务正常以后，再归档。”
师傅
“这才是完整闭环。”
02 · 小白做现场笔记
重要概念及注释
漏洞管理
- 正式含义
- 对漏洞持续开展发现、登记、风险研判、修复、验证和归档的闭环管理。
- 完整路线
- 发现 ↓ 登记 ↓ 研判 ↓ 修复 ↓ 验证 ↓ 归档教材把弱口令、权限过宽、默认配置、过期组件、暴露端口和审计关闭等都纳入漏洞或安全缺陷管理。
漏洞不是“扫出来”，而是要一直管到复测关闭。
漏洞风险研判
- 正式含义
- 结合漏洞的技术问题和真实业务环境，判断实际风险和处理优先级。
- 七个判断维度
- 资产重要性 暴露情况 影响范围 利用条件 补救条件 业务影响 现有控制同一个漏洞放在互联网核心系统和隔离测试环境中，实际风险可能不同。
漏洞等级不能只看工具上的“高、中、低”，还要看它落在哪里。
授权扫描
- 正式含义
- 在明确批准的目标、范围和时间窗口内执行漏洞扫描。
- 扫描前先确认
- 扫描哪些IP和系统 使用什么工具 什么时候执行 是否影响业务 谁负责联系 什么情况立即停止 结果保存在哪里第四模块明确要求所有扫描、日志核查、演练和恢复操作都在授权范围内执行。
扫描先有边界，再有工具。
漏洞台账
- 正式含义
- 用于持续记录漏洞对象、等级、责任人、计划和当前状态的管理清单。
- 基本字段
- 编号 资产 发现项 风险等级 责任人 计划完成时间 当前状态 复测结果教材中的漏洞台账也按这一结构记录。
漏洞台账回答：哪里有问题、谁来改、什么时候改完、有没有复测。
漏洞修复
- 正式含义
- 通过补丁、升级、配置调整、关闭服务或强化访问控制等方式消除或降低漏洞风险。
- 面包厂场景
- 发现配方服务器组件过期：确认影响 ↓ 安排维护窗口 ↓ 备份 ↓ 升级组件 ↓ 检查业务 ↓ 重新扫描
修漏洞也属于生产变更，不能为了“快”而制造新的故障。
漏洞例外
- 正式含义
- 由于兼容性或业务原因暂时不能修复漏洞时，在限定条件和期限内正式接受剩余风险。
- 例外需要写清
- 为什么不能立即修 剩余风险是什么 采用什么补偿措施 谁负责 有效到什么时候 什么时候重新复核例外并不等于问题关闭，到期后仍需修复、复核或重新审批。
例外是“暂时受控地保留问题”，不是“以后不用管了”。
复测验证
- 正式含义
- 整改以后重新检查原漏洞是否已经消除，同时确认业务功能和性能正常。
- 复测检查
- 补丁版本正确吗？ 配置真的修改了吗？ 端口关闭了吗？ 权限收敛了吗？ 重新扫描还存在吗？ 业务还能正常运行吗？
“技术人员说已经修复”不是证据，重新验证才是。
03 · 经验和难点
小结
这一站，小白完成了从漏洞发现、登记、风险研判、整改到复测归档的完整流程。最值得记住的经验是：漏洞等级要同时结合技术严重性和真实业务环境判断。初学者最容易遇到的难点，是直接按照扫描工具的等级安排整改，却没有考虑资产价值、暴露情况、现有控制和修复本身带来的业务影响。