Composer 不使用 finfo 扩展做依赖安全检查，其内置的 composer audit 命令（v2.5.0+）仅通过比对 composer.lock 与 Packagist 安全数据库实现漏洞扫描，全程不调用 finfo 函数，也不分析文件魔数。
Composer 本身不使用 finfo 扩展做依赖安全检查——它压根不调用 finfo，也不基于文件魔数（magic number）分析包内容。所谓“用 finfo 检查 Composer 依赖安全”是一个常见误解，根源在于混淆了「文件类型识别」和「依赖漏洞扫描」两个完全不同的技术场景。
Composer 安全检查靠的是 composer audit，不是 finfo
Composer 自带的安全审计功能从 v2.5.0 起内置 composer audit 命令，它连接 Packagist 的安全告警数据库（composer/security-advisories），比对 composer.lock 中的已安装包版本与已知 CVE 是否匹配。
这个过程不读取任何 PHP 文件内容，更不需要 finfo 扩展。它只解析 JSON 格式的锁文件和远程 JSON 告警列表。
实操建议：
- 确保 Composer 版本 ≥ 2.5.0：
composer --version
- 运行审计：
composer audit
（默认检查所有依赖）或限定范围：composer audit --only=monolog/monolog
- 若提示
Command "audit" is not defined，升级：composer self-update
finfo 扩展根本不会被 Composer 加载或调用
即使你服务器上启用了 finfo（例如通过 extension=finfo.so），Composer 的核心流程（install/update/require）也完全不调用 finfo_file()、finfo_open() 等函数。它的包下载靠 cURL 或 PHP Stream，解压靠 ZipArchive 或 PharData，校验靠 SHA-256 和签名，和文件类型识别无关。
常见错误现象：
- 误以为启用
finfo就能“增强 Composer 安全”——实际毫无作用 - 在 CI 环境中因缺少
finfo扩展报错，却去排查 Composer 审计失败——其实报错来自你自己的代码（比如某个上传处理逻辑），不是 Composer - 看到某安全工具文档里同时提到
finfo和 Composer，就认为二者有集成——大概率是该工具在扫描项目源码时独立使用finfo识别可疑文件（如伪装成图片的 WebShell），和 Composer 依赖管理无关
真要结合 finfo 做安全防护，得自己写扫描逻辑
如果你确实想在 Composer 项目中利用 finfo 防御恶意包（比如检测 vendor 目录下是否混入非 PHP 的可执行文件、二进制木马、隐藏脚本），那必须自行实现扫描脚本，Composer 不提供此能力。
示例思路（PHP）：
$finfo = finfo_open(FILEINFO_MIME_TYPE);
foreach (new RecursiveIteratorIterator(new RecursiveDirectoryIterator('vendor/')) as $file) {
if ($file->isFile() && $file->getSize() > 0 && $file->getSize() < 10 * 1024 * 1024) {
$mime = finfo_file($finfo, $file->getPathname());
if (strpos($mime, 'application/x-executable') !== false ||
strpos($mime, 'application/x-sharedlib') !== false ||
strpos($mime, 'text/plain') !== false && preg_match('/<\?php.*eval|shell_exec|system/i', file_get_contents($file))) {
echo "Suspicious: " . $file->getPathname() . " (" . $mime . ")\n";
}
}
}
finfo_close($finfo);注意点：
- 这属于深度安全加固，不是 Composer 标准流程，需额外维护
-
finfo识别有局限：无法识别混淆 PHP、纯文本 WebShell、或加密 payload - 大量小文件会显著拖慢扫描速度，建议加白名单跳过
.git、tests/、docs/ - CI 中运行需确保 PHP 编译时带
--enable-fileinfo
真正容易被忽略的是：安全审计的有效性高度依赖 composer.lock 的完整性。如果有人绕过 Composer 直接改 vendor 文件、或用 git clone 替换包目录，composer audit 就完全失效——它只认锁文件记录的版本，不校验磁盘文件真实性。
