背景

甲方企业安全建设的本质上是风险管理，随着业务发展阶段、形态不同，逐渐衍生出各个风险域的风险管理（基础设施、核心数据、内容、业务、mobile等）。风险的变化是动态的，风险管理也不是一成不变的，要求我们结合动态变化的风险、目标、资源等因素综合评估来投入，确保风险『可控』 —— 严重/高危风险动态清零。

风险管理中，最基础/最绕不开的一个话题是：漏洞修复（风险闭环），从实习生、技术骨干、TL、CISO都绕不开。不同的角色在其中承担的职责也不一样。最近scope中牵扯到一部分漏洞修复的问题，非SDL背景，本文就主要围绕，『如何更高效修复漏洞』，谈一谈我的看法，列举几个典型的场景（持续扩充）。

写作时间：2026年4月28日 23:19:16
写作时长：40min

结论（理想状态）

安全与业务之间的沟通成本很小，协作效率很高，两个agent都遵循一套标准的交互流程/接口去努力。具体表现在：
1）业务视角（风险消费者）：日常知道有自己/部门（who）、有多少漏洞（what）、为什么要修（why）、应该什么时间修复（when）、在哪里修（where）、怎么修复/验证（how）。
2）安全视角（风险生产者）：围绕风险自动化发现（what）、风险等级与SLA制定（why/when）、风险归属责任人与流转机制（who）、标准修复方案/一键复测能力/加白（how） 做工。

实践下来，上述过程中，影响漏洞修复效果的关键是：风险说明、标准修复方案、修复时间SLA、超期责任方，加白流程，一键复测验证。遗憾的是：超期责任方、一件复测/验证做的好会比较困难。

因此说，漏洞修复、加固推进是一门艺术也不为过，夹杂着：技术、管理，很考验一个人的综合素质。这也是为什么部分同学干了七八年的风险管理后，毅然决然走向攻击方，逃离保姆角色。但这也是风险管理的挑战所在。

实操案例

理想是丰满的，现实是骨感的。不可否认，在一家业务处于上升期，业务跑在安全前面的公司来说，不阻塞业务发展的前提下，如何更好的确保高风险闭环？抛几个我认为常见2个案例吧。

典型场景1：事件级别/高危漏洞业务不修，没有资源，没有排期。
解决方案：
安全完成同步义务：风险说明、风险严重程度、预期修复方案、验证方法、超期责任方、加白方式。常见话术：如发生因超期不修复导致的后续损失，责任方需业务承担。
难点：1）通用的修复时间SLA的制定 2）风险&责任方需要整体CISO与业务方敲定（如果没有标准落实，一线执行同学推修漏洞时，面临SLA超期周知到TL即可）

场景1案例：背景存于某业务加固隔离场景，提前一周周知业务风险明确了最终下线迁移时间，但业务一再延期。最终通过明确DDL，给业务选择题后解决，本质上是风险转移：1）争取资源按期修复 2）邮件申请加白 明确责任方抄送leader审批。

典型场景2：重点业务场景，重要不紧急漏洞无资源投入。
解决方案：
1）体系化梳理领域目标风险，确认交互接口：领域内的整体风险，风险修复优先级、推荐修复方案、业务需要投入的资源。
2）强化风险危害暴露：严重风险危害阐述清楚，通过实际case/演练来增强业务体感，尤其是资源分配方的体感。（根因：没有人会说这个风险很严重，但我还是不修）
3）建立风险闭环流程机制：定期晾晒风险闭环情况。

场景2案例: 背景存在于重点专项，安全识别到风险很高，但给不出需要业务的做工项。业务老板拍板：各个业务领域，安全给出具体的风险和支持项，排好优先级。对着具体的问题来判断要不要做。本质上：还是把复杂的问题具体化，最小原则先明确具体的目标做起来再说。

感受

1、视野范围内的严重的风险，需要紧急业务修复的，证明危害后（需要一定成本），绝大部分业务都会配合乖乖修复。如果你无法证明危害，似乎修复的紧急程度也不会很高。这部分的资源不如让业务去发展coding吧。

2、高效的本质，是多个对象可以围绕一套已对齐的接口 自己迭代做工，如果你觉得低效，那么一定你们的交互标准是模糊的。缺少了 问题定义、目标对齐的过程，这个工作应该更前置close掉。

3、在一家头部公司内，基础组件类的漏洞，存在2-3年都不修复 or 都不在视野范围内，且没有对应的加固感知体系，这都是非常不应该的。抛开漏洞修复方案的复杂程度，根因：缺失一个企业整体高风险项的看板，缺少 加固、检测、验证机制晾晒机制。

4、抛开业务/安全的交互流程上的事情，SDL做的好坏的几个评价的能力：1）自动化能力黑白灰能力与覆盖度：漏洞准确召回率，流水线接入效果/增量/存量回扫的时间 2）基础建设完善度：IDE安全插件/标准修复方案/研发安全意识与培训/漏洞管理平台 3）结果上：高危漏洞修复SLA达成率等等

5、如果你觉得做这件事比较痛苦，那一定不是做这件事情的标准方式，一定代表着有新的机会。（比如push业务修复漏洞），应该把这个过程沉淀下来，形成标准的SOP来运转。