在漏洞扫描的结果出来以后，真正拖慢整改效率的，往往并不是告警数量本身，而是由谁来负责、要处理哪几个版本、什么时候能把证据交出来。要想把Cybellum里的修复任务合理地分配下去，并且弄清楚任务状态到底是怎么流转的，就需要把漏洞、对应的产品组件、受影响的版本、具体的责任人，还有整改的结论，全部都放在同一条记录里面。从Cybellum官方的资料来看，这个平台能够围绕整个调查过程，把相关的信息给整理起来，形成分析结论，创建起对应的工单，并且为不同的相关方生成报告。

　　一、Cybellum修复任务怎么分派

　　在正式分配任务之前，得先判断一下这个漏洞是不是真的会对当前产品造成影响。Cybellum里面有一个VM Co-Pilot功能，它会结合平台的兼容性、产品的功能需求，还有设备实际的配置情况，把那些需要继续往下处理的问题给筛出来，避免团队把时间花在跟当前产品没什么关系的漏洞上。

　　1、先确认漏洞到底影响了哪些范围

　　进到漏洞的详情页面里面，去核对一下CVE编号、被命中的组件、组件的版本、所在的固件、关联的产品，还有受影响的版本。一个漏洞很可能同时出现在好几个历史版本当中，可不能光把任务挂到当前正在开发的那个分支上就完事了。

　　2、把负责人和执行人分开设置

　　负责人通常是由产品安全这一块的接口人来担任的，他们主要负责对风险做出判断、跟踪整改进度，还有在最后关闭任务时做审核；而执行人可以是内部的开发团队，也可以是外部的供应商。Cybellum的PSIRT资料里也建议，在各条产品线上都设置好安全的接口人，由他们来负责自己领域内的风险量化、分析，还有修复工作。

　　3、把交付的要求写清楚

　　在任务当中，至少要把漏洞的描述、受影响的版本、打算怎么去处理、计划完成的时间、用什么样的方式去验证，还有最后交付的证据，这些内容都给保留下来。如果是要做修复类的任务，就需要附上补丁的版本或者新的软件包；要是只做配置上的缓解，那就得写明到底关掉了哪些服务，或者修改了哪一项配置。

　　4、给不同的阶段设置好时间点

　　可以把发布之前的整改、产品量产之后的补丁，还有供应商那边往回传修复结果，分别设置成不同的时间节点。Cybellum的Project Milestones支持去设置任务的截止日期，也可以设置那些能够被跟踪的指标，还能去查看不同版本下的完成状态。

　　二、Cybellum修复任务状态怎么流转

　　不同版本或者不同部署环境里，任务入口的名字可能会稍微有些差别，但漏洞处置的状态是应该保持统一的。Cybellum对外公开的资料里，列出了四种比较常见的状态，分别是Open、Fixed、Mitigated，还有Accepted Risk。

　　1、Open

　　那些新被发现出来的问题，首先要进入Open这个状态，表示团队已经注意到了这个风险，但还没有确定下来到底要怎么去处理。在这个阶段，要赶紧把影响分析、具体的责任人，还有计划完成的时间都给补全。

　　2、Fixed

　　等到代码被修改好了、软件包或者补丁也打上了，而且通过了验证之后，就可以把这个任务转成Fixed。不要只是听开发人员口头说一句已经改完了，至少还要把新的版本信息、构建的记录，还有重新扫描之后的结果给留下来。

　　3、Mitigated

　　有些漏洞虽然没有直接从代码里面消失，但团队已经通过编译时的防护、关掉了相关服务、调整了防火墙策略，或者修改了一些配置项，把风险给降下来了，这个时候就可以把它转成Mitigated。官方资料里也把这类配置上的改动算作一种缓解的方式。

　　4、Accepted Risk

　　如果某个漏洞确实还存在着，但是经过评估之后，团队决定接受这个剩余的风险，那么就可以转成Accepted Risk。在记录里面一定得把理由、适用的版本、是谁审批的，还有计划在什么时间复核，都给写清楚，不能光留下一句“风险比较低”就完了。

　　三、Cybellum修复任务流转后怎么复核

　　在把任务的状态改完了以后，还要再去检查一下留下来的这些记录，是不是真的能撑得住以后的审计。Cybellum的资料里也强调过，在做漏洞追踪的时候，需要把责任人、当前的状态，以及用来支撑整个缓解计划的技术和业务上的理由，都一并记录好。

　　1、检查一下版本是不是全都被覆盖到了

　　同一个组件很有可能会出现在好几个不同的产品，还有好几个不同的固件里面。在正式把任务关掉以前，要去确认一下，所有受影响的版本是不是都已经处理过了，或者是不是已经分别为它们建立了后续的跟进任务。

　　2、检查一下状态和手里的证据能不能对得上

　　补丁发布之后就用Fixed，单纯靠配置绕过的那就用Mitigated，经过了正式的审批流程，决定保留风险的就用Accepted Risk。要是状态一不小心给选错了，后面再翻看报告的时候，就看不出来当时真实的处理情况了。

　　3、检查一下供应商回传过来的那些内容

　　当供应商把修复的补丁包交过来的时候，要同时去核对一下组件的版本、变更的说明、验证的结果，还有重新扫描之后的结果。要是拿到的只有孤零零的几个文件，却看不到完整的证据链条，那到了后面再想复核，还是会非常困难。

　　4、跟踪那些已经超期的任务

　　管理人员可以把截止日期、还没有被关掉的工单数量，还有平均的关闭时间，这几个指标放在一起，来看一看整改的整体进度。Cybellum的管理中心里面，也支持去查看那些有待复核的组件，还有工单的关闭时间。

　　总结

　　Cybellum里的修复任务要怎么去分派，以及这些任务的状态又是怎么流转的，这里面的核心，就在于先把真实的影响给确认清楚，然后再把责任人、版本的范围、完成的时间，还有证据的要求，一五一十地写明白。任务的状态应该清楚地区分出Open、Fixed、Mitigated和Accepted Risk这几种，在正式关闭之前，还要再去核对一下版本的覆盖、验证的结果，还有审批的记录。只有这样，漏洞的整改才不会只是停在“已经有人在处理了”这一步，而是能够形成一个可以被追踪、也能够被复核的闭环。