Composer通过集成第三方工具实现依赖安全检查，主要采用两种策略：一是使用Roave/SecurityAdvisories在安装时阻止引入已知漏洞版本，二是通过Enlightn/SecurityChecker扫描composer.lock文件进行事后审计。前者利用Composer的replace机制防止不安全版本被安装，后者可定期或在CI/CD中运行以发现现有依赖中的漏洞。Composer未内置该功能，是出于职责分离、性能、灵活性和维护成本的考虑。推荐在CI/CD流程中自动化执行security-checker，配置为发现漏洞时中断构建，从而保障部署安全。
Composer本身不直接“检查”安全漏洞，它更像是一个包管理器，负责依赖的安装和更新。它发现依赖安全漏洞的能力，主要依赖于集成第三方工具或服务。这些工具通常会比对你项目中的
composer.lock
文件，与一个持续更新的已知漏洞数据库进行匹配，从而识别出项目中使用的包版本是否存在已披露的安全风险。说白了，Composer提供了一个平台，让这些安全工具能介入并发挥作用。
解决方案
要让Composer项目能够检查依赖中的安全漏洞，我们通常会结合使用两种策略：
预防性安装检查：
Roave/SecurityAdvisories
这是一个Composer包，它的核心思路是在你尝试安装或更新依赖时，如果发现某个包的版本已知存在漏洞，就会阻止Composer安装或更新到那个版本。它通过将已知有漏洞的包版本添加到Composer的
replace
指令中，让Composer认为这些版本已经被“替换”了，从而避免被拉取。
安装方法：
composer require roave/security-advisories:dev-master
或者，如果你想更精确地控制，可以手动编辑
composer.json
，在
require
或
require-dev
中添加：
{ "require-dev": { "roave/security-advisories": "dev-master" }}
然后运行
composer update
。
工作原理： 这个包会动态地在Composer的依赖解析阶段介入。当它发现你尝试安装或更新的某个包版本在
friendsofphp/security-advisories
这个广泛使用的漏洞数据库中有记录时，它就会抛出一个错误，阻止操作。这就像一个门卫，不让“问题”包进入你的项目。
事后审计与持续扫描：
Enlightn/SecurityChecker
或类似工具
Roave/SecurityAdvisories
虽然能阻止新引入的漏洞，但对于已经存在于你项目中的、或者在你安装后才被发现的漏洞，它就无能为力了。这时，你需要一个独立的命令行工具来扫描你的
composer.lock
文件。
Enlightn/SecurityChecker
是一个非常好的选择（它继承了之前
sensiolabs/security-checker
的精神）。
安装方法：
composer require --dev enlightn/security-checker
使用方法：安装后，你可以在项目根目录运行：
./vendor/bin/security-checker security:check composer.lock
这个命令会读取你的
composer.lock
文件，然后将其中的所有依赖及其版本信息发送给一个安全的API端点（通常是
friendsofphp/security-advisories
的API），比对是否有已知漏洞。如果有，它会列出受影响的包、漏洞详情以及建议的修复版本。
结合这两种方法，你就能在依赖引入阶段进行预防，并在项目生命周期中进行持续的漏洞审计。
为什么Composer本身不直接集成漏洞扫描功能？
这其实是个好问题，我个人也曾好奇过。在我看来，Composer作为一个包管理器，它的核心职责是处理依赖关系的解析、下载和安装。安全漏洞扫描，虽然与依赖息息相关，但它是一个相当专业且动态变化的领域，涉及到：
分离关注点原则： Composer专注于“管理”依赖，而不是“审计”依赖。把安全检查功能内置，会让Composer变得过于臃肿，职责不清晰。这就像操作系统负责运行程序，但病毒扫描软件是独立的。漏洞数据库的维护成本： 全球的软件漏洞层出不穷，维护一个全面、实时更新的漏洞数据库是一项巨大的工程，需要专业的安全团队来做。Composer项目组如果自己来做这个，无疑会分散其核心开发精力。目前我们依赖的
friendsofphp/security-advisories
等，都是由专门的社区或公司在维护。灵活性和选择权： 用户可能对安全检查有不同的需求和偏好。有的团队可能更信任某个特定的漏洞数据库，或者需要集成到特定的安全平台。将扫描功能外置，可以给用户选择最适合自己的工具和数据库的自由。性能考量： 每次运行Composer命令都进行一次全面的安全扫描，可能会显著增加执行时间，影响开发效率。将它作为可选的、独立的步骤，可以更好地平衡性能和安全性。
所以，与其说Composer“不能”做，不如说它“选择不直接做”，而是通过开放的生态系统，让专业工具来搞定这块。这种设计思路，我觉得挺合理的。
Roave/SecurityAdvisories 是如何工作的，以及它的局限性？
Roave/SecurityAdvisories
这个包，说白了，它利用了Composer自身的一个特性：
replace
。当你在
composer.json
中定义
"replace": {"package/name": "version"}
时，Composer会认为
package/name
这个包的
version
版本已经被你的项目“替换”了，因此在解析依赖时，就不会尝试去安装它。
Roave/SecurityAdvisories
就是利用这个机制。它本身并不包含漏洞数据库，而是动态生成一个巨大的
replace
列表，这个列表里包含了所有已知有漏洞的包及其版本。当你
composer update
时，这个
replace
列表就会生效。如果你的项目依赖了其中任何一个有漏洞的版本，Composer就会因为“冲突”而报错，因为它被告知这个版本已经被“替换”了，不能安装。
优点：
预防性强： 它能在你引入新依赖或更新现有依赖时，第一时间阻止你安装已知有漏洞的版本，将风险扼杀在摇篮里。集成度高： 作为Composer包，它能无缝集成到你的
composer update
流程中，无需额外命令。
局限性：
只防“新”不防“旧”： 如果你的
composer.lock
文件已经存在，并且其中包含了在
Roave/SecurityAdvisories
安装之后才被发现漏洞的包版本，那么它不会主动提醒你。它只在
composer update
或
composer install
（当
lock
文件不存在或过期时）时起作用。可能导致依赖冲突： 如果你的项目必须依赖某个有漏洞的包版本（比如为了兼容性，或者没有可用的升级路径），
Roave/SecurityAdvisories
会阻止你安装，这可能会让你陷入两难境地。虽然你可以临时禁用它，但这会增加风险。依赖数据库更新： 它的有效性高度依赖于
friendsofphp/security-advisories
数据库的更新速度和覆盖范围。不是审计工具： 它不是一个告诉你“你现在有什么漏洞”的工具，而是一个“阻止你引入新漏洞”的工具。
所以，我个人倾向于把它看作是项目安全的第一道防线，非常重要，但绝不是唯一的防线。
如何在CI/CD流程中自动化依赖安全检查？
在现代软件开发中，CI/CD（持续集成/持续部署）流程是确保代码质量和安全的关键环节。将依赖安全检查自动化集成到CI/CD中，可以确保每次代码提交、合并或部署前，都能对潜在的安全风险进行扫描。
核心思路： 在CI/CD管道的某个阶段（通常是构建或测试阶段）运行一个安全检查工具，并根据检查结果决定是否继续后续流程。
具体步骤和建议：
选择合适的工具：
Enlightn/SecurityChecker
： 这是我推荐的Composer生态中的首选。它轻量、快速，并且直接扫描
composer.lock
。Snyk、GitHub Dependabot、GitLab Security Scanning： 这些是更全面的第三方安全平台或CI/CD内置功能，它们不仅扫描依赖，还可能扫描代码中的其他漏洞。如果你的项目规模较大，可以考虑这些更专业的解决方案。不过，这里我们主要聚焦Composer依赖。
集成到CI/CD脚本：以
Enlightn/SecurityChecker
为例，你需要在CI/CD脚本中添加如下命令：
# 示例：GitHub Actions 或 GitLab CI/CD 中的步骤- name: Install Composer dependencies run: composer install --prefer-dist --no-progress --no-suggest- name: Install Security Checker run: composer require --dev enlightn/security-checker- name: Run Security Check run: ./vendor/bin/security-checker security:check composer.lock --format=json --output=security_report.json # --format=json 和 --output 可以让你将结果输出为文件，方便后续处理或上传到报告系统 # 默认情况下，如果发现漏洞，security-checker 会以非零退出码退出，导致CI失败
配置CI/CD失败策略：这是最关键的一步。当
security-checker
发现漏洞时，它通常会返回一个非零的退出码。你的CI/CD系统应该被配置为，一旦任何一个命令返回非零退出码，就立即终止当前管道，并将构建标记为失败。这能确保有漏洞的代码不会被部署到生产环境。
漏洞报告与通知：
输出格式：
security-checker
支持多种输出格式（如
text
、
json
、
html
）。在CI中，
json
格式通常最方便机器解析。集成通知： 可以编写脚本解析
json
报告，如果发现高危漏洞，通过Slack、邮件或Jira等工具通知开发团队。可视化： 一些CI/CD平台（如GitLab）可以直接解析安全扫描报告并以可视化的方式展示在MR/PR页面。
处理误报与例外：
忽略规则： 某些漏洞可能只影响特定的环境（例如，仅影响Windows服务器，而你的部署是Linux），或者你已经通过其他方式进行了缓解。大多数安全检查工具都支持配置忽略规则，让你可以在
composer.json
或单独的配置文件中标记某些漏洞为“已忽略”。但要非常谨慎地使用此功能。版本锁定： 一旦发现漏洞并升级了依赖，务必提交
composer.lock
文件，确保CI/CD和所有开发者的环境都使用相同的、已修复的版本。
在我看来，自动化安全检查不仅仅是一个技术步骤，更是一种文化。它强制团队在早期阶段就关注安全问题，而不是等到生产环境出事才去救火。这比任何事后补救都有效得多。
以上就是composer如何检查依赖中的安全漏洞的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/156682.html
微信扫一扫 
支付宝扫一扫 
