保护项目完整性
目录
引言
| ℹ️ 2025 年 6 月 26 日更新 |
|---|
| wrapper 验证 GitHub action 的链接已修复。 |
我们最近的安全报告显示，针对构建过程通过 Gradle Wrapper 进行的供应链攻击在野外存在。这篇博文解释了如何保护您的项目或您作为开发人员免受类似攻击。
构建过程，顾名思义，就是执行代码。构建过程的所有组件都带有其自身的风险。
- 运行构建工具的引导脚本可能被破坏。（参见如何确保 Gradle wrapper 的完整性？）
- 构建工具本身可能被破坏。（参见如何确保 Gradle 发行版的完整性？）
- 构建工具可能下载本身已受损的第三方依赖项。（参见如何确保第三方依赖项的完整性？）
- 恶意代码可能隐藏在项目代码、测试或构建配置中。（参见如何确保项目完整性？）
由于所有这些可能的攻击向量，当您不完全确定更改的来源时，您应该谨慎行事。在我们的报告中分析的针对 MinecraftOnline 的攻击案例中，Gradle wrapper 的更新是由一位新贡献者完成的。
同样，为开源做贡献也可能使您面临此类攻击。最好以类似的方式验证您正在查看的新项目。
关键点是：只有当您信任项目或更改集时，才应运行构建。
以下建议有助于建立对本地 Gradle 构建的信任。
如何确保 Gradle wrapper 的完整性？#
首先，确保 Gradle Wrapper 在 wrapper JAR 每次更改时的完整性，特别是来自外部贡献者的更改。Gradle 发布了每个 Gradle 版本的 gradle-wrapper.jar 的校验和。
维护者如何确保 wrapper 的完整性 #
- Gradle wrapper JARs 在仓库中更新时应始终进行验证
- 最好自己更新 wrapper，而不是合并来自外部贡献者的 PR。从已知良好的 Gradle 发行版中重新生成
gradlew、gradle-wrapper.properties和gradle-wrapper.jar。使用gradle wrapper调用本地 Gradle 不会运行项目的gradle-wrapper.jar，但它会配置构建。
贡献者如何确保 wrapper 的完整性 #
- 如果您不信任您正在构建的项目，请优先使用已知良好、本地的 Gradle 发行版，而不是 wrapper。
如何确保 Gradle 发行版的完整性？#
其次，确保 Gradle 发行版本身的完整性。除了 wrapper 的校验和，您还可以找到发行版的校验和。
维护者如何确保发行版的完整性 #
- Gradle 发行版校验和可以添加到
gradle-wrapper.properties文件中，以强制下载的内容与预期校验和匹配。
贡献者如何确保发行版的完整性 #
- 再次强调，依赖已知良好、本地的 Gradle 发行版会更安全。
如何确保第三方依赖项的完整性？#
确保第三方依赖项的完整性涉及评估多个因素，例如所使用的依赖项或插件的熟悉度和可靠性，以及它们来源仓库的可信度。综合考虑所有这些因素对于正确验证其完整性至关重要。
维护者如何确保依赖项的完整性 #
- Gradle 允许您启用依赖项验证。此功能可确保第三方依赖项（包括构建插件和项目依赖项）与配置的可信签名或校验和匹配。
- 警惕任何使用异常仓库、插件或依赖项的构建脚本更改。
贡献者如何确保依赖项的完整性 #
- 警惕任何使用异常仓库、插件或依赖项的构建脚本。依赖验证并不能保证可信度，它只确保构建所使用的内容符合预期。
如何确保项目完整性？#
这可能是一项艰巨的任务，审查的严格程度将取决于许多因素。然而，重要的是要明白，任何时候运行他人代码都会面临潜在的安全风险。
维护者和贡献者如何确保项目完整性 #
- 在运行任何任务或将项目导入 IDE 之前，检查构建脚本和任何贡献的代码。即使运行
gradle help也可能执行恶意操作。 - 在本地和持续集成环境中运行不受信任的代码时，考虑使用一次性环境。
结论 #
正如我们在最近的安全报告中所示，供应链攻击是一个令人遗憾的现实。
Gradle 团队将继续寻找改进 Gradle 构建工具及其社区安全的方法。请向我们报告任何可疑的项目、wrapper 或发行版。然而，归根结底，安全是每个项目和开发人员的责任。您应该评估自己的风险和需求，然后采取相应的行动。
如果您在我们的论坛或Gradle 社区 Slack 上有任何问题，或者在下方开始讨论，请告诉我们。