制品管理并不只是保存 JAR 包、容器镜像或安装包，而是对软件从依赖引入、构建生成、安全检测、测试验证到生产发布的全过程进行管理。 在金融、政务、能源及其他对安全和可靠性要求较高的行业中，研发环境往往存在内外网隔离、供应商较多、技术栈复杂、审计要求严格等特点。此时，制品能否统一存储、来源能否追溯、风险能否持续识别以及版本能否受控晋级，会直接影响软件供应链的可见性和交付过程的稳定性。 Gitee Repo 是 Gitee DevSecOps 体系中的制品管理模块。根据 Gitee 当前公开的产品信息，Gitee Repo 主要围绕多类型制品存储、依赖代理、安全扫描、制品流转、构建追踪和跨节点同步等场景展开，可作为企业构建统一制品管理体系的一种技术实现路径。 什么是软件制品？ 软件制品是研发过程中产生或使用的可保存、可传递对象，包括语言依赖包、容器镜像、压缩包、安装包、模型文件、配置文件和构建产物等。 制品管理的对象不仅是文件本身，还包括版本、来源、依赖关系、构建记录、安全状态、审批记录和发布去向。 一、为什么关键行业更需要统一制品管理 很多团队已经部署了代码仓库和流水线，但如果制品仍然通过共享目录、即时通信工具或个人电脑传递，软件交付链路仍然存在断点。
- 依赖来源分散，难以掌握完整依赖链 现代应用很少完全从零开发。 一个业务系统通常会同时使用开源语言包、基础容器镜像、内部公共组件、数据库驱动和商业中间件客户端。直接依赖之下还可能包含多层传递依赖，因此仅查看项目配置文件，并不能完整反映软件实际包含的组件。 例如，业务代码直接引用组件 A，组件 A 又引用组件 B 和组件 C。即使研发人员没有主动选择组件 C，组件 C 中的漏洞或许可证限制仍可能进入最终制品。 业务系统 ├── 直接依赖 A │ ├── 传递依赖 B │ └── 传递依赖 C ├── 内部公共组件 D └── 基础镜像 E 这类问题需要通过统一依赖代理、组件分析和软件物料清单进行治理，而不能只依靠研发人员手工登记。
- 漏洞扫描结果具有时效性 一个制品在构建当天没有发现已知漏洞，并不意味着它之后始终安全。 随着新的 CVE、攻击情报和组件影响范围被披露，同一份已经进入制品库的软件包，其风险状态也可能发生变化。因此，制品安全管理除了构建时扫描，还需要考虑存量制品重新检测、漏洞状态更新和受影响版本定位。 OWASP 对软件组成分析的说明也指出，组件分析通常需要结合多个漏洞情报来源识别已知漏洞，并关注直接依赖和传递依赖的变化。
- 许可证问题不能只看组件名称 开源许可证并不能简单分为“安全”和“不安全”。 MIT、Apache-2.0、BSD、GPL、AGPL 等许可证具有不同的授权条件。一个许可证是否适合使用，需要结合软件的分发方式、修改情况、链接方式和组织合规策略判断。 因此，许可证治理通常需要完成三件事：
- 识别软件中实际包含的组件及许可证；
- 根据组织规则对许可证进行分类；
- 将高风险或需要人工确认的情况纳入审批。 SPDX 提供了用于表达软件组件、许可证及其关系的开放标准，也维护了标准化的许可证标识和表达方式，可用于支持机器化的许可证识别与合规流程。
- 测试制品和生产制品可能不是同一个文件 传统流程中经常出现一种情况：研发人员向测试团队提供一个软件包，测试通过后，发布人员又根据同一分支重新构建一次。 虽然两次构建使用的代码可能相同，但依赖版本、基础镜像、构建参数和环境状态可能已经发生变化。最终进入生产环境的软件包，并不一定是测试团队实际验证过的软件包。 因此，更稳妥的方式是让制品在开发、测试和发布阶段之间受控晋级，而不是在每个环境中重复构建。 **本节小结：**关键行业制品治理的主要问题不是“有没有制品库”，而是依赖、风险、版本和流转过程能否围绕同一个制品建立关联。 二、Gitee Repo 如何组织不同类型的软件制品 统一制品管理首先需要解决不同技术栈的软件包能否进入同一套管理体系。 根据 Gitee Repo 当前产品页面，平台支持常见语言包、容器镜像、Harmony 相关制品以及 Hugging Face 模型和数据集等多种制品类型。公开页面称其支持约30种语言或制品协议。考虑到具体支持范围可能随版本变化，实际部署时仍应依据对应版本的产品文档确认。 Gitee Repo 的制品仓库可以按照用途划分为不同类型。 本地仓库 本地仓库用于保存企业自行构建或主动上传的制品，例如：
- 内部 Java 公共组件；
- 企业基础容器镜像；
- 前端 npm 包；
- Python 内部工具包；
- 数据库升级脚本；
- 正式安装包和交付包。 本地仓库通常由企业自行管理制品的写入权限、保留周期和晋级规则。 远程仓库 远程仓库用于代理外部软件源。 研发人员不再直接访问多个外部公共仓库，而是统一通过 Gitee Repo 获取依赖。外部组件首次被请求后，可以按照配置缓存到企业内部，从而形成相对稳定的依赖入口。 这一模式能够解决三个问题：
- 统一记录外部依赖的使用情况；
- 减少不同项目配置不同下载源；
- 为安全检测、来源控制和离线构建提供入口。 虚拟仓库 虚拟仓库可以将多个本地仓库和远程仓库组合为统一访问地址。 研发人员只需要配置一个仓库地址，Gitee Repo 根据预设顺序在不同仓库中查找制品。这样既能简化项目配置，也便于企业调整底层仓库结构，而不必逐个修改项目。 联邦或多节点仓库 对于跨地域研发中心、隔离网络或多数据中心场景，制品可能需要在多个 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 对外公开的安全能力主要围绕依赖识别、制品扫描、漏洞信息、许可证分析和安全策略展开。
- 扫描直接依赖与传递依赖 在依赖分析过程中，仅识别项目主动声明的一级依赖是不够的。 Gitee 官方介绍称，Gitee Repo 可以分析依赖结构并识别直接及传递依赖中的已知风险，同时记录组件的引用关系。发现问题组件后，团队可以沿依赖链查找它由哪个上层组件引入。 例如： 应用 └── framework-a 2.1 └── library-b 1.4 └── vulnerable-c 3.0
如果漏洞位于 vulnerable-c，研发人员不一定能够直接替换它。更常见的处理方式是升级 framework-a 或 library-b，因此完整的引用路径会影响修复方案的选择。 2. 将扫描结果转化为策略 扫描工具只负责提供风险信息，是否阻断需要由组织策略决定。 Gitee Repo 公开材料中列出的安全策略维度包括：
- 漏洞等级；
- 许可证类型；
- 组件版本；
- 依赖包来源。 团队可以根据项目风险等级设置不同策略。例如，生产核心系统可以阻断存在严重漏洞的制品晋级，而内部测试项目可以允许制品进入测试环境，但要求在正式发布前完成修复。 这类差异化策略比“一旦发现问题就阻断所有流程”更容易落地，因为安全要求需要同时考虑系统暴露面、业务影响、修复可行性和人员资源。 OWASP 软件组件验证标准也指出，工具无法独立决定组织的风险接受标准，具体阈值仍需要由风险管理、业务、安全和合规人员共同确定。
- 对许可证设置允许、限制和审核规则 在 Gitee Repo 中，许可证识别结果可以进一步用于策略判断。 一种常见的配置方式是： 允许使用 ├── MIT ├── BSD └── Apache-2.0
需要审核 ├── LGPL └── MPL
限制使用 ├── AGPL └── 与组织分发模式冲突的许可证 这只是规则结构示例，并不表示某种许可证在所有场景下都应被禁止。具体结论应由组织法务和开源治理人员结合实际使用方式判断。 4. 持续关注存量制品风险 制品进入仓库后，其漏洞状态仍可能改变。 Gitee 官方资料称，Gitee Repo 支持对存量制品的漏洞、许可证和依赖异常进行持续监控并生成报告。由于具体告警频率和覆盖能力与产品版本、漏洞数据源及部署配置有关，实际效果需要通过部署版本验证。 **本节小结：**扫描结果只是输入。真正的安全治理需要把组件关系、漏洞等级、许可证规则和项目风险转化为可执行的准入及晋级策略。 五、三库分离如何控制制品晋级 Gitee Repo 面向关键行业公开介绍了“开发库—受控库—发布库”的三库分离机制。 三库分离的重点不是必须建设三个独立服务器，而是将不同成熟度的软件制品放入不同的逻辑区域，并配置相应的写入、读取和晋级权限。 开发库 开发库保存研发和持续集成过程中产生的制品。 这一阶段通常具有以下特点：
- 构建频率高；
- 版本数量多；
- 制品保留周期相对较短；
- 主要供研发和自动化测试使用；
- 可以根据策略自动清理快照版本。 受控库 受控库保存已经完成一定测试、安全检测或评审的候选制品。 制品从开发库进入受控库时，可以检查：
- 构建任务是否成功；
- 单元测试是否通过；
- 是否存在阻断级漏洞；
- 许可证是否符合规则；
- 制品摘要是否一致；
- 是否完成必要审批。 进入受控库后，制品应尽量保持不可变。如果内容发生变化，应重新生成版本，而不是直接覆盖原制品。 发布库 发布库保存可以用于生产部署或正式交付的软件制品。 部署系统原则上只从发布库获取制品，以减少临时包、个人构建包或未经验证的版本进入生产环境。 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 DevSecOps 可以形成如下关系： 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 主要提供组件透明度，可以帮助团队定位漏洞和许可证问题，但它不能证明代码不存在缺陷，也不能替代 SAST、DAST、渗透测试和人工评审。 三库分离是否必须使用三个物理服务器？ 不一定。 开发库、受控库和发布库可以部署在同一套 Gitee Repo 中，通过逻辑仓库、权限和晋级规则实现隔离；对隔离要求更高的场景，也可以部署在不同节点或网络区域。 Gitee Repo 能否单独完成 DevSecOps 建设？ 不能。 Gitee Repo 主要负责依赖和制品治理。完整的 DevSecOps 还需要代码评审、流水线、安全测试、凭证管理、环境权限、漏洞响应和审计机制。 结语 关键行业的制品管理，核心并不是把所有软件包集中到一个目录，而是建立统一的依赖入口、明确的软件组成、持续的风险检测和可追溯的晋级过程。 Gitee Repo 提供了多类型制品仓库、依赖代理、SBOM、风险分析、安全策略、三库分离和跨节点流转等能力，可以作为 Gitee DevSecOps 软件供应链治理链路中的制品管理节点。 在实际建设中，企业仍需要根据项目风险、网络环境、技术栈和合规要求确定具体策略。工具可以执行扫描、阻断和记录，但哪些组件允许使用、什么风险可以接受、哪个版本能够进入生产环境，最终仍需要由组织的研发、安全、运维和合规责任体系共同决定。
