在过去十年的云迁移中，针对 Java 应用程序的威胁模型以及我们需要保护它们的方式发生了变化。OpenJDK 通过弃用旧的 SecurityManager已经在该领域做出了一个积极的改变，它是保护过去 AOL CD 和纸质地图时代的遗物。安全方面的下一个积极变化是加强软件组件的供应链，了解正在运行的内容和易受攻击的内容，并与数据存在风险的非技术专家交流这些信息。
这种威胁模型的一部分是由去年的Log4j等易受攻击的库驱动的。尽管 Log4j 是一个很棒的日志库并且在修补方面很活跃，但许多团队争先恐后地确定他们需要在哪里应用这些补丁。对于知道他们的代码并且可以部署的个人 Java 开发人员或团队来说，补丁很简单——你更新了一个库，就是这样。但现实情况是，软件发展得又快又远，通常会将这些技术专家的控制点留给没有专业知识来管理这个级别的问题的利益相关者。在争吵中，不了解 Java 细节的团队到处寻找，包括.NET 软件和Python 论坛。魁北克政府关闭服务直到他们知道 Log4j 不在哪里。这种加扰无效，也不能保护我们的数据。
Java 应用程序威胁模型的主要部分现在涉及跟踪组件并了解我们的应用程序在何处包含已知易受攻击的组件（例如 Log4j）的能力。
什么是通用 Java 应用程序的供应链？查看供应链的一个简单方法是，大多数参与者是生产者和/或消费者。企业架构师可能已经熟悉这个类比，因为供应链像队列一样移动，因此可以使用类似的术语。此供应链的示例包括：
- 像Maven Central这样的存储库是 JAR 文件的生产者。它们将这些组件提供给作为这些 JAR 文件消费者的开发人员或构建系统。
- 开发人员使用 JAR 文件并生成将应用程序组合在一起的新代码。一些开发人员生成的库会被发送回作为消费者的 Maven Central。
- 构建环境使用开发人员的自定义代码和 repo 库来生成应用程序、容器或其他包。
- 当应用程序部署到环境或发送给客户时，这通常会结束供应链。
- 对于购买的 COTS 软件，供应商是生产者，运营商通常是消费者。在内部，供应商有自己的软件制作供应链。
最终目标是将应用程序转移到生产环境并运行它们——这个生产环境只是一个消费者，因为它不会产生新的工件（在 DevOps 周期中，生产的输出是反馈）。
评估“软件供应链”背后的主要驱动力是快速检索三个问题的答案：
- 我有什么软件，包括构成更大系统的组件？
- 当一个软件或库被识别为易受攻击时，它会影响我吗？如果是，影响在哪里？
今天有许多方法用于清点应用程序。定制软件通常在 CI/CD 管道期间使用工具来创建 SBOM ；Maven 通过它的dependency:tree插件来提供这个。另一种方法涉及容器扫描以分析软件运行的包装环境。另一种方法涉及将代理集成到软件中。但是，每种方法都需要一个团队在供应链的一个步骤中采取行动，并且不会捕捉到通常在这些步骤之外部署的生产偏差或下载的项目。JVM 拥有的独特优势之一是它必须无处不在才能运行软件，并且 JVM 已经拥有必要的信息，因为它负责加载代码。
Azul 提供了两个 JVM，作为其他 Java 实现的替代品。除了更快地运行应用程序和降低运营成本之外，10 月份的 PSU 版本还实施了第一个版本的漏洞检测，以帮助管理供应链威胁。
在供应链威胁模型中，JVM 还提供了验证信任的另一个优势。随着供应商和承包商生产他们自己的 SBOM识别组件，有时该信息可能不正确。承包商可能会将易受攻击的库隐藏到他们的组件中，假设他们通过避免命名空间冲突来提供帮助。通过使用 JVM 生成和/或验证 SBOM，组件检测可以是字节码感知的。JVM 可以理解“代码形状”或签名并根据它们所做的而不是它们声称的内容来匹配组件，而不是简单地查看文件来确定每个文件声称的内容。Azul 在 Java 社区工作了十多年，分析了性能，创建了这个性能代码识别云数据库，并且能够将相同的方法应用于安全问题。
通过加速 Java 来增强您的安全控制当 JVM 执行跟踪组件的工作时，一个关键优势是能够检测在 JVM 上运行的所有工作负载，而不仅仅是安全控制所涉及的工作负载。目前正在使用其他方法来盘点组件的团队应该继续这样做——目标是纵深防御，每个控件协同工作以捕捉另一个可能错过的东西。通过以生产速度工作，Azul 漏洞检测等新技术正在“向右移动”，以提供对可能遗漏的项目的生产速度验证，或节省集成和扫描所有 Java 软件的工作。
,
