信息技术开源治理第2部分:
企业治理评估模型
1范围
本文件规定了企业在自身开源治理过程中应该具备的方法、流程和能力。
本文件适用于所有使用和贡献开源项目的企业单位。
2规范性引用文件
本文件没有规范性引用文件。
3术语和定义
下列术语和定义适用于本文件。
开源项目Open Source Project
以开源协作模式运作的项目。
开源社区Open Source Community
开源组织的一种，是具有共同目标、愿景、与价值观的共同体，又称开源共同体。
源代码Source Code
以适宜于汇编器、编译器或其他翻译器作为输入的形式所表达的代码。
[来源：GB/T5271.7-200807.04.38]
制品Artifact
由源代码编译构建生成的二进制文件。
4缩略语
以下缩略语适用于本文本。
OSPO：开源项目办公室（Open Source Program Office）
CI/CD：持续集成/持续交付（Continuous Integration/Continuous Delivery）
SBOM：软件物料清单（Software Bill of Material）
5企业开源治理评估模型
概述
企业使用开源的过程中主要面对的风险包括：许可证合规风险，安全漏洞风险，知识产权风险，出口管制风险等，规避和消除上述诸类风险是企业开源治理的主要目标。
企业开源治理评估模型
企业开源治理评估模型见图1。本模型包含企业开源治理工作中的人员、制度和资源三个方面。其中人员部分描述了开源治理团队的组织架构以及包含的各种成员角；制度部分描述了企业规范开源治理
工作的相关制度政策；资源部分描述了企业完成开源治理工作的相关基础设施。
图1企业开源治理评价模型
6组织架构
总体要求
OSPO负责制定开源合规规范、开源治理流程和协调资源，统筹规划和推动企业开源治理工作。OSPO 包含若干角、工作团队，负责相应职责的工作。
开源管理
治理专家
安全专家
除开源安全漏洞以外，安全专家还应负责与开源相关的数据安全，个人信息安全等其他安全事项。
基础设施支撑
社区运营
源社区的各种活动以及大型会议，推广企业自发开源项目，以及相关商业宣传等。
7制度政策
开源使用制度
企业应制定引入开源项目到企业内部使用的管理制度。包括开源项目的引入、开源项目的更新以及开源项目的退出。
对于产品中有包含外购商业部件和外包研发部件的企业，还应制定因使用商业部件和外包研发而被动引入开源项目的管理制度。
开源贡献制度
企业应制定开源贡献制度。包括对外部现有开源项目的贡献，以及企业将私有项目主动对外开源。
风险管理制度
企业应制定针对于各类风险的预防和消除制度，以及风险应急预案。需应对的风险包括安全漏洞风险、许可证合规风险、知识产权风险和出口管制风险等。
开源培训制度
企业应制定面向企业内的开源培训制度，使得员工了解企业关于开源的各项制度和规程，确保各项规避风险的制度能被贯彻落实。
8开源声明周期管理
开源项目引入
8.1.1开源选型规范
企业应制定开源项目选型规范，指导企业研发项目在需要引入开源项目时对其进行评价对比，以判断是否使用。开源选型应综合考虑开源项目的各方面情况进行判断，宜采用以下几个维度作为评判因素，企业可以根据研发项目的需要和特点来从其中进行选择和设置权重。
a)需求满足度。宜参照但不仅限于以下方面予以衡量：
∙功能满足度，
∙性能满足度，
∙易用性满足度，
∙可靠性满足度，
∙可维护性满足度，
∙可移植性满足度。
b)项目成熟度。宜参照但不仅限于以下方面予以衡量：
∙是否持续的发布了一定数量的稳定版本。
∙是否具有比较稳定的核心贡献者团队，
∙是否具有比较明确的技术规划，
∙是否具有比较明确的版本发布计划，
∙是否具有比较完备的文档，
∙是否具有比较可靠的故障和漏洞提交和解决机制，
∙是否具有自动化构建和测试能力，
∙是否具有比较稳定充足的CI/CD环境和相应资源，
∙是否具有比较可靠的代码托管机制，
∙是否具有多个代码托管地。
c)开源许可证。
∙企业应建立允许引入使用的开源许可证清单或禁止引入使用的开源许可证清单。可根据不
同的业务场景制定不同的允许清单或禁止清单。
∙应禁止使用许可证不明的开源项目。
∙宜尽量使用具有知识产权条款的开源许可证的开源项目。
∙当企业的研发项目为对外发布的闭源项目时，应考虑引入开源项目的开源许可证传染性，防止出现违反开源许可证要求的合规问题。
d)项目活跃度。宜参照但不仅限于以下方面予以衡量：
∙最后一个版本发布距今的时间，
∙开源项目版本发布更新频率，
∙软件BUG和安全漏洞的修正周期，
∙开源贡献者数量，
∙开源贡献来源多样性，
源代码下载开源社区∙相关开源社区活动的形式和频率。
e)行业认可度。宜参照但不仅限于以下方面予以衡量：
∙是否有行业主要厂商的支持。
f)风险评估。宜参照但不仅限于以下方面予以衡量：
∙开源项目版本中是否含有安全漏洞风险。
∙开源项目版本中是否含有知识产权风险。
8.1.2开源引入规范
企业应制定开源项目的引入流程规范，各研发项目依据此规范将开源项目引入企业内部使用。此引入流程规范一般可包括：
——明确选型需求：包括功能需求，性能需求等；
——开源项目选型：依据开源项目选型规范选择开源项目，输出有优先级的备选清单；
—
—开源项目选型确认：通过测试验证确定备选清单中的开源项目是否确实满足了选型需求，并最终确定唯一的选型结果；
——开源项目代码/制品入库：将选定的开源项目的代码/制品拉取到企业内部，并入企业开源项目管理库，供后续进行使用和管理。代码/制品需要从官方或者可靠的源下载，避免引入安全
隐患。
——开源项目引入台账：对于上述选型，确认，入库等流程信息，需要在企业内部予以记录。
8.1.3开源项目守护
企业应制定开源软件在引入企业内后的守护规范。每个开源软件在被引入企业进行使用后应设置一个守护团队，守护团队主要有以下职责：
——应跟踪所守护开源项目的技术动向，识别开源项目的功能增减和性能变化等重要技术特征，为使用此开源项目的企业内研发项目提供使用建议。
——应跟踪所守护开源项目的缺陷，安全漏洞。及时向企业内部使用了此开源项目的研发项目推送升级建议或补丁。
——应跟踪开源项目使用开源许可证的变更情况，及时向企业内部使用了此开源项目的研发项目提供指导意见
——宜建立面向所守护开源项目的软件构建和测试环境，建立测试验证方案，具备构建和测试验证能力。
——当开源社区不能及时提供缺陷和安全漏洞的解决方案和补丁时，守护团队宜自行制定解决方案并研发补丁。
——对其守护的开源项目宜制定一个可以使用的版本基线，这个基线可以是一个版本集合，要求企业内研发项目使用此开源项目时，只能使用这个集合中的版本。基线版本除开源项目版本
的原始内容外，还应包含解决了此版本中缺陷和安全漏洞的补丁。
——可参与所守护开源项目的外部社区开源贡献活动，将企业自行研发的功能和补丁贡献到开源社区。
开源项目使用更新
企业应制定开源项目使用更新规范，列出研发项目必须更新其所使用的开源项目的情况，更新包括升级版本和自行打补丁。这些情况可包括：
——功能/性能需求：研发项目发现在用的开源项目版本不能满足功能或性能需求，需要通过升级来满足需求。
——现使用版本存在重大安全漏洞：企业应根据业界通用的漏洞库的漏洞等级确定哪些级别的漏洞必须通过更新来解决。
——现使用版本过于老旧：企业应规定开源项目版本老旧的标准，如必须选用开源项目最新的几个版本，和/或当前开源项目版本最旧发布时间。
——现使用的开源项目许可证发生了变更，变更为企业不能接受的开源许可证，企业应考虑对此开源项目进行重新选型，使用同等功能的其他开源项目替换。
注：如企业对一个开源项目已经通过其守护团队建立了可以使用的版本基线，则研发项目在对这个开源项目进行更新时就必须选用基线范围内的版本。
开源项目退出
开源项目版本在企业内已经没有研发项目使用时，则应将其从企业开源管理库中清理退出。
企业也可根据开源项目更新规范在满足更新条件时，强制将需更新的开源项目版本从企业开源管理库中清理退出，并通知仍在使用的项目立即更新。
开源项目使用规范
8.4.1开源项目使用方法
企业在使用开源项目时应遵循以下使用原则：
——应通过开源项目引入规范引入开源项目来使用，禁止自行随意使用开源项目；
——应从企业内的开源项目管理库获取开源项目的代码和制品，禁止自行从企业外部拉取代码和制品；
——应严格遵守开源项目所用开源许可证的要求；
——宜整体使用开源项目的版本，不宜仅使用开源项目的代码片段。
8.4.2研发项目开源软件清单
企业研发项目应明确本项目使用了哪些开源项目，维护一个所用开源项目列表，并确保其正确性。
8.4.3研发项目发布要求
企业研发项目在对外作为产品发布时应明确其使用开源项目的情况并满足开源许可证的要求，需提供：
——产品所包含的SBOM；
——产品所包含的开源项目的开源许可证；
——产品所包含的开源项目的版权声明；
——如产品所包含的开源项目的开源许可证有要求，需要提供所使用的开源项目代码以及衍生物代码。
8.4.4研发项目应急响应
企业研发项目应建立面向开源项目的应急响应机制，明确当开源项目出现严重的故障和安全漏洞后应该采取的措施，以及响应时间要求。
开源项目贡献
8.5.1开源贡献战略
企业宜根据自身产品和技术发展战略等原因，制定开源贡献策略，指引企业各产品和研发项目对外开源贡献工作。
8.5.2自发开源项目贡献
企业宜根据开源贡献战略将企业私有研发项目对外开源，即自发开源项目。
a)企业宜制定自发开源开源的贡献规范，其内容包括：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。