在做产品安全管理的时候，大家经常遇到的麻烦其实不是“有没有风险”，而是因为风险数量实在是太多了，导致手头不知道该先去处理哪一条，所以Cybellum风险优先级怎么排序，以及Cybellum风险优先级和修复计划怎么对应，这两个常见问题必须要合在一起来考虑。需要结合产品的版本、外面能不能接触到、被利用的可能有多大，还有合规的节点和手头的研发资源，把这些因素加在一起才能做个判断。

　　一、Cybellum风险优先级怎么排序

　　我们在给风险排先后顺序的时候，绝对不能只看着CVSS分数从高到低往下排，因为CVSS分数只是用来说明漏洞在技术上的严重程度的，但是等这些漏洞真正要写进产品修复计划里的时候，我们还得去看看漏洞是不是真的在这个产品里面、目前有没有被别人利用过的痕迹、在外部能不能被触发，以及坏掉的是不是关键功能；哪怕是CVSS v4.0版本把基础、威胁、环境还有补充这些指标分开了，它的目的也是想让通用的严重性和具体环境带来的影响能稍微分得清楚一点。

　　1、按照产品受影响的范围来分层

　　用户在登录Cybellum系统之后，可以先去产品视图、资产视图或者版本视图里面看风险列表，把那些会影响到核心产品、已经量产的版本、带有联网功能还有安全关键功能的风险往前挪；如果是那些只影响到内部测试版本、实验分支或者没有发布的组件的风险，它的优先级就可以往后放一放，但是也不能直接不管它。

　　2、按照被利用的可能性去调整顺序

　　把产品范围看清楚了之后，我们接着要去查这个漏洞在外面有没有公开的利用方法、有没有概念验证的代码、有没有现成的攻击工具，或者有没有正在发生的攻击迹象；比如CISA发的KEV目录就是大家判断优先级的一个参考，它能帮我们认出哪些漏洞是被别人实际利用过的，而EPSS则是用数学模型来大概算一下某个CVE漏洞在接下来的30天里面被人利用的概率有多大。

　　3、结合业务和合规的节点来补充排序

　　做产品安全的团队还得顺便看看业务上的时间节点，比方说某个产品马上就要拿去检测了、或者是客户要来审计、或者是软件要发布、或者是合规法规要提交了，那么和这些事情相关的风险就得提前去弄；Cybellum平台比较重视把产品安全的工作流程、合规需要的证据还有漏洞的分诊都放在一个地方，这种设计正好能帮我们把风险的排序和交付的时间点联系在一起，省得让安全问题一直死板地待在单独的列表里面。

　　二、Cybellum风险优先级和修复计划怎么对应

　　等风险的顺序都排好之后，下一步要做的事情可不是直接把列表丢给开发人员，而是要把不同的优先级去和不同的修复办法对应起来；如果是紧急的风险，那就得定死截止的时间，还要有临时应付的招数，高风险要塞进最近的版本里，中低风险则可以放到后面的迭代计划里或者先盯着，要不然优先级就只是网页上的一个好看的文本，根本没办法把事情真正做完。

　　1、紧急风险要对应马上处理

　　那些被算作紧急的风险，通常包括已经被别人利用的、暴露在外面的、会影响到核心功能的，或者是影响到了量产版本以及客户正在用的版本的漏洞；大家在发现了这类风险之后，就得赶紧在Cybellum系统里把它的状态、归谁管、影响哪个产品、还有打算什么时候修完都写上去，而且还要赶紧告诉研发、测试、产品还有供应商的负责人。

　　2、高风险要对应在最近的版本里修复

　　高风险的事情倒不一定非得在当天就全部弄完，但是也绝对不能一直放在那里不管，比较合适的做法是把它们塞进最近要出的维护版本、补丁包或者是供应商的交付计划里面，同时还要在Cybellum里面把修复的任务、测试验证的要求还有做完的标准都绑定在一起。

　　3、中低风险要对应排期或者直接接受

　　至于那些中低风险，我们可以把它们放到日常的迭代里去，但是状态也得填好，千万别让它们一直挂在“待处理”这一栏里；如果我们去确认了之后，发现这个风险其实根本触发不了、代码走不过去、或者旁边已经有别的保护措施了，又或者它只影响没有发布的版本，那我们就可以在平台里把它记录成接受、延期或者是没有受到影响，而且后面必须把判断的理由也附上去。

　　三、修复计划执行中要怎么保持闭环

　　把风险优先级和修复计划对上号了之后，后面还得不停地盯着执行的情况才行；很多团队在刚开始的时候分级分得特别仔细，但是到了后面不去验证、也不去重新扫描，手里连个证据都没有，结果等到被人审计的时候，还是说不清楚某一个风险到底有没有被真正解决掉。

　　1、把风险的状态和到底该谁负责写清楚

　　每一个风险在列表里都应该至少让人看到它现在的状态、哪个部门管、具体是谁在弄、计划什么时候弄完、影响到了哪个产品，以及打算怎么处理它；这里的状态我们可以按照待确认、修复中、已缓解、已修复、已接受、误报或者是未受影响来分类管理，状态如果写得越清楚，那和其他团队沟通的时候扯皮的事情就会越少。

　　2、修完之后必须得重新扫描和验证

　　等开发人员说东西修完了，我们可不能只听他们嘴上说完了就直接把风险关掉，而是需要重新扫描一次，或者重新把SBOM导入进去，好去确认组件的版本、漏洞的匹配情况还有资产清单是不是真的变过来了；Cybellum本身就支持围着产品安全的流程来管资产、SBOM、漏洞还有证据，我们在修完之后去把这些内容重新核对一遍，这整件事才算是真正做完了。

　　3、要定期回过头来看看优先级有没有变化

　　风险的优先级绝对不是看了一次之后就永远都不变了；如果外面出来了新的利用代码、或者被KEV收录了、或者EPSS分数升高了，又或者是产品上线了、接口被打开了、甚至客户在现场反馈了问题，这些情况都有可能让一个本来挺轻微的风险突然间变成高风险；相反，要是后面能证明代码根本走不到，或者功能其实没启用，那我们也可以把优先级往调低了改。

　　总结

　　Cybellum风险优先级怎么排序，这件事不能只死盯着分数看，而是要把产品影响的范围、被利用的可能、在外面暴露的情况、业务的节点还有合规的要求这些东西加在一块去综合考虑；至于Cybellum风险优先级和修复计划怎么对应，也绝对不是把高危的漏洞一股脑全丢给开发人员，而是要把紧急、高、中低这些风险分别和马上修、近期的版本、后面排期处理或者是直接接受去做好对应；真正管用的办法，其实就是在Cybellum里面把风险、组件、版本、负责人、修复状态还有验证的证据全部串在一起，让每一个风险都有一个清清楚楚的排序理由，也能有一条真正能走得通的处理路子。