composer audit 扫描依赖漏洞的核心是确保 Composer 安全审计能力生效：需版本 ≥2.5.0 并启用 experimental.audit，依赖 composer.lock 精确版本、网络通达 Packagist 安全数据库，且镜像源须同步 security-advisories。
ThinkPHP 项目用 composer audit 扫描依赖漏洞，核心不是框架本身特殊，而是确保 Composer 的安全审计能力在 ThinkPHP 环境中真正生效。它不识别 ThinkPHP 特性，只认 composer.lock 里锁死的包版本——只要锁文件规范、网络通、配置对，就能扫出 Laravel、Symfony 或 ThinkPHP 项目共有的第三方漏洞（比如 monolog、guzzlehttp、swiftmailer 等）。
以下四点最关键：
确认 Composer 版本与实验特性已启用composer audit 是 Composer 2.5+ 官方命令，低于该版本会报错“Command 'audit' is not defined”。
执行：
composer --version
若版本 ≥ 2.5.0 但 composer audit 仍不可用，运行：
composer config --global experimental.audit true
否则命令静默忽略，不报错也不扫描。
立即学习“PHP免费学习笔记（深入）”；
保证 composer.lock 准确且受保护
ThinkPHP 项目常因手动改 composer.json 后忘记 composer install，导致 composer.lock 落后或为空。composer audit 只读 lock 文件，不看 json 中的 ^ 版本约束，也不扫描 vendor/ 目录实际内容。
必须满足：
-
composer.lock存在且非空 - 文件未被
.gitignore排除（否则 CI 里拉不到） -
dist.shasum与本地vendor/中对应包一致（不一致时 audit 主动跳过） - 私有仓库（如公司内部 ThinkPHP 扩展包）需在
composer.json的repositories中明确定义，并提供兼容security-advisories的元数据
按生产环境真实场景执行扫描
ThinkPHP 多数部署在 PHP 7.4–8.2，依赖中常见高危点如：
monolog/monolog （CVE-2023-49070，反序列化）guzzlehttp/guzzle （CVE-2023-29197，DNS 重绑定）-
symfony/http-foundation（被thinkphp/framework间接引入，旧版存在 Session Fixation）
推荐命令：
composer audit --no-dev --severity=critical --severity=high --no-interaction --timeout=30
说明：
-
--no-dev：ThinkPHP 生产环境通常不加载phpunit、phpstan等，跳过开发依赖更贴近真实攻击面 -
--severity=：避免低危 CVE 干扰构建（CI 中默认遇任意 advisory 就失败） -
--no-interaction：防止流水线卡在提示上 -
--timeout=30：国内网络不稳定时防超时挂起
警惕镜像源导致的“假阴性”
很多国内镜像（阿里云、腾讯云）不同步 Packagist 的 security-advisories 接口，即使 composer audit 成功执行，也可能返回 “No security vulnerability detected”，实则漏报。
验证方式：
composer config repositories
若看到非 https://packagist.org 的自定义源，尤其是 HTTP 协议或域名生僻的，建议临时切回官方源：
composer config --global repos.packagist.org '{"url":"https://packagist.org","type":"composer"}'再运行 audit。关键项目不建议长期依赖镜像做安全审计。
ThinkPHP 自身不提供 composer audit 的封装或插件，它的安全水位完全取决于你锁住的生态链——扫得准，靠的是 lock 文件准、源可靠、参数严，而不是框架有多“智能”。
