解读

在国内一线/二线互联网公司的 PHP 面试中，Composer 已从“加分项”变成“必考点”。面试官抛出“Composer Audit 怎么用”时，通常不是让你背一条命令，而是想确认三件事：

1. 你是否真的在生产环境做过依赖治理；
2. 你是否能把安全漏洞与业务风险对应起来；
3. 你是否具备“自动化 + 流程化”意识，能把 Audit 结果落地到 CI/CD。
   因此，回答要围绕“命令 → 结果 → 处置 → 闭环”四步展开，并给出国内可落地的工程化方案。

知识点

1. Composer 2.3+ 内置 audit 子命令，无需额外插件。
2. 数据源：默认访问 Packagist 官方 Advisory Database；国内若网络受阻，可配置 https://mirrors.aliyun.com/composer 或腾讯云镜像，但 Advisory 仍需翻墙，企业内网建议搭建 Packagist 代理 + 本地 Advisory 镜像。
3. 判定级别：low / moderate / high / critical；PHP 国内监管把 critical 直接映射为“高危”，必须 24h 内修复。
4. 返回码：0 表示无漏洞；1 表示有漏洞；2 表示参数错误。CI 流水线用返回码做门禁。
5. 忽略规则：可在 composer.json 新增 extra.audit.ignore 节点，但需走内部安全评审，禁止私自白名单。
6. 与 roave/security-advisories 的区别：roave 是“硬性拦截”，audit 是“扫描报告”；两者互补，国内大厂双线并行。
7. 合规要求：等保 2.0 三级系统要求“第三方组件定期扫描并留存报告”，Audit 结果需入库 ELK，保留 6 个月备查。

答案

“Composer Audit 的使用分三步：扫描、评估、闭环。
第一步，扫描。
本地开发：composer audit --format=plain 直接出结果；若在内网 CI，先 export COMPOSER_REPO_PACKAGIST=https://repo-packagist.internal，再 composer audit --no-dev --format=json > audit.json，保证只扫生产依赖并生成机器可读报告。
第二步，评估。
把 audit.json 上传到内部安全平台，平台按 critical 自动开 Jira 工单并 @对应服务 owner；同时根据 OWASP Top10 做二次评级，例如 Laravel <6.0.2 的 SQL 注入虽标记为 high，但业务没有用到 ::whereRaw，可降级为 medium。
第三步，闭环。
修复策略三选一：①升级组件，composer require vendor/package:^2.3.4 --with-all-dependencies；②如升级不兼容，先打临时补丁，用 cweagans/composer-patches 在 composer.json 中引用 patch 文件，再排期重构；③若漏洞在 dev 依赖且线上无引用，写审计说明后关闭工单。
最后把 composer audit 命令固化在 GitLab-CI 的 test 阶段，返回码非 0 即阻断合并请求，实现‘安全左移’。上线前再跑一次 composer audit --locked，确保 lock 文件与仓库一致，完成合规闭环。”

拓展思考

1. 镜像一致性：国内团队常用阿里云 Composer 镜像，但 Advisory 数据仍走 github.com/advisories，若 CI 无法翻墙，可用 GitHub 官方 API 自建同步脚本，每小时拉取一次，落入内网 MinIO，Composer Audit 通过 COMPOSER_AUDIT_DATABASE_URL 指向内网地址，实现“离线也能扫”。
2. 多语言联动：微服务架构下，PHP 服务只占总集群 30%，如何把 Composer Audit 的结果与 Node npm audit、Java OWASP Dependency-Check 统一成一份“物料清单（SBOM）”？可基于 CycloneDX 标准，把各语言报告转成 BOM 格式，再送入 Dependency-Track 做集中治理，方便等保测评时一键导出。
3. 红蓝对抗：在护网行动中，蓝队常利用“已知漏洞未修复”作为突破口。把 Composer Audit 接入 Prometheus exporter，critical>0 自动触发蓝队告警，并联动 K8s 将对应 Pod 镜像打污点，实现“漏洞出现即隔离”，把风险窗口从小时级降到分钟级。