产品漏洞一旦进入整改阶段，光靠手工去维护一张表格，很快就会发现表格跟不上实际的变化，而且越来越乱。要想把Cybellum的整改进度清楚地跟踪起来，又把整改进度的看板配置得顺手一些，关键的地方，就是把每一个漏洞当前处在什么状态、波及了哪些版本、该由谁来负责处理、计划在什么时间之前完成，以及最终实际的处理结果，这几样信息串在同一条清楚的链条上。Cybellum本身在产品风险管理这一块，能够借助一个集中式的看板，让团队一眼就看到重要的风险项和各项关键指标，同时这个平台也会持续地盯着每次软件更新、各个产品版本以及不同分支当中的漏洞变化，一旦有新情况就会反映出来。

　　一、Cybellum整改进度怎么跟踪

　　做整改跟踪的时候，不能只是在任务后面简单地写一句“处理中”或者“已完成”，因为同一个漏洞有时会同时牵扯到好几个产品版本，就算负责的同事已经把补丁做好了，也远远不代表这个补丁已经被部署到正在线上跑着的正式版本里面去了，所以状态的划分还要更细致一些。

　　1、先把受影响的范围摸清楚

　　进到产品或者组件的对应页面之后，第一步要做的，就是去查看当前这个漏洞到底关联到了哪些产品、哪些版本还有哪些组件。像那些公共库、供应商交付的组件，还有作为基础环境的镜像，它们经常会被好几个产品同时引用，因此不能只盯着当前这一个版本就把问题关掉，那样很容易在其他产品上留下同样的隐患。Cybellum本身可以帮着定位到底有哪些产品和组件受到了新漏洞的牵连，而且它还能结合VEX或者CSAF这类安全报告，把漏洞的当前处理状态同步分享出去，让其他人也知道进展到了哪一步。

　　2、按处理阶段分开更新状态

　　在整个整改的过程当中，应该把问题首次被注意到并动手更新的时间、补丁真正开发完成的时间，还有最后正式部署到线上环境的时间，分别记录下来，不要把它们揉在一起只写一个含糊的状态。Cybellum在v3.7版本里新增了一个叫Vulnerability Treatment Tracking的功能，它能专门跟踪First Updated、Patched和Deployed这几个关键日期，正好就用它来区分问题到底是刚刚被确认、已经完成了修复，还是切实推到了生产系统里面，几个阶段清清楚楚，不会互相干扰。

　　3、给每个问题明确指定责任人

　　只要是高风险的漏洞，就都必须明确到底由谁来负责处置、计划放进哪一个版本里面去解决，以及最迟得在什么时间之前完成。如果问题的根源出在供应商交付的组件上，那除了内部的责任人，还得同时把供应商那边给出的反馈意见、对应放出来的补丁版本号，还有内部做完整套验证以后得出的结论，也都一并记录下来。最要避免的，就是把横跨好几条产品线的问题一股脑全塞进同一个模糊的大任务里，那样做的话，等到后面想回过头来判断哪一条产品线还没处理完，就完全看不出来了。

　　4、定期把遗留的问题翻出来复查

　　每个星期至少要安排一次，把那些已经过了截止日期却还挂着没动的、长期停在同一个状态没有任何更新的，还有补丁明明已经打好了却一直没被部署上去的问题，统一拉出来复核一遍。整改看板最能派上用场的地方，就是让这些容易卡住的麻烦事情早点浮到水面，被大家看到，而不是等到马上就要发布了，才急急忙忙地去翻找之前随手记下来的零散记录。

　　二、Cybellum整改进度看板怎么配置

　　整改看板的配置，需要贴合项目实际的管理方式来做，因为不同的角色关心的事情并不太一样，产品负责人通常更想看到整体的完成率走到了多少，而安全人员往往会把自己的一双眼睛紧紧盯在高风险漏洞和已经逾期的事项上面。

　　1、先把看板盯住的范围圈出来

　　进到Product Risk Management相关的看板之后，先别急着看数据，而是应该按照业务线、产品名称、具体的版本或者组件，把这次要查看的范围筛选出来，不要一上来就把所有产品的数据全都搅和在一张图里。要是产品数量本身比较多，更合理的办法是给那些正在正式发布的版本、还在研发中的版本，以及已经停产但仍在维护的旧版本，分别建立起各自独立的查看方式，让它们的数据互不掺杂，这样看到的每一条信息才是最准确的。

　　2、用里程碑来对标关键节点

　　如果当前部署的环境里面已经开启了Project Milestones这个功能，那就可以顺着发布门槛、合规要求的截止日期，还有每一批整改的批次，来设置对应的里程碑。Cybellum v3.7已经支持设定截止时间，也可以配合可跟踪的KPI一起使用，在里程碑看板里面能够直接查看不同版本当前的完成状态，等到期限一到，它还能够自动把里程碑给锁住，并且顺带把那些还没有达到目标的项标识出来，免去了人工逐项核对的繁琐。

　　3、给关键指标配上明确的阈值

　　看板上适合重点摆出来的指标，包括高风险漏洞还剩下多少没处理、已经修复的数量有多少、实际部署下去的数量有多少、逾期还没动的数量有多少，最后再加上一个版本的完成率。Cybellum v3.7同时还提供了一个叫作Metrics Configuration的面板，可以在里面上传或者手工去配置KPI的阈值，并且支持对配置进行搜索、编辑和导出，只不过自定义的KPI需要对应的许可证才能打开，这一点要提前确认好。

　　4、把常用的筛选条件固定保存下来

　　像“只看高风险问题”“只看当前准备发布的这一个版本”“只看已经超过了截止日期的那些项”，这些过滤条件在配好之后，就应该让它们固定地留在看板上，而不是每次进来都要重新点一遍。这样一来，不管是开周会还是做发布前的评审，所有参与的人员用的都是同一套筛选标准，不至于每回打开看板，得到的统计数字都不一样，一群人讨论了半天，目标却根本对不上。

　　三、Cybellum整改看板为什么容易失真

　　有些时候，看板上面显示出来的数字表面看去还挺正常，好像整改进度已经推得很靠前了，可这未必就代表实际的整改工作都真的落了地。最容易出现的情况，就是状态的更新总是慢了半拍，又或者补丁做完以后就放在那里，没人去盯着到底有没有真正部署到线上去。

　　1、不要把修复和部署当成同一回事

　　开发人员把补丁代码提交上去，根本就不等于可以直接把问题标成“已完成”，还要另外去确认这个补丁到底被合并进了哪一个版本、有没有通过相应的测试，以及正式跑着业务的产品环境里面，是不是真的已经把这个补丁部署上去了，如果漏掉了后面的任何一环，看板上的完成率哪怕再高，其实也没有什么实在的意义。

　　2、版本的范围要跟着一起同步

　　每回有新的固件被导入进来，就必须再去重新检查一遍漏洞的状态有没有发生变动，因为Cybellum能够持续分析产品版本和软件更新当中漏洞的增减情况，所以每次做完版本升级以后，都要回过头去核对两个问题：老的漏洞是不是的确消失干净了，新的漏洞有没有趁着这次升级悄悄跟着混了进来，这一轮核对绝不能跳过。

　　3、指标的统计口径要交代清楚

　　在看板的旁边，一定得用简短的文字把这次统计的范围、数据到底更新到了哪一天，还有每种状态具体是按照什么规则来定义的，都写得明明白白。要不然，不同的人看到“已完成”这三个字，心里面想的东西可能完全不一样，有的人以为补丁已经提交上去就算完了，有的人理解成测试验证已经顺利跑通了，还有的人认为是正式版本已经推到线上去了，一旦这个口径在团队内部没有对齐，那么整块看板的数据就再也靠不住了。

　　总结

　　对Cybellum的整改进度进行跟踪，在具体操作上，应当从受影响的范围、明确的责任人、补丁的当前状态、部署的进展状态，还有截止日期这几个维度下功夫，把它们紧紧串在一起。整改看板在配置的时候，则可以按照产品和版本把查看的范围拆分开，再结合Project Milestones和KPI的阈值，来管住不同发布节点的风险敞口。只要团队养成了把“发现、修复、验证、部署”四个步骤分开来记录的习惯，整改看板就不会只剩一个看起来挺高、实际上经不起细查的表面完成率。