composer audit 不扫描敏感配置，仅检查 composer.lock 中已安装包的已知漏洞和废弃状态；它不读取 .env、config/*.php 或环境变量，敏感信息检测需借助 git-secrets、truffleHog、semgrep 等外部工具。
Composer 本身不校验敏感配置数据——它连环境变量、.env 文件、config/*.php 里的值都完全不读，更不会检查数据库密码是否硬编码、API Key 是否明文写死。 所有声称“Composer 自带敏感信息扫描”的说法，都是混淆了依赖审计和配置合规的边界。
为什么 composer audit 和 composer validate 都不碰敏感配置
这两个命令的工作范围严格限定在 composer.json 和 composer.lock 的结构与元数据层面：
-
composer audit只查已安装包的已知漏洞（CVE/GHSA）和废弃状态，路径、内容、环境变量一概无视 -
composer validate只校验 JSON 格式、字段是否存在、版本约束是否合法，对 "password": "123456" 这种明文配置视而不见 - 所有
.env、config/database.php、resources/secrets.yml类文件，Composer 默认不加载、不解析、不告警
真正能查敏感配置的工具必须独立介入
你需要在 Composer 流水线中显式引入外部扫描器，并确保它运行在代码检出后、依赖安装前或后（取决于扫描目标）：
- 查
.env明文密钥：用git-secrets（CI 前置）或truffleHog（扫描整个工作区） - 查 PHP 配置文件硬编码：用
php -l+ 自定义正则脚本，或semgrep规则php.lang.security.hardcoded-credentials - 查 YAML/JSON 配置中的敏感字段：用
gitleaks或checkov（支持自定义策略） - CI 中推荐写法：
gitleaks detect --source=. --no-git --verbose || true（加|| true避免漏配导致构建中断）
最容易被忽略的三个盲区
这些地方既不在 Composer 管控范围内，又常被人工审查跳过：
-
vendor/下某些包自带示例配置（如vendor/some-sdk/config/example.env），被误提交到 Git 后长期潜伏 -
composer.json的scripts段里写 shell 命令时拼接密钥，例如："deploy": "curl -H 'Authorization: Bearer $API_KEY' ..."——$API_KEY在 CI 中若未屏蔽，日志直接泄露 - 私有 Packagist 仓库的
composer.json元数据里填了测试用的"homepage": "https://admin:secret@staging.example.com"，composer show会原样输出
敏感配置合规不是靠一个命令就能闭环的事。它需要把扫描工具嵌进 Git Hook 或 CI 步骤，且必须覆盖从开发机到私有包元数据的全链路——Composer 只是起点，不是终点。
