我正在尝试为企业级应用程序设计部署流程。关于 Composer 是否可以在生产环境中使用，我听到了相互矛盾的意见。
我知道运行 composer update 会是一个错误，因为您可以提取未经测试的版本。相反，在生产中，建议仅使用 composer install。
话虽如此，我最关心的是安全性。中间人攻击是多么容易。如果packagist被黑了，我们可以拉下被黑的代码吗？
我不希望有一个手动流程，每次部署时我都必须手动将供应商文件带过来。目前 Jenkins 会将源文件转移到生产环境中。如果可能的话，我不想对供应商文件夹进行版本控制。
composer install，我真的应该担心安全吗？【问题讨论】：
标签： php composer-php
是的，您应该关注并尝试了解涉及哪些数据传输。
Composer 的当前实现确实在内部使用了大量校验和，但不涉及包签名，因此在composer install 期间下载的任何内容都可能是任何软件，具体取决于托管软件存储库或 TGZ/ 的服务器ZIP 或被询问元数据是有效的目标，可能会被篡改以影响您要安装的内容。
但是请注意，这不仅与安全有关。如果您依赖于在生产部署期间可安装的软件包，则上述任何服务器很可能处于脱机状态。您将如何保护您的部署免受第三方软件托管的任何服务器中断？这个问题的答案很简单：在本地托管软件。
而且这个答案也会影响安全问题：如果您在本地托管软件包，您还可以在内部提供之前审核这些版本。根据您需要的安全级别，您可以检查您获得的每个版本，并将可用版本限制为您能够检查的少数几个版本，或者您可以创建一种更慷慨的方式来断言您获得的软件从原始 Git 存储库中获取，并在本地创建软件的 ZIP 版本（如果您不打算进一步开发包 IMO，ZIP 更方便）。
只有两种已知的软件产品可以提供帮助：Toran Proxy 是 Jordi Boggiano（Composer 核心开发人员之一）的商业产品，它还应该有助于为 Composer 和基础架构的开发提供资金。另一个软件是 Satis，它还允许创建您使用的包的本地副本。
免责声明：我的回答可能没有涉及更详细的细节，并且可能会提供一些过于简短或可能错误的细节。它并不意味着解决每个安全细节，而是提供一个广泛的概述。软件包的安全性和真实性检查是一个被讨论了相当长一段时间的话题（例如参见https://github.com/composer/composer/issues/38），但到目前为止还没有任何结果。
【讨论】：