Java的新威胁模型
作者：互联网
在过去十年的云迁移中，针对 Java 应用程序的威胁模型以及我们需要保护它们的方式已经发生了变化。OpenJDK已经在这一领域做出了一个积极的变化，弃用了旧的SecurityManager，这是一个保护过去AOL CD和纸质地图时代的遗物。安全性的下一个积极变化是加强软件组件的供应链，了解正在运行的和易受攻击的，并与数据面临风险的非技术专家沟通这些信息。
这种威胁模型的一部分是由易受攻击的库驱动的，比如去年的Log4j。尽管 Log4j 是一个很棒的日志库，并且在修补方面很活跃，但许多团队争先恐后地确定他们需要在哪里应用这些补丁。对于了解其代码并可以部署的单个 Java 开发人员或团队来说，补丁很简单 — 您更新了一个库，仅此而已。但现实情况是，软件发展得又快又远，通常将这些技术专家的控制点留给没有专业知识来管理此级别问题的利益相关者。在一场混乱中，不了解Java细节的团队到处寻找，包括.NET软件和Python论坛。魁北克政府关闭了服务，直到他们知道Log4j在哪里。这种加扰无效，也不能保护我们的数据。
Java 应用程序威胁模型的一个主要部分现在涉及跟踪组件的能力，并了解我们的应用程序在何处包含已知易受攻击的组件，例如 Log4j。
什么是常见 Java 应用程序的供应链？
查看供应链的一个简单方法是，大多数参与者是生产者和/或消费者。企业架构师可能已经熟悉这个类比，因为供应链像队列一样移动，因此可以使用类似的术语。此供应链的示例包括：
- 像Maven Central这样的存储库是JAR文件的生产者。他们向开发人员或构建系统提供这些组件，他们是这些JAR文件的使用者。
- 开发人员使用 JAR 文件并生成将应用程序组合在一起的新代码。一些开发人员生成库，这些库被发送回作为消费者的Maven Central。
- 生成环境使用开发人员的自定义代码和存储库库来生成应用程序、容器或其他捆绑包。
- 当应用程序部署到环境或发送给客户时，这通常会结束供应链。
- 对于购买的 COTS 软件，供应商是生产者，运营商通常是消费者。在内部，供应商有自己的供应链来说明他们如何制作软件。
最终目标是将应用程序移动到生产环境并运行它们 — 此生产环境只是一个使用者，因为它不会产生新的工件（在 DevOps 周期中，生产的输出是反馈）。
评估“软件供应链”背后的主要驱动力是快速检索三个问题的答案：
- 我拥有哪些软件，包括构成较大系统的组件？
- 当一个软件或库被识别为易受攻击时，它是否会影响我，如果是，在哪里？
JVM如何管理我的Java应用程序的供应链？
目前有许多方法用于清点应用程序。自定义软件通常在 CI/CD 管道期间使用工具创建 SBOM;Maven通过其依赖：tree插件提供此功能。另一种方法涉及容器扫描，以分析运行软件的包装环境。另一种方法涉及将代理集成到软件中。但是，每种方法都需要一个团队在供应链的某个步骤中采取行动，并且不会捕获通常在这些步骤之外部署的生产漂移或下载的项目。JVM拥有的独特优势之一是，它必须存在于任何地方才能运行软件，并且JVM已经拥有必要的信息，因为它负责加载代码。