开源中国正式成为 OpenChain 合作伙伴计划成员，这件事的意义不只是"又一家组织加入了某个国际计划"。OpenChain 是 Linux Foundation 旗下的软件供应链安全与合规标准组织，其核心产出——ISO/IEC 5230（开源许可证合规）和 ISO/IEC 18974（开源安全保证）——已经是全球主流企业采购和交付软件时的硬性参考。开源中国的加入，意味着国内的开源合规实践有了对接国际标准的正式通道，对日常需要处理许可证合规、SBOM 生成、安全漏洞溯源的开发者和团队来说，标准趋同会直接降低跨区域协作的摩擦。
OpenChain 在管什么
OpenChain 不是又一个漏洞数据库或扫描工具，它管的是流程标准。具体来说有两块：
- ISO/IEC 5230：定义了企业如何建立开源许可证合规流程——从引入组件时的许可证识别、记录，到发布前的审查和声明，要求可追溯、可审计。
- ISO/IEC 18974：定义了开源安全保证流程——要求企业对所使用的开源组件进行安全评估、漏洞响应和披露，形成闭环。
这两项标准已经从社区规范升级为 ISO 国际标准。企业如果声称自己"OpenChain 合规"，意味着它有一套可验证的流程，而不是口头承诺。
国内标准与国际标准的对接点
国内在开源供应链安全方面已有实践基础，比如信通院牵头的一系列合规指南和评估体系。但问题在于：国内标准和 ISO/IEC 5230/18974 在术语、流程节点、证据格式上存在差异，导致国内企业在向海外客户交付软件时，合规证据不被直接认可。
开源中国作为 OpenChain 合作伙伴，可以参与标准文本的审阅和本地化映射，推动两边术语和流程节点的对齐。对开发者来说，最直接的好处是：以后用同一套 SBOM 和合规证据，既能满足国内评估，也能通过国际审计。
实践：生成 SPDX 格式 SBOM 并做许可证提取
OpenChain 合规流程的第一步是"知道你用了什么、用了什么许可证"。SPDX（Software Package Data Exchange）是 OpenChain 推荐的 SBOM 标准格式。下面用两个开源工具演示一条可落地的流水线：用 Syft 扫描项目生成 SPDX SBOM，再用 FOSSology 提取许可证信息。
1. 用 Syft 生成 SPDX JSON 格式 SBOM
Syft 是 Anchore 开源的容器和文件系统 SBOM 生成工具，支持 SPDX JSON 输出。
# 安装 Syft（macOS / Linux）
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# 对当前项目目录扫描，输出 SPDX JSON 格式 SBOM
syft dir ./my-project -o spdx-json > sbom-spdx.json
# 如果是容器镜像，直接扫描镜像
syft registry.example.com/my-app:v1.2.0 -o spdx-json > sbom-spdx.json
生成的 sbom-spdx.json 包含每个组件的名称、版本、下载位置、许可证声明（licenseConcluded 和 licenseDeclared）等字段，正是 ISO/IEC 5230 要求的合规证据核心。
2. 用 FOSSology 做许可证深度识别与审计
Syft 能提取包元数据里的许可证声明，但源码中的实际许可证可能与声明不一致。FOSSology 可以扫描源码文本，做许可证关键词匹配和对比。
# 用 Docker 快速启动 FOSSology 服务
docker run -d --name fossology \
-p 8081:80 \
-v fossology-data:/var/lib/fossology \
fossology/fossology:latest
# 等服务就绪后，通过 API 上传源码包进行扫描
curl -X POST "http://localhost:8081/api/v1/uploads" \
-H "Authorization: Bearer YOUR_TOKEN" \
-F "fileInput=@my-project.tar.gz" \
-F "folderId=1"
# 上传成功后，触发许可证扫描
curl -X POST "http://localhost:8081/api/v1/uploads/{uploadId}/scans" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"scanType": "license"}'
YOUR_TOKEN需要先登录 FOSSology Web 界面（http://localhost:8081）在用户设置中生成。首次登录默认账号 admin / fossology。
FOSSology 扫描完成后，会输出每个文件匹配到的许可证标识，与 SPDX License List 对应。你可以将 FOSSology 的结论回填到 SBOM 的 licenseConcluded 字段，形成完整的合规证据链。
3. 一条最小合规检查脚本
把 Syft 输出和 FOSSology 结论结合起来，可以用脚本快速检查是否有许可证冲突：
#!/usr/bin/env python3
"""最小化 SPDX SBOM 许可证冲突检查脚本"""
import json
import sys
# 定义不允许出现在产品中的许可证（根据企业策略调整）
BLOCKED_LICENSES = {"AGPL-3.0-only", "AGPL-3.0-or-later", "GPL-3.0-only", "GPL-3.0-or-later"}
def check_sbom(sbom_path: str) -> list:
with open(sbom_path) as f:
sbom = json.load(f)
conflicts = []
for pkg in sbom.get("packages", []):
name = pkg.get("name", "unknown")
concluded = pkg.get("licenseConcluded", "NOASSERTION")
declared = pkg.get("licenseDeclared", "NOASSERTION")
# 检查已确认许可证是否在黑名单中
if concluded in BLOCKED_LICENSES:
conflicts.append(f"❌ {name}: licenseConcluded={concluded} (blocked)")
# 如果未确认，但声明了黑名单许可证，标记为风险
elif concluded == "NOASSERTION" and declared in BLOCKED_LICENSES:
conflicts.append(f"⚠️ {name}: licenseDeclared={declared}, not yet concluded")
return conflicts
if __name__ == "__main__":
path = sys.argv[1] if len(sys.argv) > 1 else "sbom-spdx.json"
results = check_sbom(path)
if results:
print("许可证冲突/风险：")
for r in results:
print(r)
else:
print("✅ 未发现许可证冲突")
# 运行检查
python3 check_licenses.py sbom-spdx.json
这段脚本做的事情很简单：读 SPDX SBOM，对比企业许可证策略，输出冲突和风险项。它不是什么高级工具，但恰好是 ISO/IEC 5230 要求的"合规流程有可执行步骤"的最小实现。
开发者和团队现在可以做什么
标准对接是组织层面的事，但合规和安全证据的生产是工程层面的活。几条建议：
- 尽早生成 SBOM：不要等到交付前才扫描。在 CI 中集成 Syft 或类似工具，每次构建自动产出 SPDX SBOM，积累历史记录。
- 许可证策略要写下来：上面脚本里的
BLOCKED_LICENSES不应该是开发者的个人判断，而应该是组织明文规定的策略文档。ISO/IEC 5230 要求的就是这份策略的可追溯性。 - 关注 SPDX 和 ISO/IEC 18974 的安全字段：SPDX 2.3 已经加入了安全引用字段（如
externalReference指向漏洞数据库），后续版本会进一步强化。生成 SBOM 时保留这些字段，为安全合规流程留好接口。 - 国内项目优先用 SPDX 格式：如果你现在还在用自定义格式记录组件清单，切换到 SPDX。这是 OpenChain 推荐格式，也是国内标准正在对齐的方向，一份 SBOM 同时满足两边要求。
开源中国加入 OpenChain 是标准对接的起点，不是终点。对接完成之前，开发者能做的最有价值的事，就是让自己的项目产出结构化的合规证据——SBOM 和许可证审计记录。等标准对齐落地时，你不需要回头补债。