保护项目完整性

Calendar - Gradle 构建系统
Louis Jacomet
安全

目录

引言

我们最近的安全报告显示，针对通过 Gradle Wrapper 进行构建过程的供应链攻击已在实际环境中出现。这篇博文解释了如何保护您的项目或您作为开发者免受类似的攻击。

构建过程，从设计上来说，会执行代码。构建过程的各个组件都有其自身的风险

  1. 用于运行构建工具的引导脚本可能被篡改。（请参阅如何确保 Gradle Wrapper 的完整性？）
  2. 构建工具本身可能被篡改。（请参阅如何确保 Gradle 发行版的完整性？）
  3. 构建工具可能下载已被篡改的第三方依赖项。（请参阅如何确保第三方依赖项的完整性？）
  4. 恶意代码可能隐藏在项目代码、测试或构建配置中。（请参阅如何确保项目完整性？）

由于所有这些可能的攻击途径，当您对变更来源没有完全信心时，您应该保持谨慎。在我们的报告中分析的针对 MinecraftOnline 的攻击案例中，Gradle wrapper 的更新是由一位新的贡献者完成的。

同样，为开源项目做贡献也可能会使您面临此类攻击。最好以类似的方式验证您正在关注的新项目。

关键点在于，只有当您信任项目或变更集时，才应该运行构建。

以下建议可以帮助建立对本地 Gradle 构建的信任。

如何确保 Gradle Wrapper 的完整性？ #

首先，确保每次 Wrapper JAR 文件发生更改时，特别是来自外部贡献者的更改，Gradle Wrapper 的完整性。Gradle 发布了每个 Gradle 版本的 gradle-wrapper.jar 的校验和。

维护者如何确保 Wrapper 的完整性 #

  • 当在仓库中更新 Gradle wrapper JAR 文件时，应始终对其进行验证
    • 对于使用 GitHub Actions 的用户，Gradle 发布了一个专用 Action，它将验证 wrapper 校验和
    • 对于任何其他设置，可以通过扩展我们的验证说明来自动化该验证过程
  • 最好自己更新 wrapper，而不是合并来自外部贡献者的 PR。从已知的良好 Gradle 发行版重新生成 gradlew、gradle-wrapper.properties 和 gradle-wrapper.jar。使用本地 Gradle 调用 gradle wrapper 不会运行项目的 gradle-wrapper.jar，但会配置构建。

贡献者如何确保 Wrapper 的完整性 #

  • 如果您不信任正在构建的项目，则最好使用已知的良好本地 Gradle 发行版，而不是 wrapper。

如何确保 Gradle 发行版的完整性？ #

其次，确保 Gradle 发行版本身的完整性。除了 wrapper 校验和之外，您还可以找到发行版校验和。

维护者如何确保发行版的完整性 #

贡献者如何确保发行版的完整性 #

  • 同样，依赖已知的良好本地 Gradle 发行版可能更安全。

如何确保第三方依赖项的完整性？ #

确保第三方依赖项的完整性涉及评估多个因素，例如所使用的依赖项或插件的熟悉度和可靠性，以及它们来源的仓库的可信度。综合考虑所有这些因素对于正确验证其完整性至关重要。

维护者如何确保依赖项的完整性 #

  • Gradle 允许您启用依赖项验证。此功能确保第三方依赖项（包括构建插件和项目依赖项）与配置的可信签名或校验和匹配。
  • 警惕对构建脚本的任何更改，这些更改使用了不寻常的仓库、插件或依赖项。

贡献者如何确保依赖项的完整性 #

  • 警惕任何使用不寻常的仓库、插件或依赖项的构建脚本。依赖项验证并不能保证可信度，它只能确保构建所使用的内容与预期相符。

如何确保项目完整性？ #

这可能是一项重大的工作，审查的程度将取决于许多因素。但是，重要的是要理解，每次您运行别人的代码时，您都面临潜在的安全风险。

维护者和贡献者如何确保项目完整性 #

  • 在运行任何任务或将项目导入 IDE 之前，请检查构建脚本和任何贡献的代码。即使运行 gradle help 也可能执行恶意操作。
  • 考虑在使用不受信任的代码时使用临时环境，无论是在本地还是在持续集成环境中。

结论 #

正如我们在最近的安全报告中展示的那样，供应链攻击是一个令人遗憾的现实。

Gradle 团队将继续寻找方法来提高 Gradle 构建工具及其社区的安全性。请向我们报告任何可疑的项目、wrapper 或发行版。但是，最终，安全是每个项目和开发人员的责任。您应该评估您的风险和需求。然后采取相应的行动。

如果您有任何问题，请在我们的论坛或 Gradle 社区 Slack 上告知我们，或在下方发起讨论。

讨论

相关文章