赋能DevOps流：结合Composer与自动化工具生成依赖物料清单

赋能DevOps流：结合Composer与自动化工具生成依赖物料清单

给composer项目生成一份真正有用的SBOM（软件物料清单），可不是“装个插件就完事”那么简单。关键在于，这份清单得能被后续的安全扫描、合规审计和依赖溯源流程真正用起来。如果只是在本地跑一句composer show --format=json，得到的不过是个孤立的快照——既没有许可证信息，也看不到嵌套依赖的完整路径，更缺少构建上下文。这样的文件，很难集成到现代化的CI/CD流水线里发挥作用。

为什么不能只靠 composer show 导出 JSON

问题出在信息缺失上。composer show命令通常只列出在composer.json里顶层声明的包及其直接版本。这样一来，require-dev里的那些工具链依赖（比如phpunit、phpstan）就被漏掉了。更重要的是，它不会去解析vendor/目录下实际安装的复杂结构，那些传递依赖（例如monolog依赖psr/log，后者又依赖psr/container）的完整链条也就无从知晓。

输出的JSON里，既找不到关键的许可证字段，也没有组件的哈希值或来源仓库URL。像Microsoft Defender for Cloud或OWASP DependencyTrack这类安全工具，拿到这样的输入，基本等于无效。这里有几个典型的痛点：

• 实际运行时加载的组件，并不完全等于composer.json里声明的组件。
• 缺少vendor/autoload.php的加载顺序信息，导致无法映射到运行时的真实类路径。
• 其JSON输出没有遵循标准schema，无法被主流的CycloneDX解析器识别和处理。

用 syft 扫描 vendor/ 目录生成合规 SBOM

那么，正确的路径是什么？答案是使用专业的SBOM生成工具，比如syft。作为CNCF的孵化项目，syft原生就支持PHP Composer的项目结构。它能递归扫描vendor/目录，精准提取出所有已安装包的名称、版本、许可证、PURL（包URL）以及SHA256哈希值，并输出为CycloneDX或SPDX这类行业标准格式——这才是安全工具能真正“读懂”并利用的基础。

不过，操作上有些细节必须注意：

• 时机是关键：必须在执行composer install --no-dev之后运行syft。否则，开发依赖会混入SBOM，污染面向生产环境的物料清单。
• 命令有讲究：推荐使用syft php:./ --output cyclonedx-json=sbom.cdx.json --file-type json。这里的php:前缀至关重要，它强制指定了解析器，避免syft误将composer.lock识别为其他语言（如Ruby）的依赖文件。
• 范围要精准：不要扫描整个项目根目录，目标应锁定在vendor/。
• 流水线集成：如果在Azure Pipelines中使用，需确保在UsePhp@1任务后立即运行syft，避免因为缓存机制导致vendor/目录缺失。

在 GitHub Actions 中自动附加 SBOM 到 Release

生成SBOM文件只是第一步，更重要的是让它与具体的制品绑定。否则，没人能说清哪个打包好的.phar或.zip文件对应哪一份依赖清单。将SBOM附加到GitHub Release上，是目前最轻量且有效的绑定方式，外部工具也能直接通过URL拉取。

在GitHub Actions中实现自动化，可以遵循以下步骤：

• 顺序不能错：在composer install和项目打包步骤之后，再插入syft生成SBOM的步骤，确保vendor/目录已完全就绪。
• 上传与命名：使用actions/upload-release-asset@v1动作，将生成的sbom.cdx.json作为资源上传。文件名建议包含Git commit SHA，例如sbom-cyclonedx-abc123.json，以实现精准追溯。
• 避开陷阱：尽量避免使用Actions的artifact功能来存储SBOM，因为它不对外提供直接的访问URL，像DependencyTrack这样的工具就无法通过webhook自动拉取。
• 容器场景：如果项目最终发布的是Docker镜像，方法更简单：直接运行syft your-image-name来扫描镜像层。这比先将镜像docker sa ve再解压扫描要可靠得多。

说到底，真正的难点从来不是生成一个JSON文件，而是确保每一份SBOM都携带完整的上下文：它对应着哪个Git提交、属于哪一次构建、是否排除了开发依赖、有没有启用平台检查。丢掉了这些元数据，SBOM就只是一个孤立的、静态的JSON文件，其价值将大打折扣。