软件物料清单 SBOM怎样把依赖清单绑定到构建产物怎样在批处理代码中减少额外分配

构建流水线里最容易让 SBOM “对不上”的地方，不是 SPDX 或 CycloneDX 文件格式，而是关联键选错了：如果只把 SBOM 写到 app:latest 旁边，标签移动后就无法说明它对应哪一个真实产物。更稳妥的做法是以最终 OCI manifest 的不可变 digest 作为 subject，再把 SBOM 文件的 SHA-256 摘要写进 attestation。批量生成组件记录时，Go 代码则用一次性容量规划和可复用缓冲区减少无谓的扩容。

先锁定“哪个产物”，再记录“哪一份 SBOM”，最后才谈签名和性能；标签只能用于查找，不能作为唯一绑定依据。

官方地址：https://spdx.dev/use/specifications/

官方地址：https://docs.sigstore.dev/cosign/signing/other_types/

官方地址：https://github.com/opencontainers/image-spec/blob/main/descriptor.md

本文解决三件事：用 digest 锁定构建产物；用 predicate 记录 SBOM 摘要；在批处理代码中降低重复分配。示例是静态说明，不代表已经在本机执行过。

先确认你绑定的对象不是标签

排查从一条记录开始：构建结束后，你手里至少有镜像引用、最终 manifest digest、SBOM 文件和 SBOM 文件摘要。OCI 描述符用内容地址标识对象，摘要可以独立重算；而 latest 这类标签只是一个可移动的名字。两者混在一起时，SBOM 可能仍然“存在”，却已经不再对应当前下载到的镜像。

因此，构建记录建议至少保留下面四个字段：

多架构镜像还要注意 digest 层级：索引 digest 和某个平台 manifest digest 不是同一个对象。发布清单应明确自己 attestation 绑定的是索引还是某个平台产物，不能只抄一段日志里的短引用。

为什么 SBOM 会看起来“对应成功”却查不到原产物

常见误区是把文件名、标签或构建流水线编号当成唯一键。它们适合做检索字段，却无法单独证明内容没有变化。另一个误区是只把 SBOM 路径放进自定义 predicate，而没有同时记录 SBOM 摘要；路径不变并不等于文件内容不变。

在 SPDX 模型里，文档可以表达包、文件以及它们之间的关系；它描述的是软件组成与关系，不会自动替你选择某个镜像版本。因此，SBOM 生成工具的输出应先固定，再把输出摘要作为 predicate 数据。把“SBOM 文档内容”和“它描述的最终产物”分成两个可独立核对的对象，排错会清楚很多。

{
  "image_ref": "registry.example.com/team/app:release",
  "sbom_uri": "oci://registry.example.com/team/app-sbom:release",
  "sbom_sha256": "7e1f...示例摘要...9a2c",
  "format": "spdx-json"
}

上面的 JSON 是自定义 predicate 的内容示意，字段名不是 SPDX 标准字段。关键点是它把镜像的不可变 subject 交给 attestation 外层，把 SBOM 的位置和摘要放进 predicate；消费端可以分别处理两种身份。

在批处理里减少额外分配

如果流水线一次整理几千个依赖，最直观的浪费通常来自两处：组件切片不断增长，以及 JSON 编码器背后的输出缓冲区反复扩容。下面的例子只展示内存组织方式，不负责生成完整 SPDX 文档，也不提供未经基准测试的性能数字。

package sbom

import (
    "bytes"
    "encoding/json"
)

type Module struct {
    Path    string
    Version string
}

type Component struct {
    Name    string `json:"name"`
    Version string `json:"version"`
}

type Document struct {
    Components []Component `json:"components"`
}

func buildDocument(mods []Module) ([]byte, error) {
    // 按输入数量一次性预留切片容量，减少 append 触发的扩容搬迁。
    components := make([]Component, 0, len(mods))
    for _, mod := range mods {
        // 只复制 SBOM 需要的字段，避免把整个依赖对象带入文档。
        components = append(components, Component{
            Name:    mod.Path,
            Version: mod.Version,
        })
    }

    // 预留一个近似容量；实际占用仍取决于名称和版本长度。
    var buf bytes.Buffer
    buf.Grow(128 + len(components)*96)
    enc := json.NewEncoder(&buf)
    if err := enc.Encode(Document{Components: components}); err != nil {
        // 序列化失败时把错误交给上层，不能发布不完整的 SBOM。
        return nil, err
    }
    return buf.Bytes(), nil
}

这里的收益是减少切片和缓冲区的重复扩容，不是让所有 SBOM 生成都“零分配”。如果组件名称长度差异很大，Grow 的估算应通过基准测试调整；如果后续还要计算摘要，尽量在同一个确定的字节切片上完成，避免先转字符串再转回字节。

用最终 digest 写入并复查 attestation

签名或 attestation 的命令行操作应始终指向同一个最终 digest。SBOM 可以作为独立 OCI 对象保存，也可以作为构建产物旁的文件保存；无论哪种方式，predicate 中的摘要都要对应那一份固定内容。

# 使用最终 manifest digest，避免标签移动造成绑定漂移。
IMAGE='registry.example.com/team/app@sha256:0123456789abcdef...'

# 计算 SBOM 内容摘要，供 predicate 和消费端重复比对。
SBOM_SHA256="$(shasum -a 256 sbom.spdx.json | awk '{print $1}')"
printf '%s\n' "${SBOM_SHA256}"

# 对同一个 digest 附加自定义 predicate；不要改回可移动 tag。
cosign attest --type custom --predicate sbom.predicate.json "${IMAGE}"

# 读取该 digest 的 attestation，检查签名和 subject 是否指向同一产物。
cosign verify-attestation "${IMAGE}"

Cosign 文档给出了对容器镜像附加自定义 predicate 以及验证 attestation 的用法。生产环境还要把信任根、证书身份或公钥策略写进自己的验证配置；命令返回成功只代表签名链路通过，不能替代对 SBOM 摘要和业务策略的核对。

复查时按三处身份对齐

遇到“SBOM 找不到”“依赖列表和镜像不一致”或“批处理变慢”，按下面顺序看，通常能快速区分是绑定问题还是分配问题：

1. 产物身份：attestation 的 subject digest 是否等于部署或下载对象的 digest，而不是同名标签解析出的另一个对象。
2. 内容身份：重新取得 SBOM 后计算的摘要是否等于 predicate 里的 sbom_sha256；不一致先处理制品替换、缓存或上传路径。
3. 证明身份：签名验证是否使用了预期的身份和信任策略；通过签名不代表 SBOM 内容自动可信。
4. 内存现象：只有在分配次数、GC 时间或吞吐基准出现变化时，才调整切片容量估算或缓冲区复用，别把一次观测写成固定比例。

最终可以把镜像标签保留在展示和检索层，把 digest 放在 attestation 和部署记录层；这样既方便人查找，也不会把可变名称误当成证据。

相关问题

SBOM 一定要嵌入镜像吗？

不一定。它可以作为独立制品保存，再用 attestation 或其他签名关系绑定到镜像 digest。选择时主要看制品库、部署平台和离线消费端是否方便同时取到两者。

为什么预分配后仍然可能有很多分配？

组件字段中的字符串、JSON 编码、哈希输入和上层对象复制都可能产生分配。预分配只减少切片增长这一类成本，是否值得进一步复用缓冲区，应结合基准测试和实际 GC 数据判断。