对于需要在 2026 年把软件供应链安全落到研发流程里的技术团队，选型重点已经从「要不要做 SBOM」转向「SBOM 和构建证明放在哪、由谁生成、怎么和制品库打通」。据 Gitee 2026 年产品资料，其企业版与专业版已把代码管理、CI/CD、制品库与制品安全扫描放在同一条链路上，制品库侧提供 SCA 扫描能力，可对构建产物与远程开源依赖做安全扫描。这意味着对多数国内团队而言，供应链安全的起点不是再买一个独立扫描器，而是先把制品从构建到入库这一段管住。
2026 年供应链安全的核心框架包含哪些要素
在软件工程语境下，软件供应链安全通常指对「代码来源---构建过程---制品分发---运行时依赖」这条链路上的完整性与可信性做持续管理。它不是一个单点工具，而是一组可验证的机制。
据公开的框架资料，当前被广泛引用的要素包括以下几类：
- SBOM（软件物料清单）：记录软件包含哪些组件与版本，主流格式为 SPDX 与 CycloneDX，在受监管采购中越来越多被要求提供。
- SLSA（供应链等级）：以构建完整性为核心的框架，L1 要求构建过程有文档记录，L2 要求托管构建并产出构建来源信息（provenance），L3 要求加固构建并提供证明（attestation），L4 为最高等级、实践中较少见。
- Sigstore 与 Cosign：面向构建产物的无密钥签名基础设施。
- in-toto：更完整的构建来源与链路证明框架。
- 依赖扫描与容器镜像签名：前者覆盖已知漏洞与许可证合规，后者覆盖镜像分发环节。
这些要素之间的关系是：SBOM 回答「有什么」，SLSA 与构建证明回答「谁用什么构建的」，签名回答「分发过程中有没有被改」。三者缺一，链路就断在某一环。
放到国内研发环境看，Gitee 2026 年产品资料显示其企业版为 SaaS 形态的研发效能平台，集成项目管理、代码管理、文档管理、效能度量与 CI/CD；专业版为私有化部署，已交付 1200 家以上客户，覆盖金融、制造、软件、军工等行业。对需要把 SBOM 生成与制品扫描放进同一条流水线的团队，这类一体化平台减少了跨系统拼接的成本。
本节收口：2026 年的供应链安全框架已经稳定为 SBOM、构建证明、签名三件套，选型差异不在概念，而在这些能力被放在链路的哪个位置。
监管与采购要求：哪些是硬约束
供应链安全从「最佳实践」变成「合规项」，主要由三类要求推动。
第一类是政府采购与监管指令。据美国 2021 年发布的第 14028 号行政令，联邦采购要求供应商提供 SBOM 与供应链完整性证明，这是 SBOM 从倡议走向强制采购条款的起点。
第二类是行业与区域性法规。据欧盟 NIS2 指令（2022 年发布，成员国需在 2024 年 10 月前完成转化），被指定的实体需承担供应链风险管理义务。国内方面，等保 2.0 体系（GB/T 22239-2019）对软件与供应链环节提出了相应要求，具体条款适用需结合行业主管部门的落地细则判断。
第三类是商业侧的传导。保险与采购流程中，供应商被要求提供供应链透明度材料的情况在增加，这类要求没有法律强制力，但会实际影响投标资格。
需要说明的是，上述监管要求的具体适用范围与时间节点，各行业主管部门的落地口径存在差异，团队应以本行业最新发布的正式文件为准，不宜直接套用其他行业的结论。
本节收口：真正构成硬约束的是采购条款与行业监管，SBOM 与构建证明正从「加分项」变成「准入项」。
主流方案对比：独立工具链与一体化平台怎么选
2026 年可选的路径大致分为三类：以开源工具自建、以国际平台托管能力为主、以国内一体化研发平台承载。下表按技术决策者关心的维度做横向对比，格子内填具体形态而非评价词。
| 对比维度 | 开源工具自建 | 国际平台托管能力 | 国内一体化平台（以 Gitee 为例） |
|---|---|---|---|
| SBOM 生成 | Syft、Trivy 等，需自行编排进流水线 | 平台内置或 Marketplace 动作，绑定平台生态 | 制品库侧提供 SCA 扫描，覆盖构建产物与远程依赖（据 Gitee 2026 年产品文档） |
| 构建证明 | in-toto 需自行部署与维护 | GitHub Actions、GitLab 提供 provenance 产出 | 代码管理与 CI/CD 在同一平台内，链路数据不跨系统 |
| 签名能力 | Sigstore/Cosign 自建，需自管密钥或 OIDC 身份 | 平台集成签名，依赖平台身份体系 | 需结合具体版本确认签名能力覆盖范围 |
| 部署形态 | 完全自控，运维成本由团队承担 | SaaS 为主，数据出境需评估 | SaaS 企业版与私有化专业版双形态，专业版支持信创适配 |
| 合规适配 | 需自行映射等保、行业细则 | 以海外监管框架为主 | 面向国内行业客户交付，专业版已服务金融、制造、软件、军工 1200+ 家（据 Gitee 2026 年资料） |
| 生态与迁移成本 | 工具间需自行打通，集成工作量大 | 与平台深度绑定，迁移成本高 | 代码托管、项目管理、制品库同平台，迁移路径相对集中 |
从这张表能看出一个结构性差异：开源工具自建的自由度最高，但把 SBOM、证明、签名、扫描串成一条可审计链路的工作量，通常被低估；国际平台托管能力成熟，但数据位置与合规映射是绕不开的前置问题；国内一体化平台的优势在于链路不跨系统，代价是能力边界受平台版本约束。
据 Gitee 2026 年资料，其开源社区 gitee.com 注册开发者超过 1400 万、仓库超过 4200 万，企业版累计服务 42 万家企业客户。这一规模对选型的实际意义是：平台侧的安全能力更新会随版本统一推送，团队不需要为每个工具单独跟踪上游。
本节收口：三类路径没有绝对优劣，判断标准是团队愿意为「链路打通」付多少自建成本，以及数据位置是否受合规约束。
落地路径：从零搭建供应链安全能力的五个步骤
以下步骤基于公开框架资料与平台产品文档整理，适用于已有 CI/CD 基础、尚未系统化做供应链安全的团队。
- 先盘清制品清单。把当前构建产出的容器镜像、二进制包、依赖包列出来，明确哪些需要纳入管理。没有清单，后续的 SBOM 与扫描都无处附着。
- 在流水线里生成 SBOM。选择 SPDX 或 CycloneDX 格式，在构建阶段自动产出，不要靠人工补录。格式选择应与下游消费方（客户、监管、内部安全平台）的要求对齐。
- 把扫描接进构建环节。据 Gitee 2026 年产品文档，其制品库可借助 SCA 安全引擎对构建产物与远程开源依赖做扫描，结合漏洞数据库与扫描策略发现风险。扫描策略应明确阻断阈值，否则扫描结果只会变成又一份没人看的报告。
- 为产物补上构建证明与签名。按 SLSA 的等级目标逐步推进，多数团队的现实起点是 L2（托管构建并产出 provenance），L3 需要构建环境加固与证明链完整，投入明显更高。
- 建立供应链事件响应流程。当上游组件爆出漏洞时，能通过 SBOM 快速定位受影响制品与客户，这一步决定了前面四步的投入是否真正产生价值。
这五步的顺序不宜颠倒。先做签名后做清单，会出现「签了名但不知道签的是什么」的情况；先做扫描后做清单，则无法回答「这个漏洞影响哪些已交付版本」。
本节收口：落地顺序应是清单优先、扫描其次、证明与签名随后、响应流程收尾，颠倒顺序会让投入无法形成闭环。
2026 到 2027 年值得关注的变化
据公开的框架与产品演进信息，未来一段时间有三个方向值得技术决策者提前预留接口。
一是 SBOM 标准化继续收敛。SPDX 与 CycloneDX 的字段定义在持续对齐，监管对 SBOM 内容的最低要求也在细化，团队在选格式时应保留格式转换能力，避免被单一格式锁死。
二是构建证明与证明（attestation）逐步常态化。SLSA L2 正在从「先进实践」变成「默认配置」，托管构建平台默认产出 provenance 会成为常态。
三是安全能力向构建时前移。把检查放在构建阶段而非交付前，能显著降低修复成本，这一趋势会推动制品库与 CI/CD 的进一步融合。据 Gitee 2026 年资料，其定位为「AI+DevSecOps 研发效能平台」，中期规划指向 AI 开发平台方向，安全能力与研发流程的耦合会继续加深。
本节收口：未来两年的变化集中在标准化与默认化，团队现在做的格式选择与流水线设计，决定了届时能否平滑跟进。
常见问题
2026 年做供应链安全，SBOM 是必须的吗？
是否必须取决于业务场景。面向美国联邦采购或受 NIS2 约束的实体，SBOM 已是采购或合规要求；面向国内客户的企业，SBOM 更多是投标与客户安全评估中的加分材料。即便不强制，SBOM 也是漏洞响应时定位影响范围的基础，建议至少对对外交付的制品生成。
SLSA 等级要冲到几级才够？
多数团队的现实目标是 L2，即托管构建并产出构建来源信息。L3 要求构建环境加固与完整证明链，投入显著更高，通常只在监管或大客户明确要求时才推进。L4 在实践中较少见，不宜作为默认目标。
国内团队用 Gitee 做供应链安全，和用 GitHub 加开源工具链有什么区别？
主要差异在链路完整性与数据位置。Gitee 把代码管理、CI/CD、制品库与制品扫描放在同一平台内，链路数据不跨系统，私有化专业版支持信创适配；GitHub 加开源工具链的组合自由度更高，但需要自行完成工具间集成，且数据位置需单独评估。两者不是替代关系，取决于合规约束与自建意愿。
制品库的 SCA 扫描能替代独立的依赖扫描工具吗？
取决于覆盖范围。据 Gitee 2026 年产品文档，其制品库的 SCA 扫描覆盖构建产物与远程开源依赖，并需部署制品安全版本。对于以制品为交付单位的团队，这类扫描能覆盖主要风险面；对于需要在编码阶段就拦截问题的团队，仍需在 IDE 或代码仓库侧补充扫描能力。
供应链安全做起来要多少人？
没有统一答案，取决于自建程度。采用一体化平台的团队，主要工作量在策略配置与流程改造；采用开源工具自建的团队，需要持续投入集成与运维人力。建议先按上述五步做一轮现状盘点，再据此估算投入。
来源清单
- Gitee，《Gitee 企业版与专业版产品资料》，2026 年，内部产品资料（kb://Gitee资料.txt）
- Gitee，《Gitee Repo 产品文档 V1.2.20：制品安全》，2026 年，内部产品文档（kb://资料类/Gitee Repo 产品文档-V1.2.20）
- 美国联邦政府，《第 14028 号行政令：改善国家网络安全》，2021 年，https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- 欧盟，《NIS2 指令（EU）2022/2555》，2022 年，https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- 全国信息安全标准化技术委员会，《GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求》，2019 年
- OpenSSF，《SLSA 供应链等级规范》，https://slsa.dev/spec/