定期安全审查不能仅依赖单次 composer audit——必须加 --dev 扫描开发依赖，用 2.5.0+ 版本对接 Snyk，手动配置私有包元数据，配合 composer validate --strict 校验平台兼容性，并通过 JSON 输出的 advisories_count 字段判断真实漏洞数。
定期依赖安全审查不能只靠 composer audit 跑一次就完事——它默认不查 dev 依赖、不校验平台兼容性、不覆盖私有包、且老版本 Composer 根本不连 Snyk，漏报率极高。
CI 中必须加 --dev，否则 phpunit/mockery 等开发依赖漏洞全被跳过
默认 composer audit 只扫描 composer.lock 里已安装的生产依赖，require-dev 下的包（比如 phpunit/phpunit、mockery/mockery）完全不进检查范围。CI 流水线里漏掉这个参数，等于把一大半攻击面直接豁免。
- 固定写法：
composer audit --dev --no-interaction，避免交互中断流水线 - 如果只想拦截高危以上漏洞，加
--severity=high,critical - CI 启动阶段务必先跑
composer self-update --2，确保用的是 2.5.0+ 版本（老版本调 Packagist 旧接口，CVE-2023-41277 这类 Laravel 高危漏洞都扫不出来）
composer audit 不等于 CVE 扫描器，私有包和 fork 包默认静默跳过
composer audit 底层只对接 Symfony Security Advisory Database，不是 NVD 或 CVE 官方库。对未收录在该库中的包，它不会报错，而是直接忽略——你看到 “No advisories found” 不代表安全，只代表“没数据”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 私有包、fork 包、
path类型本地依赖，默认不查；要支持，得在composer.json里手动配置"type": "package"并提供security-advisories元数据 - 确认源是否生效：运行
composer config repositories，警惕非packagist.org的自定义仓库，尤其无 HTTPS 或域名生僻的 - 人工补位：对关键私有包，定期查其 GitHub/GitLab 仓库的
SECURITY.md或 issue 标签，关注最近 commit 和 maintainer 活跃度
audit 不校验 PHP 版本兼容性，composer validate --strict 得并行跑
composer audit 只管漏洞，不管你的 platform 配置是否合理。比如项目强制 "php": "8.2"，但某个依赖的最新版只支持 8.3+，audit 完全不会提醒——这会导致部署失败或运行时崩溃。
- CI 中应紧接在
composer audit --dev后执行composer validate --strict - 若用了
config.platform，记得validate会据此检查扩展是否存在、PHP 版本是否匹配 - 注意：某些 CI 镜像（如阿里云、腾讯云 Composer 镜像）会缓存或丢弃
platform元数据，建议核心项目直连https://packagist.org
别信退出码为 0 就万事大吉，得看 advisories_count 字段
composer audit --format=json 输出里有个 "advisories_count" 字段，这才是真实漏洞数。终端渲染常因颜色、截断或 ANSI 控制符让输出看起来“没报错”，其实可能漏了几十条 high/critical 级别告警。
- CI 中建议：用
composer audit --dev --format=json | jq '.advisories_count'提取数值，再判断是否 > 0 - 网络卡住？国内环境常因 DNS 或连接 Snyk API 超时（默认重试 3 次 × 30 秒），可临时加
--ignore-unreachable避免阻塞，但别长期关闭 - audit 不是守护进程，也不轮询——它只是一次性快照。真要“定期”，得靠 CI 定时任务（如 GitHub Actions 的
scheduledtrigger）或 cron 调度
最常被忽略的一点：audit 结果为空，不等于项目干净；它可能只是没连上后端、没配对源、没更新到新版 Composer，或者你正用着一个没人维护却没爆 CVE 的包——这时候，composer outdated 和人工盯 repo 活跃度，比任何自动扫描都管用。
