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