composer 无法拦截反序列化漏洞，因其仅管理依赖而不解析php源码或构建ast；composer audit仅比对cve数据库，不分析代码逻辑；需用phpstan、psalm等独立工具进行ast扫描，但存在漏报、解码限制及ci耗时问题。
composer 本身不支持、也无法通过静态 AST 分析拦截包内潜在的反序列化漏洞利用。这不是功能缺失，而是设计边界问题——Composer 是依赖管理器，不是代码分析引擎。
为什么不能用 Composer 做 AST 分析？
Composer 的核心职责是解析 composer.json、下载包、写入 vendor/、生成自动加载映射。它不解析 PHP 源码，也不构建抽象语法树（AST）。所有“扫描”类能力（如 composer audit）都只比对已知 CVE 元数据，不触碰实际代码逻辑。
composer audit 和 AST 分析根本不是一回事
composer audit 只做三件事：
- 读取
composer.lock中每个包的name和version - 查 FriendsOfPHP 安全数据库里是否有该
(name, version)组合的已披露 CVE - 输出匹配项，不执行任何 PHP 文件，不解析函数调用链，不识别
unserialize()出现在哪行哪列
哪怕一个包里明文写着 unserialize($_GET['data'])，只要没被录入 CVE 数据库，composer audit 就完全看不见。
真要搞 AST 级反序列化风险检测，得换工具链
可行路径是：在 composer install 后，用独立静态分析工具扫描 vendor/ 目录。例如：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
phpstan+ 自定义规则：可检测未校验的unserialize()调用，但需手动编写规则并启用高严格度 -
psalm：支持--find-dead-code和自定义污点追踪，能识别从 $_GET → unserialize → exec 的潜在链，但需配置 source/sink -
php-cs-fixer不行，它只格式化；phpmd规则太粗，无法精准定位反序列化入口点
注意：这些工具默认不启用反序列化链检测，必须显式启用污点分析或加载安全插件，且对魔术方法（如 __wakeup）的跨文件调用链支持有限。
最容易被忽略的现实约束
即使你跑通了 AST 扫描，也会立刻撞上三个硬限制：
- 第三方包大量使用动态类名、
call_user_func、eval或反射，静态分析必然漏报 - 恶意 payload 常藏在 base64 编码字符串、注释、测试文件里，AST 工具默认不解码、不执行、不展开
- 扫描
vendor/意味着每次composer update后都要重跑，CI 中耗时可能从秒级升到分钟级
所以别指望靠改 composer.json 或写个 Plugin 就让 Composer 自己学会看代码——它连 PHP 解析器都不是。
