OpenSSF GUAC 怎样串联软件供应链关系

很多团队已经能生成 SBOM，却仍然回答不了“这个镜像来自哪个构建”“某个包被哪些服务使用”“一条漏洞公告会影响哪些制品”。OpenSSF GUAC 的定位正是把分散的软件安全元数据聚合成可查询的关系图，而不是再生成一份孤立清单。

官方地址：https://guac.sh/

它的接入思路可以概括为：先收集 SBOM、SLSA、in-toto、VEX、OSV 等材料，再统一软件实体的身份，最后让包、二进制、镜像、漏洞和证明之间形成可查询关系。下面按这个链路拆开说明。

先把基线从“文件数量”换成“可回答的问题”

判断供应链数据是否真正有用，不能只统计导入了多少份 SBOM。更实际的基线是列出三类问题，并记录每类问题能否得到完整路径：

• 来源问题：一个生产镜像能否追溯到包、源码仓库或构建证明？
• 影响问题：某个依赖或漏洞出现时，能否找出受影响的应用、镜像和部署对象？
• 合规问题：目标制品是否有 SBOM、来源证明或组织要求的其他材料？

这三个问题对应“输入覆盖率、关系完整度、查询可用性”三个可持续观察的指标。若只导入 SBOM 而没有稳定的制品标识，文件数量会上升，关系完整度却不会同步上升。

GUAC 如何把分散材料串成关系

第一层是收集。官方仓库列出的输入包括 SPDX、CycloneDX、SLSA、in-toto、OSV、OpenVEX、CSAF/VEX、OpenSSF Scorecard 以及 deps.dev 等。它们提供的不是同一种信息：SBOM 更像“由哪些组件组成”，SLSA 或 in-toto 更偏向“怎样产生”，OSV 和 VEX 则帮助描述风险与影响状态。

第二层是身份对齐。GUAC 会把材料中的软件包、文件、镜像和构建对象抽取成实体，再根据软件标识标准建立关系。这里的关键不是把所有文本字段拼接起来，而是让同一个对象在不同材料中尽量拥有稳定的身份，这样“包属于镜像”和“镜像来自构建”才能落在同一张图上。

第三层是丰富。项目资料说明，GUAC 可以继续接入可信服务，为已有关系补充依赖、许可证、漏洞、生命周期或 Scorecard 等信息。查询层面对外提供统一的 GraphQL 接口，后端替换时客户端不必跟着改变。

按四个环节设计一次可落地接入

1. 盘点对象：先列出组织真正关心的应用、包、二进制和容器镜像，并为每类对象确定主标识。
2. 接入材料：优先导入已有的 SPDX 或 CycloneDX SBOM，再补充构建证明、VEX 和漏洞来源；不要把缺少来源的空字段当成已完成的证明。
3. 检查关系：围绕“包—二进制—镜像—应用”画出最小关系链，确认不同来源的数据是否落到了同一个实体上。
4. 设计查询：把补丁影响面、缺少 SBOM 的制品、无来源证明的生产对象等问题写成固定查询，并记录返回路径是否完整。

如果只是试用，可以从项目文档提供的 quickstart 开始；如果要长期保存关系，则要同时考虑后端类型和数据保留策略。官方仓库将 keyvalue 说明为非持久的内存后端，将 ent 与 PostgreSQL 说明为受支持的持久化组合。选型时应先匹配数据生命周期，再讨论查询规模。

边界：它能关联什么，不能替你保证什么

GUAC 的价值是把元数据组织成可追踪的上下文，因此它不能替代上游材料的生成，也不能自动证明材料本身真实无误。仓库特别提醒：软件标识并不总是完整，导入时可能需要启发式关联，因此会存在未处理的边界情况和数据质量问题。

还要把“有关系”与“有结论”分开。图中出现某个漏洞与镜像的关联，只代表当前材料支持这条关系；是否实际可利用、是否已经被 VEX 排除、应采取哪种修复动作，仍要结合原始证明和组织流程判断。GUAC 可以帮助缩短排查路径，但不会替团队完成风险决策。

常见问题

GUAC 是不是 SBOM 生成器？

不是。它更接近 SBOM、构建证明、漏洞和许可证等元数据的聚合与查询层，输入材料仍需要由构建、发布或扫描流程产生。

只有一份 SBOM 能不能建立完整关系？

通常只能建立部分组成关系。若要回答来源、影响面或合规问题，还需要稳定标识、构建证明以及相应的漏洞或 VEX 数据。

GUAC 能否直接替代安全审查？

不能。它提供关系和查询能力，帮助团队发现缺口、定位影响范围和组织证据；最终的风险判断、审批和修复仍由团队负责。

总结来看，GUAC 串联软件供应链关系的关键不是“把资料集中存起来”，而是让不同来源的材料围绕同一组软件实体形成可追踪路径。先定义要回答的问题，再补齐输入和标识，最后用固定查询观察关系完整度，接入才会从文件归档变成可行动的供应链视图。