composer audit 默认不检查 dev 依赖，CI 中漏加 --dev 会跳过 phpunit 等开发工具链漏洞扫描；需固定使用 composer audit --dev --no-interaction，并配合 validate --strict 防止平台兼容问题。
composer audit 默认不查 dev 依赖，CI 里漏掉 --dev 就等于放行一半漏洞
默认 composer audit 只扫描 composer.lock 中已安装的生产依赖（require 下的包），require-dev 里的 phpunit/phpunit、mockery/mockery、roave/security-advisories 全部被跳过。CI 流水线若没加 --dev，等于主动绕过开发工具链的安全检查。
实操建议：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 脚本中固定使用
composer audit --dev --no-interaction，避免交互中断构建 - 高危拦截场景下加
--severity=high,critical，中低危可先记录不阻断 -
roave/security-advisories必须放在require-dev，放错位置会导致生产环境因冲突无法启动
audit 不是 CVE 扫描器，私有包、fork 包、path 依赖默认静默跳过
composer audit 底层只对接 Symfony Security Advisory Database，不查 NVD 或 GitHub Advisory Database。对未收录的包，它不会报错，而是直接忽略——你看到 No advisories found 不代表安全，只代表“没数据”。
实操建议：
- 私有包或 fork 包需手动在
composer.json中声明"type": "package"并提供security-advisories元数据字段 - 运行
composer config repositories确认源是否可信，警惕非https://packagist.org的自定义仓库 - 关键私有包要人工补位：定期查其 GitHub/GitLab 的
SECURITY.md、issues标签和最近 commit 活跃度
audit 和 validate --strict 必须并行跑，否则 PHP 版本/扩展不兼容问题完全漏检
composer audit 只管漏洞，不管你的 platform 配置是否合理。比如项目强制 "php": "8.2"，但某个依赖最新版只支持 8.3+，audit 完全不会提醒——这会导致部署失败或运行时崩溃。
实操建议：
- CI 中紧接
composer audit --dev后执行composer validate --strict - 若用了
config.platform，validate --strict会据此检查扩展是否存在、PHP 版本是否匹配 - 某些 CI 镜像（如阿里云、腾讯云 Composer 镜像）会缓存或丢弃
platform元数据，核心项目建议直连https://packagist.org
audit --fail-on-warnings 是 CI 构建失败的底线，但必须配合 self-update --2
老版本 Composer（
实操建议：
- CI 第一步必须执行
composer self-update --2，确保用的是 2.5.0+ 版本 - 构建脚本中启用
composer audit --dev --fail-on-warnings，中危及以上即中断 - 输出 JSON 方便解析：
composer audit --dev --format=json | jq '.advisories_count'，用于判断真实漏洞数
--dev、--strict、--fail-on-warnings 和 self-update --2 四个条件同时落在 CI 脚本里——少一个，就可能漏掉一条能导致 RCE 的路径。 
