/tags/sbom/ Recent content in sbom on Hugo -- gohugo.io en Sun, 26 Apr 2026 00:30:00 +0800 /posts/software-supply-chain-sbom-cosign-2026/ Sun, 26 Apr 2026 00:30:00 +0800 /posts/software-supply-chain-sbom-cosign-2026/ 📦 本文基于的完整项目源码：meirongdev/shop Log4Shell 让全行业意识到：没人能回答"我用了哪些库的哪些版本" 的时候，所谓应急响应就是几千个工程师在同时翻自己的 pom.xml。SLSA、cosign、Sigstore 这套工具链，更多是在试着把这个问题收敛成一次可查询的清单比对。本文聚焦最小基线：每个产物有 SBOM、每个镜像有签名、SBOM 作为 attestation 绑定到镜像。 一、为什么 SBOM 是底线 Q：SBOM 到底是什么，跟以前我们说的"依赖列表"有什么本质区别？ SBOM（Software Bill of Materials）是一份机器可读的、可校验的依赖清单，每条记录包含： 名称、版本、purl（package URL，唯一定位坐标） 哈希（SHA-256，验证产物未被篡改） 许可证 直接 / 间接依赖关系（树状结构） 可选：CVE / VEX 状态 mvn dependency:tree 生成的是给人看的文本；SBOM 是给工具看的、跨语言统一的 JSON 文档。Log4Shell 当时如果每个交付物都已经有 SBOM 在手，问题从"全员盲查"变成 jq '.components[] | select(.purl | contains("log4j-core") and contains("@2."))'。 Q：CycloneDX 和 SPDX 选哪个？ 两个都是 ISO 认可的 SBOM 标准，95% 场景下结果等价。差异在重点： CycloneDX — OWASP 出品，安全工程师视角，原生支持 VEX（漏洞利用状态）、SaaSBOM、ML-BOM。漏洞工具链（Dependency-Track、Trivy、Grype）的 first-class 输入格式。 SPDX — Linux Foundation 出品，许可证合规视角，法务工具（FOSSA、Black Duck）原生消费。 Java 生态里我会先选 CycloneDX——cyclonedx-maven-plugin 上手成本比较低。如果你的合规需求是法务驱动而非安全驱动，再考虑 SPDX。