去年 12 月，Veracode 报告称，超过 1/3 的 Java 应用程序仍在使用易受攻击的 Log4j Java 日志记录库版本。在此之前，许多工程团队放弃了常规工作，将时间花在修复远程可利用的 Log4Shell 漏洞上，此漏洞感染了许多 Log4j 实例。
在经过两年多的寻找和对这一广泛使用的库的更新，您不禁要问，为什么还会出现这种情况？我们深入研究了 2023 年 Java 现状调查和报告中的数据，试图从这项针对 2000 多名负责 Java 的工作人员的研究中找到一些答案。
我们仔细研究了一些公司如何取得第三方来源的 CVE，以及他们的方法对组织的 Log4Shell 漏洞有何影响。我们研究的两个问题是：
- 贵公司最关心哪一种公共漏洞和暴露 (CVE) 来源？
- 谁主要负责为内部应用程序创建软件物料清单 (SBOM)？
我们按顺序看一下
最受关注的 CVE 来源
参与者可以选择多个答案，可选的答案有:
- 开源库和应用程序
- 第三方库和应用程序（容器、开发中心等）
- 由我们的应用程序开发人员编写的代码
- 基础设施软件（Kafka、Cassandra 等）
- JVM
- CI/CD 工具
- 我不知道
- 我们不关注 CVE
我们关注的是，关注开源和第三方库及应用程序是否可作为应当警惕的指标。以下是我们的发现。
| 细分 | 我不知道 Log4j 存在漏洞 |
|---|---|
| 已指明开源或第三方 | 2.3% |
| 未指明开源或第三方 | 8.4% |
调查对象是负责 Java 的人员，因此 B 组的人数超过 8% 是相当惊人的。
| 细分 | 该漏洞没有被利用，但工程团队花了几个小时补救风险（搜寻 Log4Shell、替换等） |
|---|---|
| 已指明开源或第三方 | 50.6% |
| 未指明开源或第三方 | 36.4% |
A 组中有一半的受访者在 Log4Shell 上花费了几个小时，而 B 组中只有近三分之一。B 组可能节省了时间来执行更具战略性的工作，但较低的数字表明他们没有发现受感染的 Log4j 库并将其更新为干净的版本。这会产生什么影响？
| 细分 | 黑客试图利用该漏洞攻击我们公司，但未成功 | 黑客成功利用该漏洞攻击我们公司 |
|---|---|---|
| 已指明开源或第三方 | 15.4% | 12.9% |
| 未指明开源或第三方 | 20.1% | 13.8% |
总体而言，A 组中有 28.3% 的公司经历过通过 Log4j 实施的黑客攻击，而 B 组中 33.9% 的公司经历过。增加了 20%！
所有数据
| 细分 | Log4j 对我们公司没有影响 | 该漏洞并未被利用，但工程团队花了数小时修复 | 黑客试图利用该漏洞攻击我们公司，但未成功 | 黑客成功利用该漏洞攻击我们公司 |
|---|---|---|---|---|
| 已指明开源或第三方 | 16.2% | 50.6% | 15.4% | 12.9 |
| 未指明开源或第三方 | 16.4% | 36.4% | 20.1% | 13.8 |
识别 SBOM 管理者
调查参与者可以选择多个答案，可选的答案有:
- 应用程序开发人员
- DevOps
- 平台工程
- 安全性
- 业务线（产品团队、营销、合规等）
- 运营
- 无人负责 SBOM
应用程序开发人员是最常见的答案，从参与者回答 Log4Shell 对其组织的影响来看，这是一个令人鼓舞的迹象。
| 角色 | Log4j 对我们公司没有影响 | 该漏洞并未被利用，但工程人员花了数小时修复风险 | 黑客试图利用该漏洞攻击我们公司，但未成功 | 黑客成功利用该漏洞攻击我们公司 |
|---|---|---|---|---|
| 应用程序开发 | 12.4% | 49.4% | 18.1% | 15.7% |
| 平台工程 | 12.4% | 49.8% | 20.3% | 16.0% |
| 安全性 | 8.1% | 44.4% | 25.1% | 20.5% |
| 运营 | 8.1% | 46.3% | 24.4% | 19.4% |
| DevOps | 11.2% | 48.6% | 19.4% | 16.6% |
| 业务线 | 8.8% | 48.3% | 21.2% | 19.2% |
具有讽刺意味的是，负责 SBOM 的安全团队的攻击率最高，成功率也最高。近一半 (45.6%) 将 SBOM 委托给安全部门的团队受到攻击，其中五分之一被黑客成功入侵。我们不会冒这个险！
与此同时，负责 SBOM 的应用程序开发团队中有 33.8% 受到攻击，其中 15.7% 被成功入侵。
这对 DevOps 团队意味着什么
安全性只是代码库清理和更新这一更大需求的一部分。由于遗留代码尚未停用，许多 DevOps 团队难以进行创新，这使得维护变得更加困难，并增加了漏洞暴露的风险。企业面临着加快应用程序创新周期和优化开发资源的压力，同时还要确保应用程序和客户数据的安全性。
跨平台和 Java 版本的部署使代码维护变得日益复杂。代码维护成了没人愿意做也很少有人做的工作，问题也得不到解决。情况是否有所好转？我们将于今年秋天发布 2024 年 Java 现状调查和报告，届时答案将会揭晓。
使用 Azul Vulnerability Detection 解决问题
Azul Intelligence Cloud 由两项服务组成，可解决在生产环境中运行的 Java 应用程序面临的这些挑战：
- Azul Code Inventory 通过精确描述哪些自定义代码和第三方代码正在运行（而不仅仅是存在），帮助识别未使用和失效的代码。借助 Code Inventory，DevOps 团队可以减少维护和测试未使用代码的时间和负担，显著缩短开发人员的工作时间，并最终节约成本。
- Azul Vulnerability Detection 通过准确识别和优先处理已知的安全漏洞来消除误报。通过在生产使用点检测漏洞，Vulnerability Detection 填补了软件供应链端点的关键空白，并增强了传统工具的功能，包括第三方来源的 CVE，从而获得更准确的结果。
