Composer audit 命令完全不检测反序列化漏洞，仅比对 composer.lock 与安全数据库的已知 CVE，无法识别代码中 unserialize() 的危险调用或用户输入污染。
Composer audit 命令本身**完全不检测反序列化漏洞**，它不会分析代码调用链、不会检查 unserialize() 的使用方式，也不识别是否传入了用户可控输入——哪怕你项目里满屏都是 unserialize($_GET['data'])，audit 也视而不见。
为什么 composer audit 查不到反序列化漏洞
它只比对 composer.lock 中的包名和版本号，与 FriendsOfPHP/security-advisories 数据库里的已知 CVE 条目做精确匹配。而绝大多数反序列化漏洞：
- 未被收录进该数据库（尤其私有包、冷门组件、或刚披露未同步的 0day）
- 属于“配置型”或“使用型”风险：同一版本的包，安全与否取决于你是否在危险上下文中调用
unserialize() - 不满足“固定版本即高危”的模式（比如漏洞只在启用某扩展 + 特定类加载路径下触发）
composer audit 能间接提示哪些反序列化风险
仅当某包的某个版本已被官方通告为存在反序列化漏洞，且该通告已录入 FriendsOfPHP 数据库时，audit 才会报出。典型例子包括：
-
monolog/monolog≤ 1.17.2（CVE-2016-10074） -
phpunit/phpunit≤ 4.8.28（CVE-2017-9841） -
symfony/symfony某些旧版本中的CallbackFilterIterator利用链
但注意：audit 不告诉你哪一行调用了 unserialize()，也不说明你是否真的触发了利用路径——它只说“这个版本有风险”，判断权完全交给你。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正能查反序列化问题的替代方案
必须跳出 composer audit 的局限，组合使用以下手段：
- 静态扫描：用
phpstan+ 自定义规则，或psalm配置--find-dead-code+unserialize调用检测插件 - 动态验证：在测试环境构造 payload，用
php -d "error_reporting=-1" script.php观察是否触发__wakeup/__destruct，再结合Xdebug追踪调用栈 - 依赖加固：禁用危险函数（
disable_functions = unserialize），或用igbinary/msgpack替代原生序列化 - 人工审计重点路径：搜索
grep -r "unserialize\|phar://" ./src，特别检查$_GET、$_POST、file_get_contents等输入源
CI 中如何避免漏掉反序列化风险
别只靠 composer audit --severity=high --severity=critical 卡点。你应该：
- 在 CI 脚本中加一步：
grep -r "unserialize(" ./src | grep -v "test\|fixture"，发现就失败 - 用
composer show --outdated --direct找出所有可升级的包，再人工核对其 CHANGELOG 是否修复过反序列化相关 issue - 对关键包（如
phpunit、monolog、swiftmailer）单独写脚本，检查composer.lock中版本是否低于已知修复版本
最常被忽略的点是：反序列化漏洞往往藏在 require-dev 依赖里（比如测试工具链），而 composer audit 默认不扫它们——除非你显式加 --dev 参数，但即便加了，它也只报版本，不报调用。
