话题：开源组件漏洞的可达性或实际可利用性分析识别，大家有什么落地实践或经验吗？即使是商业版sca很多也只是照搬公开漏洞库做简单的版本匹配。
A1：今年rsa沙盒有一家的产品说是可以跟踪调用链路，准确判断。
A2：在原有的sca识别逻辑加上IAST/SAST的调用链或数据流分析进行综合判断，这个在技术上应该也可行。但是这么多组件漏洞要逐个收集分析编写规则，需要耗费的人力太多了。
A3：加poc验证吗？开源组件针对有poc的那部分，如果版本号匹配上了，就大概率是可攻击的，只是需要去找漏洞的入口。sca要做poc验证有点不太现实，还和调用组件的入口函数有关系了，这部分需要通过代码审计才能做。
现在的sca应该都已经前置到了开发人员那儿了，iast和sast在ci/cd阶段去了，这两个要和sca联动的话，个人感觉sca的时效性就太差了。
A4：好像iast 可以做，iast本身有识别组件模块。通过插桩，主动模式和被动模式结合，之前跟厂商提过这样需求，可以识别fastjson和log4j这类的漏洞。
A5：我们这这边就是左移给开发去用，但是有追求的开发会自己去分析漏洞是否对他的项目存在实际影响，然后就被吐槽了。
客观来讲，组件漏洞确实太多，里边也有很多不能利用的，我们推起来费劲，开发测试修起来也累，所以想看下能不能进一步做到可达性的层面，实际有影响的才推。
A6：这种建议分成存量和新增，新增的话，就好解决，ide插件就可以完成修复，存量的问题就要考虑实际是否可利用可缓解可修复来进行处理（这个过程需要消耗不少的人力成本）。
A9：可以考虑把组件版本漏洞映射到https://www.exploit-db.com；不考虑攻击面暴露的话，可以结合源码扫描代码片段和配置文件里面配置吧。另外感兴趣可以看看Endor Labs这个。
Q：请教个问题，你们如何去判定组件漏洞是否可利用，有没有自动化判断的方案，现在如果根据是否包含某个组件就告警，存在不少误报。
A10：Poc是否真实可利用，或者具体的漏洞接口有没有调用。我们自己分析用POC没问题，但是具体到系统层面不大可能拿着POC每都去试一遍，局限比较大。主要是放在生产环境不太好去推动，不是不能实现，而是打POC容易影响业务稳定性和连续性。
A11：感觉也得考虑代码库对应部署单元的资产属性，比如先分清微服务的部署单元是否对外提供接口，这个当成一个远程利用的条件，从外往内推，要不依赖检查比版本全是高危，研发要崩溃了。
A12：理论上是可行的，但是适合在测试环境和预发布阶段。测试环境需要单一，不能混用；然后可以通过SCA类的工具，最好是偏向agent类的去检测，然后针对SCA检测出的漏洞去扫描验证。有点像主动性的IAST。具体流程如下：SCA ----扫描----> 测试应用系统------输出漏洞list---->漏洞验证扫描器-------针对漏洞list自动化验证触发---->返回验证结果。
A13：是的，针对线上环境的poc测试难度大，大部分组建的真实调用情况通常需要业务配合确认，人工沟通成本高。
A14：组件漏洞的是否可利用对安全人员的能力和poc的能力要求太高了，很多组件的漏洞都需要去分析调试代码才能够验证，这些东西基本上都是理论上可行，实际上就不太现实了。
上面流程中“漏洞验证扫描器”环节基本上不太可能实现自动化，组件的漏洞利用太麻烦了，基本上都需要人工来参与，反复调试才能出结果。当然如果像当初log4j出来的时候，只要有输入就拿poc去砸就另说了，盲打log4j，fastjson好像也可以盲打。
Q：这些都是最知名的，大家怎么推那些不太知名的，或者咋定标准？SCA一扫没有能幸免的项目。
A15：管它知不知明，拿着poc结合iast直接盲打。只要有poc和rce、反序列化之类的，就盲打。配合ci/cd检测和验证还是可以检测和监控起来的。这个是参考一些扫描器和bp漏洞识别插件的行为。
A16：资产统计，版本统计，在开发调用的时候就做好。
---------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
原文始发于微信公众号（君哥的体历）：开源组件漏洞可利用性分析的落地实践与经验之谈 | 总第208周
评论