保障框架底层安全：借助Composer自动审计机制每日巡检核心代码

说到Composer，很多人第一反应是“它能做安全审计”，甚至觉得它能自动帮我们每天巡检代码。这其实是个不小的误会。这事儿得说清楚：Composer本质上就是个依赖管理器，它的本职工作是帮你搞清楚要装哪些包、装哪个版本，至于安全扫描？抱歉，那不是它的活。

你可能会好奇，那网上常提到的“Composer自动审计机制”是怎么回事？我们来掰扯掰扯。

composer audit 命令根本不存在

如果你在终端敲过 composer audit 然后收到一个 Command "audit" is not defined 的报错，别怀疑，你不是一个人。Composer 的核心命令列表里，压根就没有这个名字。v2.5+ 版本引入了一个实验性的 composer validate --strict，能做一部分完整性检查，但和人们想象中的“漏洞扫描”是两码事——它既不联网查CVE数据库，也不知道你项目里引用的库是否有已知漏洞。

• 那些能扫漏洞的工具，其实是独立的：composer security-checker（已归档）、roa ve/security-advisories（被动阻断型）、或者 sensiolabs/security-checker（已停更）
• 当前比较推荐的组合是：composer install --no-dev 之后，再跑 php -d memory_limit=-1 vendor/bin/security-checker security:check（需要先手动安装 security-checker CLI）
• 如果用了 GitHub Actions，可以配合 php-actions/composer 加 whitesource/whitesource-scan-action 来实现自动触发扫描

roa ve/security-advisories：防得住安装，管不了已存在的漏洞

这个包的思路很有意思——它本质上是一个“冲突声明列表”。你在 composer.json 里写上 "roa ve/security-advisories": "dev-master"，Composer 在安装或更新时，只要碰到已知的高危版本，直接拒绝掉。但请注意，它是被动阻断的：

• 它不扫描 vendor/ 目录里的现有文件
• 不会读 composer.lock 去做回溯分析，看哪些历史版本是被标记为有问题的
• 更关键的是，面对间接依赖——比如 monolog 依赖了 symfony/http-foundation，后者又依赖了 guzzlehttp/psr7——这种链条上任何一环出现低版本漏洞，它都无能为力
• 如果项目把 minimum-stability 禁了，或者设置了 prefer-stable: false，这个防御机制甚至可能被绕过

真正能跑起来的“每日巡检”，得自己搭闭环

没有现成的“Composer 每日巡检”开关，这事儿必须靠外部调度来驱动：定时扫描、抓取结果、发出告警。选择什么工具反而不是最关键的，关键在于能把扫描的输出变成真正可执行的信号。

• 对小项目来说，用 curl -sS https://security.symfony.com/check_lock | php composer.lock 这个 Symfony 官方在线检查器已经够了。但缺点是依赖外网，而且没有任何认证，内网环境完全用不了
• 本地化方案推荐 oss-review-toolkit (ORT) 或者 phpstan-security（通过静态分析来补漏），然后配合 crontab -e 来每日跑一次：0 3 * * * cd /var/www/myapp && /usr/bin/php /usr/local/bin/composer update --dry-run 2>&1 | grep -q "CVE\|advisory" && echo "$(date): vulnerability found" | mail -s "Composer Audit Alert" admin@example.com
• 注意一点：所有扫描最好在干净环境里执行（加上 --no-cache、小心对待 --ignore-platform-reqs），因为PHP版本差异可能导致漏报

话说回来，这个领域的真正难点其实不在于“能不能扫”，而在于后续处理——如何把误报和真实漏洞区分开？比如一个只在开发阶段使用的包出现在生产环境的 lock 文件里，算不算风险？又比如某个 API 接口引用了带漏洞的 firebase/php-jwt，能不能把这个调用路径找到？最头疼的是，当有人偷偷改了 composer.lock 文件绕过了检查，怎么从 Git 历史里把这个变更揪出来？这些复杂场景，没有哪一行命令能够搞定。