PHP 怎么PHP 依赖安全

本文目录导读：

1. 核心工具：composer audit（PHP >= 8.0，推荐）
2. 持续监控平台：GitHub Dependabot / GitLab Dependency Scan
3. 锁定版本与哈希校验：composer.lock 与 composer verify
4. 代码级安全：审查 vendor 目录的恶意包
5. 版本策略：composer bump 与语义化版本
6. 一套完整的安全流程

在 PHP 生态中，“依赖安全”主要指的是管理第三方包（Composer 包）时，避免引入已知漏洞、恶意代码或过时不再维护的库。

由于 PHP 项目通常重度依赖 Packagist 上的开源包（如 Laravel, Symfony, Guzzle 等）,依赖安全是生产环境运维的关键环节。

以下是实现 PHP 依赖安全的 5 个核心策略及具体工具：

核心工具：composer audit（PHP >= 8.0，推荐）

从 Composer 2.4 开始，内置了漏洞扫描功能，这是最直接、免费且全局集成的方案。

如何使用：

# 1. 运行一次扫描（检查当前 composer.lock）
composer audit
# 2. 如果发现漏洞，你会看到类似输出：
# Found 1 security vulnerability in 1 package:
#   Package: guzzlehttp/guzzle
#   Version: 6.5.5
#   CVE: CVE-2022-29248 Change in CurlMultiHandler allows POST request body injection
#   URL: https://github.com/advisories/GHSA-cwmx-hjrq-48ff

最佳实践：

• 集成到 CI/CD 流水线中，一旦检测到漏洞，阻断构建（composer audit --format=json | grep "vulnerabilities" 判断退出码）。
• 搭配 composer update --lock 或 composer bump 更新到安全版本。

持续监控平台：GitHub Dependabot / GitLab Dependency Scan

分布式团队或大型项目需要持续监控,而不是手动运行命令。

• Dependabot（GitHub）：
  • 在仓库的 Security -> Dependabot alerts 启用。
  • 会自动检测 composer.lock 中的漏洞，并自动创建 PR 升级到修复版本。
  • 配置文件 .github/dependabot.yml：

    version: 2
    updates:
      - package-ecosystem: "composer"
        directory: "/"
        schedule:
          interval: "weekly"
          day: "monday"
        open-pull-requests-limit: 10

• GitLab Dependency Scan：
  • 启用 CI Job，使用 gemnasium 或 trivy 扫描器,官方文档有现成模板。

锁定版本与哈希校验：composer.lock 与 composer verify

不要依赖 require 中的模糊版本（如 ^1.0），必须提交 composer.lock 到版本控制。 这是安全基线：

• composer.lock 记录了确切版本和内容哈希。
• 部署时安装 composer install --no-dev 会锁定版本，避免生产环境意外拉取到带有 bug 或漏洞的补丁版本。
• composer verify 可以验证 lock 文件是否被篡改。
• 使用 composer install --prefer-dist --no-dev --classmap-authoritative 提高性能和安全性。

代码级安全：审查 vendor 目录的恶意包

现代攻击不仅限于已知 CVE，还包括依赖混淆（Dependency Confusion） 或后门植入。

防范措施：

• 使用权威源： 配置 composer.json 的 repositories 优先指向官方 Packagist 或私有可信源,避免解析到恶意同名包。
• 配置安全代理： 对于企业，推荐使用 Satis 或 Toran Proxy 作为中介缓存,扫描拉取的所有包。
• 定期更换密钥： 如果使用私有包，确保 auth.json 中的 API Token 权限最小化,并定期轮换。
• 代码审计脚本： 在 CI/CD 中，对 /vendor 目录运行 grep -r "eval(" ./\* 或 base64_decode 等可疑函数扫描（虽然误报多，但有必要）。

版本策略：composer bump 与语义化版本

不要放任 composer update 升级所有依赖，尤其是次要/补丁版本：

# 安全更新：只升级有安全修复的包，保持其他不变
composer update vendor/package:1.2.3 --lock
# 使用 composer bump 更新所有包到允许的最新版本（但保持语义约束）
composer bump --dev-only

版本约束建议： 对于核心安全敏感的包（如 php, laminas/laminas-diactoros），情愿使用 >=1.2 <1.3 的严格范围，也不要用 ^1.2。

一套完整的安全流程

一个最容易被忽视的点： 不要直接把 vendor/ 目录提交到 Git 仓库，只提交 composer.lock，版本控制中的 vendor 会引入扩展包的攻击面，且无法通过 composer audit 准确扫描。