背景
Composer 2.9.6 和 2.2.27 LTS 修复了 Perforce driver 中的两处命令注入问题：
| 编号 | 触发点 | 关键风险 |
|---|---|---|
| CVE-2026-40261 / GHSA-gqw4-4w2p-838q | package metadata 中的 malicious Perforce source reference / URL | 在 source install 场景下影响底层命令构造 |
| CVE-2026-40176 / GHSA-wg36-wvj6-r67p | root composer.json 或 Composer config 中的 malicious Perforce repository definitions |
在不可信项目里运行 Composer 时触发 |
这不是"所有 Composer 用户都会被远程扫穿"的漏洞，也不是一个互联网暴露端口就会被批量利用的 RCE。
但它特别适合提醒 AI Coding Agent 时代的一个现实问题：
当 Agent 从"建议代码"变成"替你执行命令"，依赖安装、构建、测试和脚本执行都会变成安全边界。
composer install、npm install、pip install、go test、make、docker build 这些命令，本质上都在处理外部输入、读取项目配置、访问网络、调用工具链，有时还会触发脚本、插件和认证逻辑。
如果这些动作发生在一个带有 .env、SSH key、GitHub token、云凭据、私有包仓库权限或内网访问能力的环境中，风险就不再只是依赖管理器本身，而是 Agent 执行环境的整体风险。
一句话模型
text
AI Coding Agent 风险 = 不可信输入 × 自动执行 × 高权限环境这三个条件同时出现时，很多普通开发命令都会被放大：
| 条件 | 示例 |
|---|---|
| 不可信输入 | 陌生 GitHub 仓库、外部 PR、用户上传代码包、README 安装命令、第三方依赖元数据 |
| 自动执行 | 安装依赖、运行测试、执行构建、修复 lint、启动服务、调用脚本 |
| 高权限环境 | 开发者本机、带 token 的 CI runner、能访问内网的 dev container、挂载云凭据的 workspace |
所以，安全检查不能只问"Agent 的 Prompt 有没有写不要泄露秘密"。
Prompt 是软边界。容器、网络、凭据、文件系统、日志和人工确认才是硬边界。
为什么 Composer 这个案例值得拿来讲
很多团队看到 Perforce，会先说一句："我们不用 Perforce，所以和我们关系不大。"
这个判断不够稳。
问题不在团队平时是不是主动用 Perforce，而在于：
- 依赖管理器支持的后端能力，往往比团队日常意识到的多
- 攻击者不需要你真的把 Perforce 当主力工具，只需要让工具链处理一段恶意构造的元数据或项目配置
- 当 Agent 自动替你跑
composer install、composer update、测试和构建时，它已经从"看代码"跨到了"执行工具链"
所以这个案例真正提醒我们的不是 PHP 生态新闻，而是：
AI Agent 工作流里，任何会处理不可信项目配置、依赖元数据和外部仓库信息的命令，都应该被重新当成执行边界来看。
五个必须先问的问题
1. 这个仓库是否可信
先区分 Agent 正在处理什么代码来源：
| 来源 | 推荐策略 |
|---|---|
| 内部长期维护仓库 | 可使用标准 devcontainer，但仍需命令留痕 |
| 外部开源仓库 | 只进入 disposable sandbox |
| 外部 PR | 默认无高权限 secret，避免直接暴露 CI 凭据 |
| 用户上传代码包 | 默认无网络、无密钥、只读挂载 |
| 未知来源压缩包 | 先静态查看依赖文件和构建脚本，不直接执行 |
最低要求：
- 陌生仓库不在工程师真实工作目录中直接运行
- Agent 执行前标注代码来源和信任等级
- 从"读代码"到"执行代码"必须是一个显式动作
2. 执行环境里有没有真实凭据
命令注入最现实的危害，往往不是"执行了一条命令"，而是"这条命令能读到什么身份"。
需要检查：
| 凭据类型 | 例子 |
|---|---|
| 项目凭据 | .env、配置文件、数据库连接串 |
| 开发凭据 | SSH key、Git credential helper、GitHub token |
| 云凭据 | AWS / GCP / Azure CLI 登录态、环境变量、metadata endpoint |
| 包仓库凭据 | Composer / npm / pip / Docker registry token |
| 集群凭据 | kubeconfig、CI/CD secret、发布凭据 |
最低要求：
- 陌生代码执行环境里不放生产密钥
- 如需访问私有包源，使用短期、只读、可吊销 token
- 不要把同一个环境同时用于"跑陌生代码"和"持有真实凭据"
3. 依赖安装有没有网络出口限制
如果命令可以执行，同时还能任意外联，风险会迅速升级。
需要检查：