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 流水线中显式引入外部扫描器，并确保它运行在代码检出后、依赖安装前或后（取决于扫描目标）：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 查 .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 只是起点，不是终点。