c44da777创建于 2025年11月25日历史提交

开源三方件维护指南

1. 选型指导

在引入开源软件前，建议从以下四个维度进行评估：

1.1 合法合规

1.1.1 许可证合规性

引入软件许可证合规性检查。

【规则】

禁止选用无许可证的软件，优选开源促进会（OSI）批准的软件，非OSI批准的软件需要安全SIG评审。

【建议】

优先选择软件本身（项目级和文件级）及其依赖软件的许可证均为宽松类型的软件；
确保项目的所有源码包含完整的许可头与版权声明。

1.1.2 许可证兼容性

引入软件许可证兼容性检查。

【规则】

禁止引入项目级或文件级许可证存在兼容性问题的软件及版本。

1.1.3 专利风险

引入软件专利风险分析。

【建议】

优先选择经全球专利保护社区（OIN）认证的软件；未经认证的软件需单独评估专利风险。

1.2 技术生态

1.2.1 依赖可获得性

引入软件依赖源码可获得性检查。

【规则】

项目依赖的库必须是可公开获取的开源软件。

1.2.2 代码维护

社区活跃度及是否活跃维护检查。

【规则】

选用处于成熟期（代码更新活跃、定期发布）或成长期（代码更新活跃、频繁发布）的软件；
禁止选用处于衰退期（代码无更新、无新版本发布）的软件。

1.2.3 社区支撑

社区服务与支撑能力检查。

【建议】

如社区无明确版本计划，或有效 Bug、PR 半年以上未响应，不建议选用。

1.2.4 采用度分析

引入软件采用度分析，优先选择业界广泛应用的软件。

【建议】

优先选择主流供应商/社区或社区项目；
优先选择在业界成熟应用或实际使用效果良好的软件。

1.2.5 软件质量

引入软件质量分析，包括代码规范、圈复杂度、代码复用度、测试用例覆盖度等。

【规则】

禁止引入不符合技术架构要求或已被技术演进淘汰的软件。

【建议】

优先选择架构更安全、灵活度高、支持组件化与插件化的软件；
优先选择代码质量高的软件，例如：使用不安全函数数量/密度少、代码结构规范（圈复杂度低）、重复度低、代码调试功能可关闭、具备自动化构建能力、自动化测试覆盖充分。

1.3 生命周期

1.3.1 版本生命周期

检查引入软件版本的社区维护生命周期是否结束。

【建议】

优先选择近 2 年内有正式版本发布的软件（以评审时间为准）；
社区已宣布 EOL（生命周期结束）的软件，不建议引入。

1.4 网络安全

1.4.1 二进制制品

引入软件源码仓库是否包含二进制制品。

【建议】

不建议直接引入二进制制品，应从源码构建。如确有必要引入，须经安全 SIG 决策，并提供构建指导。

1.4.2 安全漏洞

检查引入软件及其依赖源码是否存在公开未修复漏洞。

【规则】

禁止选用含有非误报病毒告警的软件（包括被动依赖软件）；
禁止选用含有已知未修复漏洞的软件。

1.4.3 漏洞响应机制

引入软件漏洞响应机制检查。

【规则】

选用的开源软件必须具备有效的漏洞反馈与修复跟踪管理机制。

2. 软件引入

2.1 软件引入评审

注意：同一软件包不同版本均视为新软件引入，当存在多版本时，需要完成选型评估及冲突影响分析才能引入。

引入查询：首先在 CANN 社区开源三方件仓查询该软件包是否已被引入。若已引入，直接进入 2.3 软件引入配置；否则，进入下一步评估。
选型评估：在引入评审前，依据开源软件引入申请模板开展选型评估并填写相关内容。
申报评审：可向 CANN 社区安全 SIG 申报开源软件引入申请议题，并在安全 SIG 会议白板中填写：议题X：XXX开源软件引入申请 —— 申报人：XXX。
会议评审：在 SIG 会议期间，依据模板内容进行陈述。议题结束后填写评审纪要，作为后续建仓引入的依据。

2.2 新建软件仓库及分支

注意：若新引入的版本软件对应仓库已存在，则可跳过创建软件仓库步骤，直接创建对应版本分支。

评审通过后，由安全 SIG 负责在 CANN 社区开源三方件仓创建对应仓库及版本分支。申请者在仓库及分支创建完成后，提交引入软件包的合并 PR，经安全 SIG 评审通过后，完成软件包的引入。

2.3 软件引入配置

申请人完成开源软件引入后，需在使用该软件的仓库对应文件（通常为 cmake/Third_Party_Open_Source_Software_List.yaml）中完成配置（以 eigen 为例），配置完成后用于进一步开发构建脚本以及后续的漏洞感知处理：

observability:  # 顶层公共节点
    eigen:  # 软件包名称
        url: https://gitlab.com/libeigen/eigen.git   # 软件包官方获取地址
        version: 3.4.0  # 对应版本号
        license: Mozilla Public License Version 2.0  # 许可证信息

并在根目录Third_Party_Open_Source_Software_Notice文件中添加相关声明（以protobuf为例）：

Copyright Notice and License Texts
Software: protobuf v3.13.0  
Copyright notice: 
Copyright 2008 Google Inc.
....
License: BSD 3-Clause License
Copyright (c) All rights reserved.
...

备注：完整例子可以参考ops-math仓

3. 软件升级

3.1 软件升级评审

按照 2.1 软件引入评审流程完成新版本引入评审。

注意：特别需关注升级的软件包是否被多个 CANN 仓库引用。如存在此情况，需协同对应仓库的 SIG 共同完成升级。

3.2 新建软件版本分支

评审通过后，由安全 SIG 在对应仓库中创建版本分支，提交引入软件包的合并 PR，经安全 SIG 评审通过后，完成软件包的升级。

3.3 软件配置更新

申请人完成开源软件升级后，需在使用该软件的仓库对应文件（通常为 cmake/Third_Party_Open_Source_Software_List.yaml）中更新配置及构建脚本，并在根目录Third_Party_Open_Source_Software_Notice文件中刷新相关声明。

注意：配置更新内容参考 2.3 软件引入配置）

4. 软件退出

4.1 软件退出评审

申报评审：可向 CANN 社区安全 SIG 申报开源软件退出申请议题，并在安全 SIG 会议白板中填写：议题X：XXX开源软件退出申请 —— 申报人：XXX。
会议评审：在 SIG 会议期间，说明清退原因、计划及影响范围，评审完成后填写最终评审结论。

4.2 软件配置删除

评审通过后，由安全 SIG 通知涉及该软件引用的仓库删除相关配置（通常为 cmake/Third_Party_Open_Source_Software_List.yaml）及构建脚本。

4.3 软件仓库删除

在所有引用仓库完成配置及构建脚本删除后，由安全 SIG 执行该软件包仓库的删除操作。