php - 在生产环境中使用 Composer Install 的安全问题

Question

我正在尝试为企业级应用程序设计部署流程。关于 Composer 是否可以在生产环境中使用，我听到了相互矛盾的意见。

我知道运行 composer update 是错误的，因为您可以引入未经测试的版本。相反，在生产中，建议仅使用 composer install。

话虽如此，我最担心的是安全问题。中间人攻击有多容易。如果 packagist 被黑了，我们是否可以拉下被黑的代码？

我不希望有一个手动流程，每次部署时我都必须手动将供应商文件提交过来。目前 Jenkins 会将源文件移至生产环境。如果可能的话，我不想对供应商文件夹进行版本控制。

1. 如果我使用 composer install，我真的应该担心安全问题吗。
2. 如果我不在生产中使用 Composer，您建议我如何部署供应商文件？

Answer 1

是的，您应该关注并尝试了解涉及哪些数据传输。

Composer 的当前实现确实在内部使用了大量校验和，但不涉及包签名，因此在 composer install 期间下载的任何内容都可能是任何软件，具体取决于托管哪个服务器软件存储库或 TGZ/ZIP，或者询问有关元数据的信息，都是可以被篡改以影响您安装的内容的有效目标。

但是请注意，这不仅与安全有关。如果您依赖于在生产部署期间可安装的软件包，则上述任何服务器很可能处于脱机状态。您将如何保护您的部署免受第三方软件托管的任何服务器中断的影响？这个问题的答案非常简单:在本地托管软件。

而且这个答案也会影响安​​全问题:如果你在本地托管软件包，你也可以在让它们在内部可用之前审核这些版本。根据您需要的安全级别，您可以检查您获得的每个版本，并将可用版本限制为您能够检查的少数几个版本，或者您可以创建一种更慷慨的方式来断言您获得的软件从原始 Git 存储库中获取，并在本地创建软件的 ZIP 版本(如果您不打算进一步开发 IMO 软件包，ZIP 会更方便)。

只有两种已知的软件产品可能对这方面有帮助:Toran Proxy 是 Jordi Boggiano(Composer 核心开发人员之一)的商业产品，它应该也有助于资助 Composer 和基础设施的开发。另一个软件是 Satis，它还允许创建您使用的包的本地副本。

免责声明:我的回答可能没有深入细节，并且可能会提供一些过于简短或可能错误的细节。它并不意味着解决每个安全细节，而是提供一个广泛的概述。软件包的安全性和真实性检查是一个讨论了相当长一段时间的话题(例如参见https://github.com/composer/composer/issues/38)，但至今没有任何结果。