telecom-rd-project-template/.agents/skills/telecom-rd-standards/references/source-documents/09-artifact-management.md

# 中国电信软件研发规范制品管理分册（修订版）

> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。

中国电信软件研发规范制品管理分册 （修订版）

中国电信集团有限公司

## 2023 年 12 月

i

> 编制人员信息已移除。

版本变更历史

## 1 文档说明

### 1.1 编制说明

中国电信软件开发的成果以软件制品呈现，软件制品是中国电信重要的数字资产。只有具备规范的开发构建、安全扫描、存储管理、测试及部署的过程管理，并且配套进行全生命周期的元数据信息收集，才能形成安全可靠、可高效部署及成果可复用的数字资产。为了规范中国电信软件开发过程，制定本分册制品管理规范。软件制品从提供方式分为中国电信自主研发产生的制品和外购商业软件制品，本规范主要针对自主研发产生的制品，包含内部研发单位及外协单位研发产生的制品。

### 1.2 文档结构

本规范由文档说明 、制品全生命周期管理 、制品版本管理 、制品依赖的第三方组件管理及制品溯源管理等部分构成， 各章节的主要内容如下：第 1 章文档说明， 对编制目的 、文档结构 、使用范围 、起草单位 、解释权、版权和本规范用到的术语进行了说明。第 2 章制品全生命周期管理，对制品在开发构建 、安全扫描、存储管理 、测试及部署等全生命阶段的相关要求进行了说明。第 3 章制品版本管理，对制品版本、制品晋级及制品清理等要求进行了说明。第 4 章制品依赖的第三方组件管理，对制品依赖的第三方组件来源、安全扫描 、规范使用等要求进行了说明。第 5 章制品溯源管理，对制品元数据信息收集、制品软件物料清单等进行了说明。

### 1.3 适用范围

本规范适用于指导中国电信软件研发工作。

### 1.4 起草单位

本规范的起草单位是中国电信集团公司。

### 1.5 解释权

本规范解释权属于中国电信集团公司。

### 1.6 版权

本规范的版权属于中国电信集团公司。

### 1.7 名词解释

## 2 制品全生命周期管理

### 2.1 制品全生命周期管理总体要求

中国电信软件研发的输出成果是制品，研发目标是软件制品上线运行，为客户提供预期服务。软件制品的质量及交付效率是中国电信软件研发的重要衡量指标之一。为了保证交付上线的软件制品质量，必须从制品开发构建、安全扫描、存储管理 、测试及部署等全生命阶段进行规范化管理。为了实现制品的准确、及时交付，必须伴随制品生命周期流转收集必要的元数据信息， 以便实现制品标准化流转及自动化交付。制品全生命周期管理应遵循如下总体原则：构建制品的源代码及需求来源可追溯制品的安全质量可管控制品的存储管理安全可靠制品应唯一可信， 保证部署上线的制品即测试通过的制品制品操作及流转日志可审计

### 2.2 开发构建

#### 2.2.1 开发环境管理 （C1）

制品开发构建无论是本地开发构建还是采用流水线协同开发构建，均须连接统一制品库进行第三方依赖组件下载，由统一制品库代理官方的第三方组件下载源。对于构建过程中需要依赖的二方组件，需上传到统一制品库进行管理，确保通过统一制品库管控所有的二方组件 、三方组件。开发构建生成的制品必须上传到统一制品库进行管理。开发环境应将项目下载依赖及上传构建制品的仓库地址指向统一制品库。

#### 2.2.2 制品关联开发构建关键信息

开发构建的制品必须收集构建信息，构建信息至少包括构建时间、构建人员、构建名称 、构建工具 、引用的第三方依赖等 。(C3)开发构建的制品必须通过元数据关联代码仓库 、分支 、commit id 等信息，以便进行制品代码溯源及研发效能度量 。（C3）开发构建的制品应根据所关联的代码信息进一步关联到对应的需求或缺陷等 。（C4）

### 2.3 制品安全扫描管理

#### 2.3.1 制品关联源代码质量及安全扫描信息

制品应通过元数据关联源代码质量及安全扫描信息，以便根据代码质量及安全扫描结果对制品的流转进行自动化处理 。(C3)根据源代码质量及安全扫描结果，结合企业安全管控策略，确定制品能否进入存储管理环节及测试环节 。（C4）

#### 2.3.2 制品关联第三方组件安全扫描信息

制品应关联第三方组件安全漏洞扫描信息，以便根据制品第三方组件安全扫描结果对制品的流转进行自动化处理 。(C2)对于存在高中危风险漏洞问题的制品，当存在可修复的组件版本时，必须在开发阶段完成漏洞问题的修复；当暂无可修复组件版本时，应根据企业安全管控策略， 确定制品能否进入测试及部署环节 。（C2）

#### 2.3.3 制品关联第三方组件许可协议信息

制品必须关联第三方组件许可协议扫描信息，以便管控制品依赖的第三方组件符合开源协议要求 。(C3)支持制定本企业合规的开源许可协议，结合企业开源合规管控策略，确定制品能否进入测试及部署环节 。（C4）

### 2.4 存储管理

#### 2.4.1 通过统一制品库管理 （C1）

开发构建的制品必须通过统一制品库进行存储管理。项目团队应根据开发语言、构建工具、部署方式及制品的开发周期设置合适的项目制品仓库， 统一存储管理项目构建制品。根据制品开发周期， 建议创建开发快照仓库和部署发布仓库。制品仓库类型的设置应遵循以下原则：对于云原生应用制品， 建议创建 docker 仓库存储管理 docker 镜像制品，创建 helm 仓库存储管理 helm 配置文件。对于直接部署安装的制品，建议创建 generic仓库，并设置简洁清晰的目录存储制品。对于作为项目构建依赖的制品，建议创建相应的制品类型仓库进行管理，比如 java 采用 maven，nodejs 采用 npm，Go 采用 go 等， 以实现不同构建工具正确索引 、上传及下载制品需求。项目制品仓库的命名格式， 应遵循如下规范：

项目名-[子项目名]-生命周期-制品类型-仓库类型项目名：使用项目英文标识，仅限英文大小写字母（A-Z、a-z）、数字（0-9），且不能使用数字开头。子项目名： 当区分子项目管理制品仓库时出现， 格式要求同项目名。生命周期： 开发快照仓库使用 snapshot， 生产发布仓库使用 release。制品类型：表示制品包类型，遵循通用的包类型命名方式，比如docker、maven、 npm 、go 、pypi 、gems 、generic 等。仓库类型： 项目本地制品仓库使用 local， 项目虚拟制品仓库使用virtual。

#### 2.4.2 制品访问权限管理 （C1）

项目团队必须对项目制品仓库设置严格的访问权限，管控团队成员上传、修改 、删除及下载制品的操作。针对项目制品仓库应设置管理员、读写人员及只读人员等不同角色权限，满足项目管理员 、开发人员 、测试人员 、运维人员的使用需求。

#### 2.4.3 制品访问日志审计 （C2）

制品上传、下载、修改、删除必须留痕记录， 日志至少应记录操作人员、操作时间 、制品名称 、发起操作请求的客户端 IP 地址 、操作类型等。制品访问日志记录必须至少保存 6 个月。

### 2.5 测试阶段

测试阶段的制品必须从统一制品库获取 。（C1）制品必须关联制品在各阶段的测试结果，以便根据制品在各阶段的测试结果确定制品是否晋级 。（C4）

### 2.6 部署阶段

部署阶段的制品必须从统一制品库获取。只有安全检查及测试通过的制品才能部署到生产环境 。（C1）制品必须关联部署环境信息、部署时间及部署人员等信息，以便对部署到生产系统的制品进行溯源管理 。（C4）

## 3 制品版本管理

### 3.1 制品版本管理

#### 3.1.1 制品的版本号 （C1）

软件制品的版本号应该与源代码的版本号保持一致。对于代码中有明确version 定义版本的， 制品版本号与代码中version相同。代码中无version定义版本号的，代码分支有 tag 表示版本号情况，制品版本号与对应代码分支的 tag 相同。代码中无version定义版本号的，代码分支也没有 tag 情况，则构建或打包制品的版本号应遵循代码的 tag 格式原则。

#### 3.1.2 制品快照版本 、正式版本的使用 （C1）

开发测试阶段应该使用快照版本（SNAPSHOT 版本）， 更利于开发调试。快照版本在测试完成之后，应发布正式版本的制品进行回归测试。回归测试通过后才允许发布到生产环境。制品的正式版本号不允许覆盖升级， 确保每个发布部署的制品版本可追溯。

#### 3.1.3 制品版本追溯 （C3）

发布上线的制品必须可追溯到源代码版本（commit id），应通过制品的元数据关联构建信息 、构建代码的 commit id。

发布上线的制品应通过制品文件与制品元数据的紧密关联，实现版本研发全过程及状态的追溯。

### 3.2 制品晋级管理

开发构建的制品应随着生命周期的流转进行制品晋级，确保制品从开发构建到测试 、上线发布的唯一可信性， 从而保证系统上线部署的成功率。

#### 3.2.1 制品自动晋级 （C3）

制品应根据在生命周期各阶段收集的元数据信息及晋级策略进行制品的自动晋级，实现一次构建多次使用。制品应在各阶段测试及安全检查通过后从开发快照仓库晋级到生产发布仓库。

#### 3.2.2 制品审核晋级 （C4）

根据项目管控需要，在晋级到生产发布仓库前，可增加项目经理人工审核流程， 审核通过后才允许发布到生产发布仓库。

### 3.3 制品清理管理 （C1）

对于长期未使用的制品，应按版本、时间进行手动或自动清理，避免无效的制品文件占用制品库空间。对于开发快照仓库的制品， 应当限制版本数量， 最多不超过 10 个。对于生产发布仓库，针对已部署到现网的版本，建议永久保存， 以便进行版本对照与追踪。

## 4 制品依赖的第三方组件管理

### 4.1 使用统一的依赖源 （C1）

项目团队应使用统一制品库作为第三方组件的依赖源。制品库应统一代理第三方组件的官方下载源，包括《中国电信软件开发组件清单》，组件的引入和使用应符合《中国电信软件开发统一技术栈要求(试行版)》（中国电信科创〔2023〕 1号） 。

### 4.2 对第三方组件进行安全扫描 （C2）

制品应该通过软件成分分析（SCA）工具进行制品安全扫描和许可协议分析。制品安全扫描工具需要展示第三方组件安全漏洞扫描详情，包括存在问题的组件名称 、版本 、 问题描述 、严重性等级 、CVSS 评分 、CVE 信息及对制品的影响路径等。

### 4.3 制定第三方组件的使用规范 （C4）

需要制定第三方组件的使用规范,应包含如下几个方面：对禁用的第三方组件， 应设置黑名单拦截。对需要管控的第三方组件， 应设置基线范围来进行管控。项目层面新增的第三方组件需要项目负责人进行审批。

## 5 制品溯源管理

为保证软件交付的质量， 必须在制品的生命周期过程中收集必要的元数据。元数据应伴随制品文件保存在统一制品库。制品元数据分为两类：制品本身的元数据 、制品的软件物料清单。

### 5.1 制品元数据信息收集

#### 5.1.1 制品本身的元数据 （C3）

制品本身的元数据应包括以下几类：

#### 5.1.2 制品的评分体系

制品评分包括： 系统评分和用户评分。

##### 5.1.2.1 制品的系统评分（C0）

系统评分主要针对一方库制品和二方库制品，系统评分是按照既定规则对制品生命周期过程的一个综合评价 。评分应包含以下几点：通过统一制品库来发布符合代码质量扫描规范经过代码评审环节符合单元测试覆盖率/成功率指标是测试环境通过的可信制品是否存在安全漏洞运行时的动态指标， 如启动耗时， 启动时内存消耗等二方库制品的被引用数

##### 5.1.2.2 制品的用户评分（C0）

用户评分主要是针对二方库制品，使用方应对二方库制品给出用户评分和建议， 从而来推动二方库制品的持续改进 。评分应包含以下几点：接口设计是否合理依赖组件的多少 、依赖组件的深度

### 5.2 制品软件物料清单收集

大多数软件制品都包含一系列复杂的第二方组、第三方组件，软件物料清单(SBOM)是软件的组件列表，其中关键信息包括组件名称、供应商、版本号和许可证信息等。

#### 5.2.1 确定软件使用的物料清单 （C0）

在制品的构建阶段， 应基于制品包管理器（maven 、npm 等）查询依赖的第二方组件 、第三方组件， 从而获取软件物料清单。需要注意的是，制品引用的第二方组件常常引用其他的第三方组件，制品的SBOM 必须在依赖关系图中尽可能深入地枚举组件。同时还应提供依赖组件的分层信息， SBOM 中的每个组件都应该有自己对应的 SBOM。

#### 5.2.2 判断软件物料清单中的第三方组件是否安全 （C0）

1.能够支持通过 SBOM 快速定位到制品的第三方组件，并结合安全扫描工具来快速定位第三方组件是否有漏洞。2.当有新的安全漏洞时， 能够支持通过漏洞（或有漏洞的第三方组件）结合SBOM 来快速定位到有安全风险的制品， 并进行相关整改。