openharmony/community
1
0
Fork 0
mirror of https://gitee.com/openharmony/community synced 2025-02-18 13:59:08 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

!1593 OpenHarmony社区SBOM规范与指导

Browse Source 
* OpenHarmony社区SBOM规范
This commit is contained in:
高亮（Kubi） 2024-05-10 03:49:23 +00:00 committed by jinguang
parent 9f34e2faa2
commit bbc285dd1b
2 changed files with 325 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

322
sig/sig_compliance/docs/OpenHarmony社区SBOM规范与指导.md Normal file
View File

@ -0,0 +1,322 @@
# OpenHarmony社区SBOM规范与指导
## 目的
软件物料清单（Software Bill of Materials）后续缩写为SBOM，其本身在开源治理领域属于新兴的概念与规范，大量新的关于SBOM的行业规范指导与优秀实践正在不断涌现，为了帮助社区开发者及社区上下游组织，更好的理解、导入、消费OpenHarmony社区的SBOM，本文基于行业的各类各种规则规范和优秀实践结合OpenHarmony社区要求，对OpenHarmony社区在SBOM的定义、生成、消费、与上下游进行交换等主要活动进行规范和指导，以帮助社区更好的理解SBOM的术语、分类、能力等级、使用场景，并达成一致，同时满足在安全、合规、第三方开源软件管理等对社区SBOM的需求。
**特别说明：** 由于SBOM的规范和实践在国内和国外都发展的非常快速，本文中所做出的规定和指导，需要随新的标准规范发生变化，尽管本文会尽可能的与最新标准规范保持一致， 但若本规范中有与业界标准规范冲突之处，请以业界规范、标准为准，并欢迎反馈至本规范。
## 范围
本指导适用于OpenHarmony社区的发布版本（含正式版本、LTS版本、beta版本）
## 本文的改进和修订说明
1. 本文档由合规SIG主导起草和维护。最新版本可以在 [这里](OpenHarmony SBOM规范与指导.md)找到。
2. 任何对于本文中涉及的规则的增加，修改，删除都必须可追溯 。
3. 最终规则经过社区充分的讨论后，由PMC评审定稿。
## 术语和缩略语
| 术语 | 说明 |
| :------------ | :------------ |
| SBOM| 对源代码或二进制基于静态程序分析等技术进行规则检查，用于保障代码的规范、安全、合规 |
| 开源义务履行| 依据所使用开源软件中的开源许可证中所规定的条款要求，对条款规则中要求的义务项进行履行 |
| NOTICE| 即开源软件使用声明，是常见的许可证中规定的义务项所对应的交付件 |
## SBOM的定义
### SBOM的定义
什么是 SBOM
SBOM 是软件物料清单（Software Bill of Materials）的缩写。它是一份详细记录软件中使用的所有组件、库和依赖项的清单。包括开源软件组件、第三方库等。每个元素在 SBOM 中会有详细的信息，如名称、版本号、许可证信息、依赖关系等。
2021年7月12日美国在关于改善国家网络安全的行政命令（EO 14028第10节）中将SBOM定义为“包含构建软件中使用的各种组件的详细信息和供应链关系的正式记录”。
### SBOM的用途
SBOM 的目的是增加软件供应链的可见性和透明度，并提供更好的风险管理和安全性。它可以帮助软件开发者、供应商和用户了解其软件中使用的组件和依赖项，以便更好地管理潜在的漏洞、安全风险和合规性问题。通过 SBOM 用户可以识别和跟踪软件中存在的任何潜在漏洞或已知的安全问题，并及时采取相应的补救措施。
SBOM 还可以用于软件审计、合规性要求和法规遵从性等方面。一些行业标准和法规（如软件供应链安全框架（SSCF）和欧盟网络和信息安全指令（NIS指令））已经要求软件供应商提供 SBOM，以提高软件供应链的安全性和可信度。
### SBOM的分类
SBOM可在不同的软件声明周期内进行生成，因此SBOM也会存在因为生成的时间节点不同，而产生不同类型的SBOM，不同类型的SBOM各自尤其优势和限制，通常业界将其划分为以下几种类型
| SBOM分类| 定义 | 数据描述 | 优势 | 限制 |
| ------------- | ---- | -------- | ---- | ---- |
| Design SBOM | 早期阶段，成分可能不全，描述新软件 | 来自设计规范和一些初始概念 | 在引入前显示不兼容的软件 | 相比其他类型的SBOM，信息不够详细 |
| Source SBOM | 直接来源于开发环境中的源文件、以及用于构建的依赖信息 | 主要通过SCA之类工具进行分析，人工确认 |不兴国构建就可以提供可视信息，可以促进从源头开始避免引入致命/严重漏洞，提供依赖关系树，依赖+ 层次关系 |依赖于变成语言生态系统，可能不会包含运行态，插件、或者动态依赖，如系统库文等依赖其他类型来确保成分+依赖的完整性 |
| Build SBOM | 作为构建软件过程的一部分生成SBOM，已从源文件、依赖项、构建组件、构建过程临时数据和其他SBOM等数据创建可发布的制品| 典型场景是作为构建过程一部分，可能包含产生最终阀部件的构建中间+ 源SBOM | 随构建CI/CD流程产生，提升SBOM正确性保障，提供更多可见性，不仅仅时源代码。可以随产品发布件同一个构建流程进行签名，提升信任 |高度依赖构建执行的实际华景，对于间接依赖或运行依赖，在构建中铺货会比较困难。 |
| Analyzed SBOM | 构建后，通过第三方工具分析artifacts（可执行文件、包、容器）得到。类似分析方法通常需要探索性算法，一定意义上，通常成为第三方SBOM，Analyzed SBOM可以在一定程度上与提供方的SBOM验证正确性| 通常采用第三方工具对artifacts进行扫描/分析 | 不需要访问构建过程，可以作为其他类型SBOM数据验证 |如果工具无法精确分解或识别软件组件，可能容易出现遗漏、错误等。 |
| Deployed SBOM | SBOM提供系统上存在的软件清单。 这可能时其他SBOM的集合，它结合了配置选型的分析和部署环境中的执行行为检查 | 通常通过记录已安全在系统上的软件的SBOM和配置信息生成 | 显示系统上安装的软件，包括用于运行应用程序的其他配置和系统软件 | 可能会要修改安装/部署过程，可能无法准确描述运行环境 |
| Runtime SBOM | 通过检测运行软件的系统生成的SBOM，已仅捕获系统中存在的组件，以及外部标注或动态加载的组件。在某些情况下，这也可以成为“仪器化”或“动态”SBOM | 通常由与系统交互的工具生成，以记录运行环境中存在的或已执行的artifacts | 提升系统运行状况可见性，包括动态加载和外部链接，包括哪些被激活，哪些被使用的状态 | 需要在运行时分析系统，可能需要额外开销。有些详细信息可能需要系统运行一段时间后才能获得。 |
## OpenHarmony社区SBOM最小集规范
参照业界对于SBOM最小集的要求，结合OpenHarmony社区中安全治理、开源软件管理、开源合规治理诉求特对OpenHarmony社区SBOM进行以下三方面的规范
1. **SBOM各组件最小数据集** ：即SBOM清单中每个组件中至少（*必须*）需要包含的关键信息
2. **SBOM生成、消费流程及管理规范** ：即对于SBOM的生成、发布、消费、申请、访问、勘误等流程的规范
3. **SBOM自动化支持格式**：即SBOM清单在表达关键信息时需要遵从的格式、关键字、嵌套表达方式要求，此格式在SBOM生成和SBOM消费环节都需要使用，并且要做到*机器可读*。
### OpenHarmony社区安全治理、开源合规治理、开源软件管理诉求汇总
### OpenHarmony SBOM 各组件最小数据集规范
组件最小数据集是指作为每个组件必须包含的数据信息的集合，通过本数据集，应可以充分完整的追溯到该组件中成分的原始信息，再进一步基于这些最小集信息，可以根据不同的场景诉求，生成对应的满足安全治理、合规治理等SBOM信息。
| 最小集数据字段（英文） | 数据字段（中文 | 描述 |
| ------------------------- | ------------ | ----------------------------------- |
| Supplier Name | 供应商名称 | 创建，定义，识别此组件的组织或单位名称 |
| Component Name | 组件名 | 由原始供应商定义的组件名称Text |
| Version of the Component | 组件版本号 | 标识符，用于供应商标识与上一版本之前的变更 |
| Other Unique Identifiers | 其他标识符 | 其他可以用于标识一个组件的标识符 |
| Dependency Relationship | 依赖关系 | 表示依赖关系，如软件Y包含一个上游组件X |
| Author of SBOM Data | SBOM数据作者 | 创建此组件SBOM数据清单的组织或单位名称 |
| Timestamp | 时间戳 | SBOM数据清单生成的日期与时间 |
| 最小集数据字段（英文） | 数据字段（中文 | 描述 |
| ------------------------- | ------------ | ----------------------------------- |
| Hash of the Componet | 组件哈希值 | 组件的哈希值，确保组件的完整性 |
| Lifecycle Phase | SBOM生成阶段 | 不同阶段生成的SBOM不同，明确具体的生成时间点|
| Other Component Relationships| 其他类型组件关系 | 如衍生关系和后代关系 |
| License Information | 许可证信息 | 许可证信息，用于识别合规风险 |
### SBOM生成、消费流程及管理规范
SBOM不仅仅是一组清单数据，更重要的是将SBOM融于整个软件开发生命周期之中，按照一定策略进行治理和上下游交换的能力。
#### SBOM发布频率
OpenHarmony SBOM发布节奏跟随OpenHarmony社区版本发布节奏，其中Release版本及LTS版本会发布正式的SBOM，并持续对Release及LTS版本的SBOM信息进行维护和更新。 而beta版本仅对内部做SBOM的生成，主要用于验证SBOM机制的准确性和阶段性对beta版本数据进行校准，不进行后期的维护。
#### SBOM依赖软件深度
根据业界的实践，OpenHarmony SBOM至少需要包含全部主软件（顶层依赖），并应尽可能的提供更多信息，以便使用者可以根据主软件信息自行识别其传递依赖。对于下层依赖，OpenHarmony社区也应按照社区能力，持续加强支持深度，后续支持用户根据自身
需求选择SBOM中依赖软件的深度。
#### SBOM中已知的未知
业界中尽快有大量优秀实践，但都很难真正遍历全部下层依赖和成分，SBOM中必须对已知的没有进行深度依赖分析的情况，表示出known unknown（如spdx中使用NOASSERTION），用于区别出经过分析后确实没有下层依赖的情况，向SBOM使用者提示，对应的组件有可能含有下层依赖。
#### OpenHarmony SBOM 分发
OpenHarmony SBOM 当OpenHarmony软件版本发布后，在OpenHarmony数字化协作平台按版本进行归档，具有SBOM查看权限者，可以通过[此处](http://ci.openharmony.cn/workbench/opensource/thirdpartysource/bomlist/list)进行查阅。
OpenHarmony社区自身的服务可以通过基础设施的API接口获取相关数据进行进一步的治理与应用
#### OpenHarmony SBOM 访问控制
由于SBOM作为核心数据，本身的全量导出应有一定的访问控制，当前SBOM的访问权限定义为PMC成员 + 合规SIG Leader + 安全SIG Leader，但关于SBOM数据的应用结果，应向社区开放。
#### OpenHarmony SBOM 勘错
由于大型开源软件的复杂性，SBOM很难完全准确，社区通过[issue](https://gitee.com/openharmony/community/issues)来接收SBOM的错误，社区在确认后，即会定期更新SBOM的内容及新版本
### OpenHarmony SBOM自动化支持格式
当前业界具备共识的SBOM格式，主要有以下三种：
- Software Package Data eXchange([SPDX](https://spdx.dev/))
- [CycloneDX](https://cyclonedx.org/)
- Software Identification(SWID)tags
OpenHarmony社区在SBOM格式上当前重点支持SPDX和CycloneDX两种格式
#### SPDX格式的表达方式规范
SPDX 2.2 json格式
文件后缀要求： ·*.spdx.json
根据SPDX格式要求
![图片](https://spdx.github.io/spdx-spec/v2.2.2/img/spdx-2.2.2-document.png)
| NTIA SBOM Minimum Field | Satisfying SPDX field |
| --- | --- |
| Author Name | (6.8) Creator |
| Supplier Name | (7.5) Package Supplier |
| Component Name | (7.1) Package Name |
| Version String | (7.3) Package Version |
| Component Hash | (7.10) Package Checksum |
| Unique Identifier | (7.2) Package SPDX Identifier <br>(6.5) SPDX Document Namespace |
| Relationship | (11.1) Relationship:`CONTAINS`,`DESCRIBES` <br>The document must`DESCRIBES`at least one package. |
| Timestamp | (6.9) Created |
##### 组件表示方法
OpenHarmony SBOM SPDX格式规范
##### SPDX document creation information section
```
- "spdxVersion" : "SPDX-2.2", 当前固定SPDX-2.2
- "dataLicense" : "CC0-1.0", 当前固定CC0-1.0
- "SPDXID" : "SPDXRef-ability_lite"， ID命名规则。
- "name": "ability_lite-OpenHarmony_4.0" ， 为DocumentName文档名，命名规则 XXX-YYY, 其中XXX为组件名，YYY为该组件对应版本号
- "documentNamespace" : null， 当前为null，后续sbom资源归档至网站后，使用此格式进行填充"http://[CreatorWebsite]/[pathToSpdx]/[DocumentName]-[UUID]"
- "creationInfo" : {
"created" : "2010-01-29T18:30:22Z", SBOM初始创建时间 YYYY-MM-DDThh:mm:ssZ **对应NTIA中Timestamp**
"creators" : [ "Organization: OpenHarmony" ] SBOM创建的实体组织名称，**对应NTIA中Author Name**，OpenHarmony SBOM 缺省填写OpenHarmony
}
```
##### SPDXID 命名规则
- SBOM 清单文档 : SPDXRef-DOCUMENT
- 产品大包： SPDXRef-PRODUCT
- 源码仓： SPDXRef-SOURCE-源码仓
- 第三方上游软件： SPDXRef-UPSTREAM-软件名
- 文件/二进制： SPDXRef-路径，其中/改为-
- 软件包：SPDXRef-Package-包名
##### Package information section
```
"packages" : [ {
"SPDXID" : "SPDXRef-SOURCE-ability-ability_lite", **SPDXID 命名规则** 。
"filesAnalyzed" : "true", **相较SPDX额外作为必选**， 基于源码的SBOM，此字段为true，即可以基于此组件进行文件级分析，基于构建制品的SBOM，需按场景使用，若有两组件静态链接的情况，A静态链接B，A把B包含了，B组件需要写package，但在此字段需要填false，并在relationship中标识静态链接关系。
"name" : "ability_base", 组件全名，要求为**原始组件全名**，若为第三方软件，则写上游软件名， **对应NTIA中的Component Name**
"supplier" : "Organization: OpenHarmony", **相较SPDX额外作为必选**， **对应NTIA中的Supplier Name**，实际分发者，不一定与原始分发者一致，不能只是分发网站，要对应组织名，当前OpenHarmony的源，均为OpenHarmony分发，第三方软件亦是由OpenHarmony仓库托管分发
"versionInfo" : "OpenHarmony-4.0-Release" **相较SPDX额外作为必选**，**对应NTIA中的Version of the Component**组件版本信息，用于表示版本变化，
"PackageFileName"："./myrootdir/mysubdir1 or glibc-2.11.1.tar.gz" **相较SPDX额外作为必选**， 源码使用下载后的源码路径，软件包使用包名
"originator" : "Organization: ExampleCodeInspect (contact@example.com)", **相较SPDX额外作为必选**，原始供应商，自研组件填写OpenHarmony,第三方组件填写上游原始供应商
"downloadLocation" : "http://ftp.gnu.org/gnu/glibc/glibc-ports-2.15.tar.gz", 软件下载地址，自研组件 可按以下方式git地址+tag点方式，若无tag点，可以使用分支 "git+https://git.myproject.org/MyProject.git@v1.0"
"packageVerificationCode" : { 当 filesAnalyzed为true时，填写以下字段，当 filesAnalyzed为false时，不填写
"packageVerificationCodeExcludedFiles" : [ "./package.spdx" ],
"packageVerificationCodeValue" : "d6a770ba38583ed4bb4525bd96e50461655d2758"
}
"checksums" : [ { **相较SPDX额外作为必选**， **对应NTIA中的Component Hash**， 基于构建制品的SBOM必填此字段，基于源码的SBOM，同packageVerificationCode
"algorithm" : "SHA1",
"checksumValue" : "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12"
} ],
"homepage" : "http://ftp.gnu.org/gnu/glibc", **相较SPDX额外作为必选**，三方组件填上游社区网址，自研组件统一填OpenHarmony首页https://www.openharmony.cn/mainPlay
"licenseConcluded" : "(LGPL-2.0-only OR LicenseRef-3)", **相较SPDX额外作为必选** **对应NTIA中的License Information** 由SBOM创建者推论的该组件的许可证信息，可借助扫描工具，必须为SPDX License Expression
"licenseInfoFromFiles" : [ "GPL-2.0-only", "LicenseRef-2", "LicenseRef-1" ], **合规必选****相较SPDX额外作为必选**，作为推论许可证中的参考依据，应包含组件中全量许可证信息，在此不做许可证间关系说明，由工具扫描文件级许可证，必须为SPDX License Expression
"licenseDeclared" : "(LGPL-2.0-only AND LicenseRef-3)", **合规必选****相较SPDX额外作为必选**，仅包含原始作者对许可证的声明，不包含第三方库的许可证信息。
"licenseComments" : "The license for this project changed with the release of version x.y. The version of the project included here post-dates the license change.", **合规必选**
"copyrightText" : "Copyright 2008-2010 John Smith", **合规必选** 可多行
"description" : "The GNU C Library defines functions that are specified by the ISO C standard.", **开源管理必选**
"externalRefs" : [ { **相较SPDX额外作为必选**, **对应NTIA中的Unique Identifier**
"referenceCategory" : "PACKAGE-MANAGER",
"referenceLocator" : "pkg:gitee/openharmony/ability_ability_base@OpenHarmony-v4.0-Release",
"referenceType" : "purl"
}, {
"referenceCategory" : "SECURITY",
"referenceLocator" : "cpe:2.3:a:pivotal_software:spring_framework:4.1.0:*:*:*:*:*:*:*",
"referenceType" : "cpe23Type"
}],
"primaryPackagePurpose" : "SOURCE", **相较SPDX额外作为必选** **开源管理必选**, 标识软件包属性，应用hap使用APPLICATION;应用框架使用FRAMEWORK; 单一功能库使用LIBRARY;容器镜像使用CONTAINER; 操作系统OS使用OPERATING-SYSTEM;芯片及开发板相关使用DEVICE;驱动等底软使用 FIRMWARE， 当前组件为多个源码文件的集合使用SOURCE; 当前为压缩包(.tar, .zip等）使用ARCHIVE; 独立可分发的单文件使用FILE ; 如果仅用于安装软件的工具使用INSTALL，未被上述领域覆盖的使用OTHER.
"releaseDate" : "2012-01-29T18:30:22Z", **开源管理必选** 版本发布时间
"validUntilDate" : "2014-01-29T18:30:22Z", ***开源管理必选** EOS时间
```
##### File information section
根据SBOM的不同深度等级，可以补充每个package下的文件级SBOM信息，当前优先完成package级的SBOM定义，文件级SBOM在第二版进行支持和定义
```
{
"filename":"/system/lib/libdXXX.so" **构建SBOM额外作为必选**
"SPDXID":"SPDXRef-system-lib-libdXXX.so"
"checksums": [
{
"algorithm":"SHA1",
"checksumValue": "279XXXXXXXXXXXXXXXXXXXX"
}
]
}
```
##### Snippet information section
由于OpenHarmony社区中禁止对第三方开源代码片段引用，因此SBOM中不在单独定义Snippet的使用格式与规范
##### Other licensing information detected section
```
"hasExtractedLicensingInfos" : [ { **开源合规必选** 非SPDX标准License， 需要补充以下字段
"licenseId" : "LicenseRef-1",
"extractedText" : "/*\n * (c) Copyright 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Hewlett-Packard Development Company, LP\n * All rights reserved.\n *\n * Redistribution and use in source and binary forms, with or without\n * modification, are permitted provided that the following conditions\n * are met:\n * 1. Redistributions of source code must retain the above copyright\n * notice, this list of conditions and the following disclaimer.\n * 2. Redistributions in binary form must reproduce the above copyright\n * notice, this list of conditions and the following disclaimer in the\n * documentation and/or other materials provided with the distribution.\n * 3. The name of the author may not be used to endorse or promote products\n * derived from this software without specific prior written permission.\n *\n * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR\n * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES\n * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.\n * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,\n * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT\n * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,\n * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY\n * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT\n * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF\n * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\n*/"
}, {
"licenseId" : "LicenseRef-Beerware-4.2",
"comment" : "The beerware license has a couple of other standard variants.",
"extractedText" : "\"THE BEER-WARE LICENSE\" (Revision 42):\nphk@FreeBSD.ORG wrote this file. As long as you retain this notice you\ncan do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp",
"name" : "Beer-Ware License (Version 42)",
"seeAlsos" : [ "http://people.freebsd.org/~phk/" ]
}, {
},
```
##### Relationships between SPDX elements information section
```
{ **相较SPDX额外作为必选** **对应NTIA中的Relationship和Other Component Relationships**
"spdxElementId" : "SPDXRef-Package", **通过此字段来表达动静态依赖关系。**
"relationshipType" : "DYNAMIC_LINK",
"relatedSpdxElement" : "SPDXRef-Saxon"
}, {
"spdxElementId" : "SPDXRef-JenaLib", **后续通过此字段来表达软件中的包含关系如A软件代码仓中包含B软件成分。**
"relationshipType" : "CONTAINS",
"relatedSpdxElement" : "SPDXRef-Package"
}， {
"spdxElementId" : "SPDXRef-SOURCE-openXXX",
"relationshipType" : "VARIANT_OF", **后续通过此字段来表达三方软件在OpenHarmony的衍生版本。**
"relatedSpdxElement" : "SPDXRef-UPSTREAM-openXXX"
}，
{
"spdxElementId" : "SPDXRef-Package-A",
"relationshipType" : "DEPENDS_ON", **后续通过此字段来表达A依赖B。**
"relatedSpdxElement" : "SPDXRef-Package-B"
}
}
```
#### cycloneDX格式的表达方式规范
cycloneDX 1.5 json格式
```
{
"bomFormat":"CycloneDX",
"specVersion": "1.5",
"serialNumber":"urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79"" **相较CycloneDX额外作为必选**， 唯一标识
"version"：“1” **相较CycloneDX额外作为必选**， 用作标识对已有SBOM的修改版本信息
"metadata":{
"timestamp": "2024-03-17 18:00:00", **相较CycloneDX额外作为必选**,**对应NTIA中Timestamp**
"lifecycles": "design" **对应NTIA中Lifecycle Phase** design/pre-build/build/post-build/operations/discovery/decommission https://cyclonedx.org/docs/1.5/json/#metadata_lifecycles
"supplier": {
"name":"OpenHarmony" **相较CycloneDX额外作为必选**， **对应NTIA中的Supplier Name**，实际分发者，不一定与原始分发者一致，不能只是分发网站，要对应组织名，当前OpenHarmony的源，均为OpenHarmony分发，第三方软件亦是由OpenHarmony仓库托管分发
}
}
"components":{
[{"type":"library", application/framework/library/container/platform/operating-system/device/device-driver/firmware/file/machine-learning-model/data
"suppiler": {
"name":"OpenHarmony" **相较CycloneDX额外作为必选**， **对应NTIA中的Supplier Name**，实际分发者，不一定与原始分发者一致，不能只是分发网站，要对应组织名，当前OpenHarmony的源，均为OpenHarmony分发，第三方软件亦是由OpenHarmony仓库托管分发
} ,
"author":" Inc",
"name":"tomcat-catalina",
"version":"9.0.14" **相较CycloneDX额外作为必选**，**对应NTIA中的Version of the Component**组件版本信息，用于表示版本变化，
"hashes": {
"alg": "SHA-256",
"content": "3942447fac867ae5cdb3229b658f4d48"
},
"licenses":[{
"license":{
"id": "Apache-2.0", **相较CycloneDX额外作为必选**,以spdxid为准
},
},{}]，
"copyright":"XXXX Inc",
"cpe":"cpe:2.3:a:acme:component_framework:-:*:*:*:*:*:*:*",
"purl"："pkg:maven/com.acme/tomcat-catalina@9.0.14?packaging=jar"，
"pedigree": { **相较CycloneDX额外作为必选，要求第三方软件必选** **对应NTIA中的Other Component Relationships**
"ancestors":{Component object}, 找到fork的上游软件，并进行描述，如果遇到openEuler小包，则在ancestors内，进一步嵌套找到上游软件。
"variants":{Component object}, 识别不清具体关系的放在此处，但是知道有相关性，可以用于工具中的成分识别
"commits":[{
"uid":"commit id",
"url": "",
"message": "content of commit"
},{
...
}
],
"patches":[{
"type":"backport", unofficial/monkey/backport/cherry-pick
"diff": "text",
"resolves": {
"type": "defect" defect/enhancement/security
"id":""
}
},{}]
}
}, {
....
}
]
}
}
```

6
sig/sig_compliance/docs/开源合规角色职责及能力要求.md
View File

@ -1,7 +1,7 @@
| 示例角色 | openharmony社区对应角色 | 角色代码 | 姓名 | 角色描述 | 能力和理解力（概要） | 能力和理解力（详情） | 主要职责 |
|---------------|--------------------|------------|-------------|--------------------------------------------------------------|-------------------------------|---------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 开源合规委员会成员 | 工委会执行总监 | cbm | 张明修 | openharmony工委会执行总监，全面负责社区开源合规和战略。问题从开源合规主管上报给工委会 | 知识产权风险（开源）、开发过程 | 社区治理架构、沟通技巧 | 工委会执行总监负责：应负责openharmony 社区整体开源合规政策的审定，关键合规行为的审核和授权，重大合规问题的统筹，负责社区的外联职责，包括社区联络、项目社区管理和回答有关社区开源战略的一般性问题 |
| 开源合规主管 | 合规sig leader | clead | 陈雅旬 | 合规sig leader，负责社区开源合规日常执行。向openharmony工委会及pmc成员报告 | 社区治理、开源政策（流程）、软件架构 | 知识产权风险、开发过程、沟通技巧 | 开源合规主管应负责： 应主要负责解决日常内部合规问题，以及更新和审核本政策。a.审核、实施和传达本政策；b.审核和实施开源合规相关问题的培训和评估；c.对已识别的许可证进行分类；d.不断评估有关开源合规的最新问题，包括参与适当的论坛、用户组和邮件列表，并定期与法律[和合规]顾问保持联系；e.让openharmony工委会成员了解受开源政策影响的活动的最新情况; |
| 开源合规委员会成员 | 工委会执行总监 | cbm | 柳晓见 | openharmony工委会执行总监，全面负责社区开源合规和战略。问题从开源合规主管上报给工委会 | 知识产权风险（开源）、开发过程 | 社区治理架构、沟通技巧 | 工委会执行总监负责：应负责openharmony 社区整体开源合规政策的审定，关键合规行为的审核和授权，重大合规问题的统筹，负责社区的外联职责，包括社区联络、项目社区管理和回答有关社区开源战略的一般性问题 |
| 开源合规主管 | 合规sig leader | clead | 高亮 | 合规sig leader，负责社区开源合规日常执行。向openharmony工委会及pmc成员报告 | 社区治理、开源政策（流程）、软件架构 | 知识产权风险、开发过程、沟通技巧 | 开源合规主管应负责： 应主要负责解决日常内部合规问题，以及更新和审核本政策。a.审核、实施和传达本政策；b.审核和实施开源合规相关问题的培训和评估；c.对已识别的许可证进行分类；d.不断评估有关开源合规的最新问题，包括参与适当的论坛、用户组和邮件列表，并定期与法律[和合规]顾问保持联系；e.让openharmony工委会成员了解受开源政策影响的活动的最新情况; |
| 开源合规法律顾问 | 法务与合规组组长 | extcounsel | 沈芬/余甜 | 负责接受与开源许可问题相关的外部咨询，并负责确保按照开源政策进行处理。就开源许可的合规和流程提供法律建议。 | 社区治理、开源政策（流程）、软件架构 | 知识产权风险和许可问题、开源政策和流程（法律问题）、开源许可。 | 法务与合规组组长负责为a.协助pmc及合规sig进行项目相关代码的合规管控工作，包括但不限于评审项目代码扫描结果，分析许可证相关问题等；b.制订和修改本开源项目相关的各法律合规制度；c.参与和设计本开源项目合规赋能方案、整体战略合规体系等;d.本开源项目日常合规审查及合规纠纷支撑处理；e.向openharmony工作委员会等openharmony项目治理组织提供法律咨询意见; |
| 开发组组长/开源联络人 | pmc 主席 | devlead | 任革林 | pmc主席，负责新技术项目引入和孵化流程、社区技术治理和运作规范流程 | 社区治理、开源政策（流程）、软件架构 | 知识产权风险和许可问题、团队管理结构、开源政策、编码技巧。沟通技巧。管理技能。 | 负责整体协调开源合规与社区规划、特性开发及issue处理工作 a.负责社区管理工作，包括开源社区版本规划、架构看护、特性代码开发维护、版本及补丁规划等；b.发布和处理社区需求，为开源社区提供技术架构指导和技术决策；c.处理社区bug、issue、邮件列表等渠道开发者反馈问题；d.负责pmc、committer成员的 选举和退出，制定pmc、committer协作机制； |
| 架构师 | 架构sig leader | arch | 任革林 | 架构sig leader，负责制定openharmony架构设计原则，oopenharmony架构定义、设计、演进和看护 | 社区开发治理。 openchain 政策和计划。 | openharmony整体架构。了解行业标准和市场发展。了解架构选择引发的知识产权问题。对产品功能的深入了解。沟通技巧。了解客户需求。 | 负责开源三方见选型符合开源合规要求 a.负责openharmony架构（包括子系统/部件/代码仓的增加，合并，拆分和删除）相关的设计评审，《架构设计原则》和《openharmony 系统架构》修订。b.负责新增三方开源软件选项评估，包含合规中license审核 |
@ -13,6 +13,6 @@
| 内部openchain讲师 | 合规sig committer | octrain | 高亮 | 就社区实施 openchain 规范对项目人员进行培训 | 社区开源合规治理 | openchain 目标、政策、社区实践和计划、沟通技巧 | 负责openharmony openchain规范的布道和落地，负责推进openharmony社区 通过openchain认证 |
| 扩展角色 | 合规sig-合规流程规范文档组组长 | | 高亮 | 负责拟定和起草合规流程及文档 | 社区开发治理。 openchain 政策和计划。 | 了解社区合规开发流程 | 负责拟定和起草合规流程及文档 ，如以下1. 《开源政策指导》;2. 《合规角色、职责、要求》;3. 《开源合规类issue管理指导》; 4. 《义务履行交付制品说明》 等" |
| 扩展角色 | 合规sig-合规知识体系及布道推广组 | | 赵鹏（软通） | 负责制定合规培训计划等 | 社区开发治理。 openchain 政策和计划。 | 了解业界最佳合规实践，了解推广布道方式 | 负责组织洞察和了解合规业界最佳实践，负责制定布道推广计划 |
| 扩展角色 | 合规sig-工程工具组 | | 杨灏为 | 负责合规工具链 | 社区开发治理。 openchain 政策和计划。 | 了解业界合规工具链最佳实践，熟悉社区开发流程 | 负责openharmony 合规工具链的设计和实现 |
| 扩展角色 | 合规sig-工程工具组 | | 陈岱行 | 负责合规工具链 | 社区开发治理。 openchain 政策和计划。 | 了解业界合规工具链最佳实践，熟悉社区开发流程 | 负责openharmony 合规工具链的设计和实现 |
| 扩展角色 | 合规sig-合规评审及治理组 | | 陈一雄 | 负责合规评审及治理 | 社区开发治理。 openchain 政策和计划。 | 了解业界合规治理最佳实践，熟悉社区开发流程 | 负责openharmony社区孵化毕业及版本发布中开源合规相关评审 |