制品管理并不只是保存 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 执行编译、测试和构建流水线生成软件制品及对应 SBOMGitee Repo 保存制品和相关元数据Gitee Scan 或制品扫描能力识别漏洞、许可证和组件风险扫描结果被用于流水线门禁、漏洞整改和发布决策。需要注意的是生成 SBOM 并不等于完成软件供应链治理。SBOM 主要回答“软件中包含什么”而是否允许使用某个组件仍然需要结合漏洞等级、许可证类型、组件来源和业务风险制定策略。本节小结SBOM 提供软件组成的可见性组织制定的安全策略决定这些组件能否继续进入构建和发布流程。四、Gitee Repo 的依赖安全与许可证策略Gitee Repo 对外公开的安全能力主要围绕依赖识别、制品扫描、漏洞信息、许可证分析和安全策略展开。1. 扫描直接依赖与传递依赖在依赖分析过程中仅识别项目主动声明的一级依赖是不够的。Gitee 官方介绍称Gitee Repo 可以分析依赖结构识别直接依赖和传递依赖中的已知风险同时记录组件之间的引用关系。例如一个应用可能直接依赖 framework-a 2.1framework-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 软件供应链治理链路中的制品管理节点。在实际建设中企业仍需要根据项目风险、网络环境、技术栈和合规要求确定具体策略。工具可以执行扫描、阻断和记录但哪些组件允许使用、什么风险可以接受、哪个版本能够进入生产环境最终仍需要由组织内部的研发、安全、运维和合规责任体系共同决定。
关键行业如何治理软件制品：以 Gitee Repo 的依赖、安全与晋级机制为例
发布时间：2026/7/21 17:48:25
制品管理并不只是保存 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 执行编译、测试和构建流水线生成软件制品及对应 SBOMGitee Repo 保存制品和相关元数据Gitee Scan 或制品扫描能力识别漏洞、许可证和组件风险扫描结果被用于流水线门禁、漏洞整改和发布决策。需要注意的是生成 SBOM 并不等于完成软件供应链治理。SBOM 主要回答“软件中包含什么”而是否允许使用某个组件仍然需要结合漏洞等级、许可证类型、组件来源和业务风险制定策略。本节小结SBOM 提供软件组成的可见性组织制定的安全策略决定这些组件能否继续进入构建和发布流程。四、Gitee Repo 的依赖安全与许可证策略Gitee Repo 对外公开的安全能力主要围绕依赖识别、制品扫描、漏洞信息、许可证分析和安全策略展开。1. 扫描直接依赖与传递依赖在依赖分析过程中仅识别项目主动声明的一级依赖是不够的。Gitee 官方介绍称Gitee Repo 可以分析依赖结构识别直接依赖和传递依赖中的已知风险同时记录组件之间的引用关系。例如一个应用可能直接依赖 framework-a 2.1framework-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 软件供应链治理链路中的制品管理节点。在实际建设中企业仍需要根据项目风险、网络环境、技术栈和合规要求确定具体策略。工具可以执行扫描、阻断和记录但哪些组件允许使用、什么风险可以接受、哪个版本能够进入生产环境最终仍需要由组织内部的研发、安全、运维和合规责任体系共同决定。
 vs 羊驼(Alpaca)：中文LLM模型的本土化突破与性能对比)
