制品管理并不只是保存 JAR 包、容器镜像或安装包，而是对软件从依赖引入、构建生成、安全检测、测试验证到生产发布的全过程进行管理。
在金融、政务、能源及其他对安全和可靠性要求较高的行业中，研发环境往往具有内外网隔离、供应商较多、技术栈复杂、审计要求严格等特点。
在这种情况下，制品能否统一存储、来源能否追溯、风险能否持续识别，以及版本能否受控晋级，会直接影响软件供应链的可见性和交付过程的稳定性。
Gitee Repo 是 Gitee DevSecOps 体系中的制品管理模块。根据 Gitee 当前公开的产品信息，Gitee Repo 主要围绕多类型制品存储、依赖代理、安全扫描、制品流转、构建追踪和跨节点同步等场景展开，可以作为企业建设统一制品管理体系的一种技术实现路径。
什么是软件制品
软件制品是软件研发过程中产生或使用的、可以保存和传递的对象，包括：
- Java、npm、Python 等语言依赖包；
- 容器镜像；
- 压缩包和安装包；
- 模型文件和数据集；
- 配置文件；
- 数据库升级脚本；
- 编译和构建产生的交付文件。
制品管理的对象并不只是文件本身，还包括与文件关联的版本、来源、依赖关系、构建记录、安全状态、审批记录和发布去向。
换句话说，企业不仅需要知道“这个文件在哪里”，还需要知道：
- 它是谁构建的；
- 使用了哪些依赖；
- 是否经过测试和扫描；
- 是否被允许进入生产环境；
- 当前有哪些系统正在使用；
- 出现问题后应该如何定位和回滚。
一、为什么关键行业更需要统一制品管理
很多团队已经部署了代码仓库和流水线，但如果制品仍然通过共享目录、即时通信工具或个人电脑传递，软件交付链路中仍然存在明显断点。
1. 依赖来源分散，难以掌握完整依赖链
现代应用很少完全从零开发。
一个业务系统通常会同时使用开源语言包、基础容器镜像、内部公共组件、数据库驱动和商业中间件客户端。直接依赖之下还可能包含多层传递依赖，因此，仅查看项目配置文件并不能完整反映软件实际包含的组件。
例如，一个业务系统可能包含以下几类依赖：
- 项目直接引用组件 A；
- 组件 A 又依赖组件 B 和组件 C；
- 项目还使用企业内部公共组件 D；
- 系统运行环境基于基础镜像 E。
即使研发人员没有主动选择组件 C，只要组件 C 被其他依赖间接引入，它所包含的漏洞或许可证限制仍可能进入最终制品。
因此，这类问题需要通过统一依赖代理、组件分析和软件物料清单进行治理，而不能只依靠研发人员手工登记。
2. 漏洞扫描结果具有时效性
一个制品在构建当天没有发现已知漏洞，并不意味着它之后始终安全。
随着新的 CVE、攻击情报和组件影响范围被披露，同一份已经进入制品库的软件包，其风险状态也可能发生变化。
因此，制品安全管理除了构建时扫描，还需要考虑：
- 对存量制品进行重新检测；
- 更新漏洞状态；
- 定位受影响的制品版本；
- 查找正在使用这些版本的项目；
- 通知相关维护人员；
- 跟踪漏洞整改进度。
OWASP 对软件组成分析的相关说明也指出，组件分析通常需要结合多个漏洞情报来源识别已知漏洞，并持续关注直接依赖和传递依赖的变化。
3. 许可证问题不能只看组件名称
开源许可证不能简单分为“安全”和“不安全”。
MIT、Apache-2.0、BSD、GPL、AGPL 等许可证具有不同的授权条件。一个许可证是否适合使用，需要结合软件的分发方式、修改情况、链接方式和组织内部的合规策略进行判断。
许可证治理通常需要完成三项工作：
- 识别软件中实际包含的组件及其许可证；
- 根据组织规则对许可证进行分类；
- 将高风险或需要人工确认的情况纳入审批流程。
SPDX 提供了用于表达软件组件、许可证及其关系的开放标准，同时维护标准化的许可证标识和表达方式，可以用于支持机器化的许可证识别与合规流程。
4. 测试制品和生产制品可能不是同一个文件
传统流程中经常出现一种情况：研发人员向测试团队提供一个软件包，测试通过以后，发布人员又根据同一分支重新构建一次。
虽然两次构建使用的代码可能相同，但依赖版本、基础镜像、构建参数和环境状态可能已经发生变化。
最终进入生产环境的软件包，不一定是测试团队真正验证过的软件包。
更稳妥的方式是：
- 流水线只构建一次正式候选制品；
- 测试、安全扫描和审批均围绕这一份制品进行；
- 验证通过后，将同一份制品晋级到发布区域；
- 生产环境直接部署已经通过验证的制品。
也就是说，制品应当在开发、测试和发布阶段之间受控晋级，而不是在每个环境中重复构建。
本节小结：
关键行业制品治理的主要问题并不是“有没有制品库”，而是依赖、风险、版本和流转过程能否围绕同一个制品建立关联。
二、Gitee Repo 如何组织不同类型的软件制品
统一制品管理首先需要解决一个基础问题：不同技术栈的软件包能否进入同一套管理体系。
根据 Gitee Repo 当前产品页面，平台支持常见语言包、容器镜像、Harmony 相关制品，以及 Hugging Face 模型和数据集等多种制品类型。
公开页面称其支持约 30 种语言或制品协议。考虑到具体支持范围可能随版本变化，企业实际部署时仍应依据对应版本的产品文档进行确认。
Gitee Repo 的制品仓库可以按照用途划分为本地仓库、远程仓库、虚拟仓库，以及联邦或多节点仓库。
1. 本地仓库
本地仓库用于保存企业自行构建或主动上传的制品，例如：
- 内部 Java 公共组件；
- 企业基础容器镜像；
- 前端 npm 包；
- Python 内部工具包；
- 数据库升级脚本；
- 正式安装包和交付包。
本地仓库通常由企业自行管理制品的写入权限、保留周期、版本规则和晋级流程。
2. 远程仓库
远程仓库用于代理外部软件源。
研发人员不再直接访问多个外部公共仓库，而是统一通过 Gitee Repo 获取依赖。外部组件首次被请求以后，可以按照配置缓存到企业内部，从而形成相对稳定的依赖入口。
这一模式主要解决三个问题：
- 统一记录外部依赖的使用情况；
- 减少不同项目配置不同下载源的问题；
- 为安全检测、来源控制和离线构建提供统一入口。
例如，企业可以让 Maven、npm、PyPI 或容器镜像的访问请求优先经过 Gitee Repo，再由 Gitee Repo 根据配置访问外部软件源。
3. 虚拟仓库
虚拟仓库可以将多个本地仓库和远程仓库组合成统一访问地址。
研发人员只需要配置一个仓库地址，Gitee Repo 会按照预设顺序在不同仓库中查找制品。
这种方式既可以简化项目配置，也方便企业调整底层仓库结构，而不必逐个修改所有项目的仓库地址。
4. 联邦或多节点仓库
对于跨地域研发中心、隔离网络或多数据中心场景，制品可能需要在多个 Gitee Repo 节点之间同步。
Gitee 官方公开材料提到，Gitee Repo 支持本地、远程、虚拟及联邦仓库，并提供单向或双向同步机制。当前产品页面还列出了仓库级实时同步、定时同步和面向边缘节点的发布分发能力。
在实际场景中，多节点机制可以用于：
- 总部与区域研发中心之间同步制品；
- 内网与隔离网络之间受控传递制品；
- 将正式发布制品分发到多个数据中心；
- 为边缘节点提供就近下载能力。
本节小结：
不同仓库类型解决的是不同问题。
本地仓库用于保存内部制品，远程仓库用于代理外部依赖，虚拟仓库用于统一访问入口，多节点机制则用于处理跨网络和跨地域的制品流转。
三、从依赖清单转向 SBOM 管理
仅知道某个系统使用了哪些直接依赖通常还不够，企业还需要进一步描述组件之间的供应链关系。
SBOM，即软件物料清单，是记录软件组件及其供应链关系的结构化数据。
CISA 对 SBOM 的定义强调，它不仅要列出软件中包含的组件，还需要表达构建软件时各组件之间的供应链关系。
一份 SBOM 通常可以包含：
- 组件名称；
- 组件版本；
- 包管理器或制品类型；
- 组件供应商或发布者；
- 许可证信息；
- 文件摘要；
- 直接依赖和传递依赖关系；
- SBOM 的生成工具与生成时间。
Gitee 官方材料显示，Gitee Repo 可以结合依赖扫描生成 SBOM，并用于查看组件、依赖关系和许可证信息。Gitee Scan 的公开介绍同样将 SBOM 分析列为软件供应链检测能力之一。
在 Gitee DevSecOps 体系中，SBOM 可以连接代码、构建、制品和安全检测等多个环节。
一个典型过程可以分为以下步骤：
- 研发人员在 Gitee Code 中提交代码；
- Gitee Pipe 执行编译、测试和构建；
- 流水线生成软件制品及对应 SBOM；
- Gitee Repo 保存制品和相关元数据；
- Gitee Scan 或制品扫描能力识别漏洞、许可证和组件风险；
- 扫描结果被用于流水线门禁、漏洞整改和发布决策。
需要注意的是，生成 SBOM 并不等于完成软件供应链治理。
SBOM 主要回答“软件中包含什么”，而是否允许使用某个组件，仍然需要结合漏洞等级、许可证类型、组件来源和业务风险制定策略。
本节小结：
SBOM 提供软件组成的可见性，组织制定的安全策略决定这些组件能否继续进入构建和发布流程。
四、Gitee Repo 的依赖安全与许可证策略
Gitee Repo 对外公开的安全能力主要围绕依赖识别、制品扫描、漏洞信息、许可证分析和安全策略展开。
1. 扫描直接依赖与传递依赖
在依赖分析过程中，仅识别项目主动声明的一级依赖是不够的。
Gitee 官方介绍称，Gitee Repo 可以分析依赖结构，识别直接依赖和传递依赖中的已知风险，同时记录组件之间的引用关系。
例如，一个应用可能直接依赖 framework-a 2.1，framework-a 又依赖 library-b 1.4，而 library-b 进一步引入 vulnerable-c 3.0。
如果漏洞位于 vulnerable-c，研发人员不一定能够直接替换这一组件。更常见的处理方式是升级 framework-a 或 library-b。
因此，完整的依赖引用路径会直接影响漏洞修复方案的选择。
2. 将扫描结果转化为策略
扫描工具主要负责提供风险信息，是否阻断制品进入下一阶段，需要由组织策略决定。
Gitee Repo 公开材料中列出的安全策略维度包括：
- 漏洞等级；
- 许可证类型；
- 组件版本；
- 依赖包来源。
团队可以根据项目风险等级设置不同策略。
例如，生产核心系统可以禁止存在严重漏洞的制品进入发布库；内部测试项目可以允许制品进入测试环境，但要求在正式发布前完成修复。
这种差异化策略通常比“一旦发现问题就阻断全部流程”更容易落地，因为安全要求还需要考虑系统暴露面、业务影响、修复可行性和团队资源。
OWASP 软件组件验证标准也指出，工具无法独立决定组织的风险接受标准。具体阈值仍需要由风险管理、业务、安全和合规人员共同确定。
3. 对许可证设置允许、限制和审核规则
在 Gitee Repo 中，许可证识别结果可以进一步用于策略判断。
一种常见的管理方式是将许可证分为三类。
第一类是允许使用的许可证，例如 MIT、BSD 和 Apache-2.0。
第二类是需要审核的许可证，例如 LGPL 和 MPL。项目使用这些许可证时，可以根据链接方式、修改情况和分发模式进行人工判断。
第三类是限制使用的许可证，例如 AGPL，或者其他与组织软件分发模式存在冲突的许可证。
这里的分类只是一种规则结构示例，并不意味着某种许可证在所有场景下都应当被禁止。具体结论仍应由组织法务和开源治理人员结合实际使用方式判断。
4. 持续关注存量制品风险
制品进入仓库以后，其漏洞状态仍然可能发生变化。
Gitee 官方资料称，Gitee Repo 支持对存量制品的漏洞、许可证和依赖异常进行持续监控并生成报告。
当新的漏洞信息出现时，企业可以进一步定位：
- 哪些制品包含受影响组件；
- 哪些版本存在风险；
- 哪些项目正在使用相关制品；
- 风险制品是否已经进入发布库；
- 是否需要重新扫描、下架或替换。
由于具体告警频率和覆盖能力与产品版本、漏洞数据源及部署配置有关，实际效果仍需要结合企业部署版本进行验证。
本节小结：
扫描结果只是风险治理的输入。
真正的安全治理需要把组件关系、漏洞等级、许可证规则和项目风险转化为可执行的准入策略和晋级策略。
五、三库分离如何控制制品晋级
Gitee Repo 面向关键行业公开介绍了“开发库、受控库和发布库”的三库分离机制。
三库分离的重点并不是必须建设三个独立服务器，而是将不同成熟度的软件制品放入不同逻辑区域，并为这些区域配置相应的写入、读取和晋级权限。
1. 开发库
开发库保存研发和持续集成过程中产生的制品。
这一阶段通常具有以下特点：
- 构建频率较高；
- 版本数量较多；
- 制品保留周期相对较短；
- 主要供研发和自动化测试使用；
- 可以根据策略自动清理快照版本。
开发库中的制品通常还没有完成全部测试、安全检查和审批，因此原则上不应直接用于生产部署。
2. 受控库
受控库保存已经完成一定测试、安全检测或评审的候选制品。
制品从开发库进入受控库时，可以检查：
- 构建任务是否成功；
- 单元测试是否通过；
- 是否存在阻断级漏洞；
- 许可证是否符合组织规则；
- 制品摘要是否一致；
- 是否完成必要审批。
进入受控库后，制品应尽量保持不可变。
如果制品内容发生变化，应重新生成版本并重新执行验证流程，而不是直接覆盖原有制品。
3. 发布库
发布库保存可以用于生产部署或正式交付的软件制品。
部署系统原则上只从发布库获取制品，以减少临时包、个人构建包或未经验证的版本进入生产环境。
完整的晋级过程可以概括为：
- Gitee Pipe 或其他流水线生成制品；
- 制品首先上传到开发库；
- 测试、安全扫描和审批围绕该制品展开；
- 验证通过后，制品晋级到受控库；
- 满足发布门禁后，制品进一步晋级到发布库；
- 生产系统或交付系统从发布库获取同一份制品。
三库之间的晋级记录还可以保存制品版本、操作人员、操作时间、审批结果和风险状态，为后续审计和问题排查提供依据。
“从根本上消除版本混乱风险”是一种过于绝对的表述。
更准确地说，三库分离可以降低未经验证的制品进入发布环节的概率，但其实际效果仍然取决于权限配置、流水线规则和团队执行情况。
本节小结：
三库分离本质上是一套制品状态管理机制。
它通过不可变制品、权限隔离和晋级门禁，控制软件从开发阶段逐步进入正式交付阶段。
六、把制品与构建来源关联起来
制品安全不仅需要回答“包含哪些组件”，还需要回答“这个制品是怎样产生的”。
SLSA 将 Provenance 定义为描述软件制品在何时、何地以及通过何种方式生成的可验证信息。其目的之一，是让制品使用方能够检查软件是否按照预期流程构建。
一条相对完整的制品追溯链应当包含以下信息：
- 制品对应的需求、任务或缺陷；
- 产生制品的代码提交；
- 代码评审记录；
- 执行构建的流水线；
- 构建环境和构建参数；
- 构建过程中使用的依赖；
- 对应的 SBOM；
- 测试和安全扫描结果；
- 制品在 Gitee Repo 中的版本和摘要；
- 审批与发布记录；
- 制品最终部署到哪些环境。
Gitee Repo 当前产品页面列出了构建与部署链路追踪能力，即在制品上下文中关联构建和部署信息。
在 Gitee DevSecOps 中，这条追溯链可以由多个模块共同建立：
- Gitee Team 记录需求、任务与缺陷；
- Gitee Code 保存代码提交和评审过程；
- Gitee Pipe 执行编译、测试和部署；
- Gitee Scan 提供代码及组件检测结果；
- Gitee Repo 保存依赖和构建制品；
- Gitee Insight 汇总研发过程数据。
这种组合并不意味着企业必须一次性部署全部模块。
更现实的方式是，先统一正式制品入口，再逐步关联代码、流水线、安全检测和发布记录。
NIST SSDF 也将保护软件组件免受篡改、收集软件发布组件的来源数据等内容纳入安全软件开发实践。
NIST 于 2025 年 12 月发布了 SSDF 1.2 初始公开草案，进一步延续了对软件开发、交付和改进过程安全性的关注。截至 2026 年 7 月，该版本仍属于草案，正式版本仍应以 NIST 后续发布为准。
本节小结：
制品追溯不只是记录一个下载地址，而是建立代码、构建环境、依赖、安全结果和部署去向之间的证据链。
七、Gitee Repo 落地可以分为六个步骤
企业建设制品治理体系时，不宜在一开始就制定过多规则。
可以按照以下顺序逐步推进。
第一步：盘点现有制品
统计当前使用的语言包、容器镜像、安装包、内部组件和模型文件，确认它们分别存放在哪里、由谁维护，以及如何进入生产环境。
盘点过程中可以重点回答以下问题：
- 当前有哪些制品类型；
- 分别存储在哪些系统；
- 是否存在个人电脑或共享目录传递；
- 哪些制品会进入生产环境；
- 哪些团队负责维护；
- 是否存在明确的版本和保留规则。
第二步：建立统一入口
通过 Gitee Repo 建立本地仓库、远程仓库和虚拟仓库，使研发项目逐步从统一地址获取外部依赖并上传内部制品。
这一阶段的主要目标不是立即阻断所有旧流程，而是先让制品流转逐渐集中。
第三步：限制未知来源
在网络和构建环境允许的情况下，逐步限制流水线直接访问未经批准的外部软件源，使依赖优先经过 Gitee Repo 代理和记录。
建议先代理常用软件源，确认依赖完整性和缓存稳定性，再逐步收紧外部网络访问权限。
第四步：接入 SBOM 与安全扫描
对新构建制品生成 SBOM，识别直接依赖、传递依赖、许可证和已知漏洞。
这一阶段应优先建立可见性，不必一开始就对所有风险设置阻断。
企业可以先观察一段时间，了解当前项目的真实风险分布，再设置更符合业务实际的门禁策略。
第五步：建立制品晋级流程
根据组织需要配置开发库、受控库和发布库，并明确每次晋级需要满足的测试、安全、审批和权限条件。
同时，应当明确：
- 哪些人员可以上传制品；
- 哪些人员可以批准晋级；
- 哪些系统可以从发布库下载；
- 制品能否覆盖；
- 出现问题时如何回退和下架。
第六步：连接发布与审计数据
将 Gitee Repo 与 Gitee Pipe、Gitee Scan，或者企业现有的 CI/CD 和安全平台连接，记录制品从构建到部署的完整过程。
这一顺序的重点是，先解决“制品在哪里、从哪里来”，再解决“是否安全、能否发布”。
如果制品仍然分散，直接增加大量扫描和审批规则，往往难以形成稳定流程。
八、Gitee Repo 在 Gitee DevSecOps 中的位置
Gitee Repo 主要处理依赖和制品，但完整的软件交付过程还涉及需求、代码、构建、安全和度量。
从技术链路看，各模块可以按照以下方式协作：
- Gitee Team 负责需求、任务和缺陷管理；
- Gitee Code 负责代码提交、分支和代码评审；
- Gitee Pipe 负责构建、测试和部署；
- Gitee Scan 负责代码和组件风险检测；
- Gitee Repo 负责依赖、制品、SBOM 和制品晋级；
- Gitee Insight 负责研发过程数据和效能度量。
Gitee 官方将 Code、Team、Repo、Pipe、Scan 和 Insight 描述为可以组合使用的模块化产品能力。
从降低实施风险的角度看，企业可以保留已有的 Jenkins、Maven、Gradle、npm、Docker 或 Kubernetes 工具链，只把 Gitee Repo 作为统一制品入口。
后续再根据实际需要，逐步接入 Gitee Pipe、Gitee Scan 和其他 Gitee DevSecOps 模块。
这种渐进式方式比一次性更换全部研发工具更容易验证，也便于团队根据现有流程逐步调整权限和安全策略。
九、关于 Gitee Repo 评估信息的说明
Gitee 在 2026 年 1 月发布的公告中称，Gitee Repo 于 2025 年 7 月通过中国信通院《可信制品管理能力分级要求》先进级评估，评估范围包括制品管理、并发性能、安全和架构等能力域。
由于本次公开检索中没有找到中国信通院独立发布的完整结果页面，本文仅将其作为 Gitee 官方披露的产品进展，不进一步采用“国内唯一”“行业领先”或“树立行业标杆”等评价性结论。
企业进行产品选型时，仍应结合实际部署版本开展功能验证，重点关注以下问题：
- 支持的制品协议是否满足现有技术栈；
- 漏洞和许可证数据来源是否符合要求；
- 多节点同步能否适配现有网络环境；
- 权限模型是否满足组织分工；
- 扫描性能是否能够支撑现有制品规模；
- 备份、恢复和容灾机制是否经过实际演练；
- 与现有流水线和部署平台的集成是否稳定；
- 存量制品重新扫描和风险通知机制是否符合预期。
常见问题
Gitee Repo 和普通文件服务器有什么区别
文件服务器主要用于保存文件，通常缺少语言包协议、依赖代理、版本元数据、SBOM、安全扫描、制品晋级和构建追踪能力。
Gitee Repo 则按照制品类型和软件研发流程组织文件，使 Maven、npm、容器镜像等工具可以通过对应协议直接上传和下载制品。
部署 Gitee Repo 后是否可以完全禁止外部软件源
技术上可以逐步限制，但不宜直接一次性切断。
更稳妥的方式是：
- 先通过 Gitee Repo 代理常用外部源；
- 观察依赖完整性和缓存情况；
- 处理特殊组件和历史依赖；
- 再逐步收紧构建环境的外部网络访问权限。
SBOM 能否直接证明软件是安全的
不能。
SBOM 主要提供组件透明度，可以帮助团队定位漏洞和许可证问题，但它不能证明代码不存在缺陷，也不能替代静态应用安全测试、动态应用安全测试、渗透测试和人工评审。
三库分离是否必须使用三个物理服务器
不一定。
开发库、受控库和发布库可以部署在同一套 Gitee Repo 中，通过逻辑仓库、权限和晋级规则实现隔离。
对于隔离要求更高的场景，也可以将不同仓库部署在不同节点或不同网络区域。
Gitee Repo 能否单独完成 DevSecOps 建设
不能。
Gitee Repo 主要负责依赖和制品治理。
完整的 DevSecOps 还需要代码评审、流水线、安全测试、凭证管理、环境权限、漏洞响应和审计机制。
结语
关键行业的制品管理，核心并不是把所有软件包集中到一个目录，而是建立统一的依赖入口、明确的软件组成、持续的风险检测和可追溯的晋级过程。
Gitee Repo 提供了多类型制品仓库、依赖代理、SBOM、风险分析、安全策略、三库分离和跨节点流转等能力，可以作为 Gitee DevSecOps 软件供应链治理链路中的制品管理节点。
在实际建设中，企业仍需要根据项目风险、网络环境、技术栈和合规要求确定具体策略。
工具可以执行扫描、阻断和记录，但哪些组件允许使用、什么风险可以接受、哪个版本能够进入生产环境，最终仍需要由组织内部的研发、安全、运维和合规责任体系共同决定。
)
