Composer的store-auths功能会将私有仓库认证信息以明文存储在auth.json中，导致凭据泄露、多项目共享风险及CI/CD安全隐患，建议禁用该选项并使用环境变量动态注入令牌以提升安全性。
Composer 的 "store-auths" 配置项用于保存私有仓库（如私有 Packagist 或 Git 仓库）的身份认证信息，比如 API Token 或用户名密码。当执行 composer install 或 composer update 时，如果需要从受保护的仓库拉取包，Composer 会提示是否保存这些认证凭据到本地配置中。这个功能虽然方便，但也带来一定的安全风险。
1. 认证信息明文存储
当 store-auths 设置为 true 或选择“总是”保存认证时，Composer 会将敏感凭证以明文形式写入用户主目录下的 auth.json 文件（通常位于 ~/.config/composer/auth.json 或 ~/.composer/auth.json）。这意味着：
- 任何能访问该文件的本地用户或进程都可以查看这些凭据。
- 如果系统被入侵，攻击者可直接获取私有仓库的访问权限。
- 若开发者误将该文件提交到版本控制系统（如 Git），会导致凭据泄露。
2. 多项目共享凭据的风险
auth.json 是全局配置文件，一旦保存，所有使用该 Composer 配置的项目都会继承这些认证信息。这可能导致：
- 本不应拥有访问权限的项目也能拉取私有包，违背最小权限原则。
- 在共享开发环境或 CI/CD 中，容易造成凭据滥用。
3. 在 CI/CD 环境中的隐患
很多团队在持续集成流程中使用 Composer 安装依赖。如果 CI 脚本中启用了 store-auths，可能会无意中将临时生成的令牌长期保存或暴露在构建日志中。更严重的是：
- 某些 CI 平台未妥善清理工作区，
auth.json可能残留并被后续任务读取。 - 日志输出若未过滤，可能打印出认证过程，导致泄露。
4. 默认行为诱导误操作
Composer 在首次遇到私有仓库时会询问是否保存凭据，默认选项是“yes”。这种设计容易让用户习惯性确认，而忽略安全后果。尤其新手开发者可能不了解此机制，导致凭据被长期保留。
为了降低风险，建议：
- 将
store-auths设为false，避免自动保存。 - 通过环境变量传入令牌（如
http-basic结合${ENV_VAR}），并在运行时动态注入。 - 在 CI 中使用一次性令牌，并在任务结束前清除
auth.json。 - 定期轮换私有仓库的访问令牌。
基本上就这些。关键是不要让认证信息持久化地留在磁盘上，尤其是明文形式。安全虽麻烦，但比事后补漏强。
