Composer audit默认不生效，需确认版本≥2.5.0、启用experimental.audit配置、显式加--dev参数扫描开发依赖，且仅比对Packagist安全数据库，不检测私有包、fork包及PHP platform兼容性。
Composer 依赖安全不能靠 composer install 自动兜底，audit 功能默认不生效、不报错、不阻断，必须手动确认版本、开启配置、补全参数，否则 CI 里跑十次也等于没扫。
如何确认 composer audit 真正在工作
很多人执行完 composer audit 看到 “No security vulnerabilities found” 就以为万事大吉，其实它可能根本没运行——或者运行了但跳过了所有包。
- 先检查版本：
composer --version必须 ≥ 2.5.0；低于这个版本，audit命令不存在或调用的是旧接口 - 再查命令是否可见：
composer list | grep audit，无输出说明 feature flag 没开或版本不支持 - 启用实验特性：
composer config --global experimental.audit true（该配置写入~/.composer/auth.json） - 验证是否生效：运行
composer audit --format=json，若返回空 JSON 或"advisories": []且无 warning，再看是否有"ignored": true字段——有则说明漏洞被白名单豁免，不是没有问题
composer audit 默认不查 require-dev，CI 里漏掉就等于放行攻击面
默认行为只扫描 require 树下的已安装包（含间接依赖），但完全忽略 require-dev 中的包。而 phpunit/phpunit、mockery/mockery、symfony/var-dumper 这类开发依赖，恰恰常含高危 RCE 或反序列化漏洞。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 中必须显式加
--dev（等价于--with-dependencies），写成：composer audit --dev --no-interaction --severity=high,critical -
--severity不支持low或medium，设了也无效；只认high和critical - 别信退出码为 0：要解析 JSON 输出里的
advisories_count字段，jq '.advisories | length'才是真实漏洞数
私有包、fork 包、path 依赖默认被跳过，audit 不会警告你它没扫
composer audit 底层只比对 Packagist 官方安全数据库（即 Symfony Security Advisory Database），它不认识你重命名的 myorg/guzzle，也不查本地 path 仓库或 GitLab 私有源里的包——更不会报错，而是静默跳过。
- 运行
composer show --locked | grep your-package，确认目标包确实在 lock 文件中 - 再用
composer show --locked --format=json | jq '.packages[] | select(.name == "vendor/package")'查source.type：如果是git、package或path，audit 就不会查它 - 对关键私有包，得人工补位：定期翻 GitHub 的
SECURITY.md、issues?q=label%3Asecurity、最近 commit 时间和 maintainer 活跃度 - 若要用 audit 覆盖 fork 包，必须在
composer.json里手动声明"type": "package"并提供security-advisories元数据，否则无效
audit 不校验 PHP 版本兼容性，platform 配置失效时它一声不吭
composer audit 只管漏洞，不管你的 "platform": {"php": "8.2"} 是否合理。比如某个依赖最新版只支持 PHP 8.3+，但 lock 文件里锁的是旧版能跑；audit 通过了，部署时却因扩展缺失或语法错误直接崩溃。
- 必须并行执行：
composer validate --strict，它会检查 platform 是否匹配、扩展是否存在、PHP 版本约束是否被满足 - 某些 CI 镜像（如阿里云 Composer 镜像）会丢弃
platform元数据，建议核心项目直连https://packagist.org -
composer install时不加--no-dev，可能导致 dev 依赖污染生产环境；CI 中应固定为：composer install --no-dev --no-interaction
真正卡住漏洞的不是 audit 命令本身，而是你有没有在 CI 里强制它查 --dev、有没有验证它是否真读到了私有包、有没有用 validate --strict 补上 platform 缺口——这些环节任意一个松动，审计就形同虚设。
