原本预计是没有二了，但是逼得一年没有写字的人出来蹦跶一下，一篇短文是写不完的。另外，和业界同行有了一些思想上的碰撞，又催生了一些自我思考反省，虽然有些问题没人愿意说，或者是真懂了、妥协了，甚至是视而不见，种种让我最终决定还是用自问自答的形式写下这篇二吧，这才真正暗应深井冰三个字的意思。

这个漏洞在JAVA生态8年了，为什么没有人更早一些提前发现？

这个其实是个很大的问题，不同经历的人会有不同答案。

经历过太多的人，每天我处理的漏洞是海量的，0day、nday、在野的不计其数，log4j这种漏洞会被淹没的。

专门做JAVA Web安全研究的人，2020年提交的Codeql代码扫描规则可以自动发现Log4Shell漏洞。这个回答会让我哭笑不得，是时候该反省8年JAVA安全是不是白学了。不过从我的安全经验看这个漏洞也没那么特别容易，涉及到可变变量、攻击入口的判断，还有影响面的评估，这个就看经验和悟性了。有时候原理简单，能看破，会利用的少，知行很难合一。不过综合评估这个漏洞的门槛实在不高，这也是让我纠结的点，业界确实发现和重视得太晚了，做相关研究的同学是该复盘一下了。

最重要的一点是开源社区的认知，开源社区认为这不是漏洞，是个强大功能带上的副作用，并且提供可控制的开关，所以安全社区不去逼一逼，是允许这种问题存在8年的，这也是我从业这么多年感到最可怕的事，但是在很多同行身上找不到共识，也许很多人是真懂了妥协了吧，而我只感到害怕。

为什么有人说这个漏洞不是打完补丁就完了，接下来是未来两年的战斗？

这个问题我觉得做JAVA开发的同学会很懂，不是把log4j2包删除升级就完事了，java的开发模式决定组件互相引用是指数级的，特别是log4j2包可以有嵌套打包、Fatjar包等形式，log4j2漏洞可能藏在JAVA生态的数万个包里面，这会让做防的人崩溃的，你并不知道你哪天引用开发的项目在不知不觉里踩地雷了，这又是内部安全开发流程、Devsecops要重新关注的点，而这仅仅是log4j2暴露出来的一个问题，还有无数个类似log4j2还没有披露的漏洞怎么办？

大公司部署的SCA安全软件对这个漏洞有没有帮助？

说实话，这是个我不愿意提及的问题，后知后觉，业界的很多安全产品、安全软件也受log4j2漏洞影响，局中人是该反省一下了，SCA软件自己就有SCA问题，安全产品自己就有RCE漏洞，这不讽刺么，这是唯一一个让我低下头的问题。

这个漏洞和永恒之蓝比起来谁更厉害？

永恒之蓝和Log4j2漏洞不一样，一个是操作系统漏洞，一个是一门语言生态的基础库出安全漏洞了，基础库的互相引用影响是指数级的，这是对业界生态的打击，不能放在一起比较。

对这个漏洞有什么好的解决方案和措施？

这个问题我要感谢NUKE兄弟，一直在不遗余力的推荐CISA的sbom（软件物料清单），SBOM 是描述软件包依赖树的一系列元数据，包括多种关键信息如提供商、版本号和组件名称的标准。我觉得每个组织机构经过log4j2的洗礼后，应该要重视起来了，SBOM的构建对于分析开源软件漏洞是发挥着关键作用的。

最后

用自问自答的方式还是舒服，至此LOG4J漏洞深井冰应该完了吧，看看下一年还有什么事会让我出来再写一篇。和我一样深井冰的朋友可以留言交流，深井冰久了对自己不太好 ：）