composer audit不是深度扫描工具，仅比对composer.lock中已安装包的精确版本与friendsofphp安全数据库，不分析调用链、不覆盖私有包或未安装依赖，且默认跳过require-dev；真正实现深度安全需组合audit、allow-plugins白名单和magento/composer-dependency-version-audit-plugin三件套。
composer audit 不是深度扫描工具，它只做版本比对，不分析调用链、不覆盖私有包、不检查未安装依赖——所谓“深度安全透视”，必须组合三件套：audit + allow-plugins 白名单 + magento/composer-dependency-version-audit-plugin。
composer audit 为什么总扫不出漏洞
它根本不是扫描器，只是把 composer.lock 里已安装包的 name + version 拿去比对 FriendsOfPHP/security-advisories 这个静态 JSON 列表。常见失效场景：
- 用了
acme/guzzle-fork这类私有命名空间——audit 只认guzzlehttp/guzzle，其余全跳过 - 版本带
dev-main或自定义分支标签——数据库没收录，比对直接失败 -
composer.lock不完整（比如刚改完composer.json没跑composer update）——audit 读不到 vendor/ 和 installed.json，结果为空 - CI 中漏加
--dev，而漏洞实际在phpunit/phpunit里——require-dev默认被忽略
让 composer audit 真正生效的硬条件
缺一不可，顺序也不能错：
- 先确认版本：
composer --version必须 ≥2.5.0（2.9.6最稳） - 全局启用实验特性：
composer config --global experimental.audit true（写入~/.composer/auth.json，不是项目级） - 确保
composer.lock存在且完整，且vendor/已同步（composer install或composer update后再 audit） - CI 中必须加参数：
composer audit --dev --severity=high --severity=critical --no-interaction
注意：--full 会强制检查所有已安装包（含 dev-only），但它不解决 platform 兼容性问题——那是 composer validate --strict 的事。
私有包和 fork 包怎么防供应链攻击
audit 对它们完全无感，但 magento/composer-dependency-version-audit-plugin 能堵住这个缺口：
- 它专治“同名包被公共仓库高版本覆盖”：比如你内部有
acme/private-utils，攻击者发同名包到 Packagist，composer update就可能自动升上去 - 安装方式：
composer require --dev magento/composer-dependency-version-audit-plugin - 它会在
composer update时校验包来源（是否来自你配置的私有仓库），一旦发现同名包来自 Packagist，立刻中断并报错 - 配合
"allow-plugins": {"magento/composer-dependency-version-audit-plugin": true}使用，否则插件本身会被白名单机制拒绝
依赖链安全不能只靠 audit
audit 只管已知 CVE，真正构成深度防护的是三件套协同：
-
composer audit：查 FriendsOfPHP 数据库里的已知漏洞（CVE-2024-12345 类） -
"allow-plugins"白名单：关掉默认插件加载，防止恶意插件注入（"allow-plugins": {"*": false}是起点，必须显式放行） -
magento/composer-dependency-version-audit-plugin：防私有包名被冒用、防依赖混淆
生产部署还必须加 --no-plugins 参数，且位置要严格紧跟 composer install，否则插件仍可能在 install 阶段执行——这步漏掉，前面三件套就形同虚设。
