如何在企业内部建立Composer镜像审计机制-composer-PHP中文网

composer audit不是审计机制，仅是一次性检查；企业级审计需嵌入ci、绑定pr、存档追溯，依赖锁定的advisories快照、禁用网络与交互，并解析json输出按严重等级拦截。

如何在企业内部建立composer镜像审计机制

composer audit 命令本身不构成审计机制

直接运行 composer audit 只是触发一次性检查，不是“机制”。企业级审计必须可重复、可集成、可追溯——它得嵌进 CI 流水线里，绑定 PR 合并前检查，且结果能存档比对。否则每次手动跑，等于没机制。

常见错误现象：开发在本地跑 composer audit 没报错，CI 构建时却失败；或同一份 composer.lock 在不同时间点扫描出不同结果——说明没锁定数据源或没固化环境。

composer audit 依赖 PHP-SECADV 数据库，该库每日更新但无版本号，必须用 --advisories-url 指向你托管的静态快照（如 https://mirror.internal/sec-advisories-20260615.json）
必须搭配 COMPOSER_NO_INTERACTION=1 和 COMPOSER_DISABLE_NETWORK=1，否则插件或 fallback 会偷偷联网，破坏审计确定性
CI 中不能只看 exit code，要解析 --format=json 输出，提取 .advisories[].id 和 .advisories[].severity，再按策略拦截 critical/high

私有镜像源必须提供 security-advisories 兼容接口

如果你用 Satis 或 packagist-mirror 搭建了内部镜像，但 composer audit 仍报 Could not fetch advisories，大概率是镜像服务没暴露安全通告端点。官方 Packagist 的 /advisories 路径不是标准协议，需显式支持。

使用场景：当企业定制了某个开源包（如 patch 后的 guzzlehttp/guzzle），而该 patch 修复了 CVE，但上游尚未发布——你需要把自定义通告注入镜像源，让 audit 能查到。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

Satis 不原生支持 /advisories，需在生成的 web/ 目录下手动放一个 advisories.json 文件，并确保 Nginx 返回 application/json MIME 类型
packagist-mirror 默认不启用 advisory 同步，启动时需加 --with-advisories 参数，且要求后端数据库字段完整（缺 advisory_id 或 published_at 会导致解析失败）
所有自定义通告必须含 affected 字段，格式严格为 {"name": "vendor/package", "version": ">=1.0.0 ，多一个空格或引号都会被忽略

审计结果必须与锁文件哈希强绑定

审计不是查“当前有没有漏洞”，而是查“这份 lock 文件对应的依赖组合是否已知存在风险”。脱离 composer.lock 的哈希值谈审计，毫无意义——因为同一份 composer.json 在不同时间 install 出来的依赖树可能完全不同。

性能影响：每次审计都重新下载 PHP-SECADV 全量数据（约 8–12MB）会拖慢 CI；更关键的是，若未校验 lock 文件完整性，攻击者可篡改 lock 中的 dist.shasum 却保留旧版 advisory 匹配结果，造成漏报。

CI 脚本第一行应计算 sha256sum composer.lock 并记录到日志，后续所有审计动作标注该哈希
禁用 --no-dev 时，roave/security-advisories 这类 dev-only 包的 advisory 也会被加载，但实际运行时不存在——需在审计前用 composer install --no-dev --dry-run 验证生产依赖边界
若用 artifact 模式离线部署，composer audit 仍会尝试访问网络通告源，必须提前用 composer config --global repositories.0.url file://./advisories.json 替换默认源

权限与审计日志不可分离

审计机制一旦上线，就不再是开发工具，而是合规证据链的一环。没人能删掉某次扫描记录，也没人能绕过它跳过构建——这意味着权限控制和操作日志必须前置设计，而非事后补救。

容易踩的坑：运维给所有人开了 composer config --global 权限，结果有人关掉了 experimental.audit；或者 CI 使用共享 $COMPOSER_HOME，导致不同项目审计配置互相污染。

CI 环境中禁止写全局 config，所有审计参数必须通过环境变量传入：COMPOSER_AUDIT_SEVERITY=critical,high、COMPOSER_AUDIT_FORMAT=json
审计日志必须包含：触发时间、composer.lock SHA256、PHP 版本、composer --version、使用的 advisories URL、exit code 和原始 JSON 输出（截断前 10KB）
禁止在 auth.json 中存放审计相关 token；若需调用内部漏洞库 API，应使用短期 JWT，由 CI 系统动态签发，过期即失效

审计机制真正的复杂点不在命令怎么写，而在于“谁在什么条件下、用哪份数据、对哪个精确的依赖快照做了检查”——这三者缺一不可，且必须全程留痕。少一个，就只是个玩具。