composer audit 不依赖镜像源，直接从 friendsofphp 数据库获取漏洞数据；中文镜像不影响 roave/security-advisories 插件生效，但需保留 packagist.org 源且配置 secure-http=true；私有包和 dev 分支不被扫描，需额外安全策略。
composer audit 依赖的 security-advisories 数据库不会随镜像自动更新
composer audit 命令本身不走镜像源，它直接从 https://security.sensiolabs.org/check_lock（或 Composer 2.5+ 内置的 FriendsOfPHP 数据库）拉取漏洞数据，和你配置的 repo.packagist 镜像无关。换阿里云/腾讯云镜像后，audit 结果滞后，根本原因不是镜像没同步，而是 FriendsOfPHP 数据库更新延迟，或本地缓存未刷新。
- Composer ≥ 2.5 默认每 24 小时自动更新一次 advisory 数据库，但首次运行或长时间未用时可能仍用旧快照
- 手动触发更新：运行
composer self-update --update-keys（仅刷新签名密钥），再执行composer audit --no-cache强制跳过本地 advisory 缓存 - 验证是否最新：检查
$(composer config --global cache-dir)/advisories/下advisories.json的修改时间，应 ≤ 24 小时 - CI 环境中建议加
--no-cache，避免因缓存陈旧漏报 CVE-2026-XXXX 类新披露漏洞
roave/security-advisories 插件在中文镜像下仍生效，但有前提条件
roave/security-advisories 是一个“冲突包”，它通过在 composer.json 中声明 "conflict" 规则，让 Composer 解析器在 install 或 update 时主动拒绝安装已知高危版本。它不依赖远程元数据，因此不受镜像源影响——但前提是你的镜像配置不能破坏依赖解析流程。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须保留
"packagist.org": true（或不设packagist键），否则 Composer 会跳过官方源的 conflict 检查逻辑 - 若全局配置了
"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}]，需确认该镜像返回的packages.json包含完整require和conflict字段（阿里云、腾讯云均支持） - 运行
composer show roave/security-advisories，输出中conflicts行应列出数十个包名，而非空 - 注意：它只拦截安装，不扫描已存在的
vendor/；已有漏洞包不会被自动卸载
镜像源配置错误会导致安全审计链路断裂
最隐蔽的风险是：你以为用了中文镜像 + audit，其实签名验证和元数据校验已被悄悄关闭。安全审计依赖两个底层机制——包完整性签名（signature 字段）和 HTTPS 元数据传输，而错误的镜像配置会同时破坏二者。
- 禁用
secure-http（如执行composer config -g secure-http false）→ 允许 HTTP 镜像 → 元数据可被中间人篡改 →audit基于污染数据判断，结果不可信 - 用
composer config -g repo.packagist composer http://...（协议为http）→ Composer 自动降级并跳过 signature 验证 → 即使audit报“OK”，vendor/ 里的代码也可能已被投毒 - 正确姿势：先
composer config -g secure-http true，再composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/，最后composer diagnose确认secure-http: OK和signature verification: OK
私有包和 dev 分支无法被 audit 扫描，需额外策略
composer audit 只检查 composer.lock 中锁定的**正式发布版本**，对 "dev-main"、"1.2.x-dev" 或内部 Git 仓库包完全忽略。这类包恰恰是供应链攻击高发区，中文镜像加速它们时，反而掩盖了风险。
- 私有包必须显式加入 FriendsOfPHP 数据库才可被扫描，目前无自动化入口；企业需自行维护内部 advisory 清单，并用
php -r "..."脚本比对 - 对
dev-分支，强制要求在composer.json中添加"minimum-stability": "stable"，并禁用"prefer-stable": true外的任何不稳定约束 - CI 流程中，对私有包做二次校验：用
git ls-remote检查 tag 是否存在，再用composer show --all确认其composer.json中无危险函数调用 - 镜像源对私有包无效，别指望它提升安全水位；真正要加固的是 Git 权限、Satis 元数据签名、以及
auth.json凭据轮换机制
audit OK 结果，背后是 HTTPS 连接、签名验证、数据库同步、锁文件哈希四个环节同时成立——任一环节被镜像配置绕过，整个安全链条就断了。
