Composer audit仅检测已知CVE和安全通告，不分析代码行为或0day漏洞；需配合allow-plugins白名单和magento/composer-dependency-version-audit-plugin共同防御。
直接结论：不要依赖单一插件“拦截恶意代码库”，Composer 本身不扫描代码行为，只管包元数据和已知漏洞；真正起作用的是 composer audit、allow-plugins 白名单、以及 magento/composer-dependency-version-audit-plugin 这类专用防护插件的组合使用。
composer audit 能查什么，不能查什么
它查的是已知 CVE 和安全通告（来自 FriendsOfPHP Security Advisories 数据库），不是静态分析或沙箱执行。只要包被收录进数据库，composer audit 就能报出类似 found 1 security vulnerability advisory affecting 1 package xyz cve-2024-12345 的提示。
- 必须确保你用的是 Composer 2.5+，旧版本不内置该命令
- 它不检测未披露的 0day、不分析 PHP 代码里有没有
exec()或eval()，也不识别混淆攻击 - 运行
composer audit --format=json可用于 CI 解析；加--no-dev可跳过开发依赖检查 - 若想强制失败（而非仅警告），在
composer.json中设"audit": {"block-insecure": true}
allow-plugins 不是功能开关，是执行闸门
从 Composer 2.2 开始，allow-plugins 默认为 {"*": false}，意味着任何插件——包括 symfony/flex、laravel/pint，甚至 transitive 依赖带进来的二级插件——都会被拒绝加载，除非你显式授权。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 错误做法：
"allow-plugins": true—— 这等于关掉所有插件安全控制 - 正确写法：
"config": {"allow-plugins": {"symfony/flex": true, "laravel/pint": true}}，包名必须完全匹配，不支持通配符如"*/*" - 生产环境部署时，必须加
--no-plugins参数（注意位置：必须紧跟composer install后，不能写成composer --no-plugins install） - 如果某插件仍报错，说明它依赖另一个未授权插件，得顺藤摸瓜补全白名单
magento/composer-dependency-version-audit-plugin 防的是混淆攻击
它解决的是“私有包名被公共仓库同名高版本覆盖”的典型供应链攻击场景，不是通用杀毒工具。它只在 composer install 或 composer update 期间介入，对比私有源与 Packagist 上同名包的最高可用版本。
- 安装方式：
composer require --dev magento/composer-dependency-version-audit-plugin - 它不会阻止非混淆类风险（比如包本身含后门但版本号低），也不会替代
composer audit - 启用后，若检测到公共版本 > 私有版本，会立即中断并输出明确错误，例如：
Dependency confusion detected: vendor/private-package has version 1.2.0 in private repo, but 1.3.0 exists on packagist.org - 企业私有仓库必须提前在
composer.json的repositories中正确定义，否则插件无法识别“哪个是你的私有源”
CI/CD 流程里最容易漏掉的三个硬性动作
本地跑通不代表上线安全。CI 脚本里若没写死，就等于没做。
- 必须用
composer install --no-plugins --no-scripts --no-dev --prefer-dist安装生产依赖，缺一不可 -
composer.lock必须提交进 Git，且 CI 中禁止执行composer update（除非是专门的依赖更新流水线） - 每次 PR 合入前，CI 应运行
composer audit --no-dev+composer validate+composer normalize --dry-run，任一失败即阻断
复杂点在于：这些机制彼此不重叠。一个包可能通过了 audit（无已知 CVE），又在 allow-plugins 白名单里（作者可信），但仍因版本混淆被 magento/composer-dependency-version-audit-plugin 拦下——三者得同时在线，防线才算完整。
