|
| 1 | +# OpenChain安全保证规范V1.1自我认证清单 |
| 2 | + |
| 3 | +本清单是组织检查一致性的简单 |
| 4 | + |
| 5 | +方法修订版1 |
| 6 | + |
| 7 | +2022-10-14 |
| 8 | + |
| 9 | +简体汉语翻译人:张俊霞。 |
| 10 | + |
| 11 | +本中文翻译文本采用与英文版本相同的知识共享协议授权。 |
| 12 | + |
| 13 | +翻译时间:2022-10-15 |
| 14 | + |
| 15 | +# 介绍 |
| 16 | + |
| 17 | +OpenChain安全保证规范旨在识别和描述在使用开源软件背景下的实施质量安全保证计划的关键要求。它专注于狭义的主要关注问题:检查开源软件是否存在已知的安全漏洞(如通过CVE、GitHub/GitLab漏洞报告等公开)。 |
| 18 | + |
| 19 | +您可以在自己合适的时间通过进行自我认证,或与服务提供商合作进行独立评估,或第三方认证等方式,来采标OpenChain安全保证规范。我们推荐的路径是自我认证,我们提供这份文件,以一系列“是”或“否”的陈述来支持这一点。如果你能对每件事都回答“是”,你就是符合自我认证要求的。如果您对某些问题回答“否”,也有助于您知道在哪里应该投入更多时间来构建质量计划。 |
| 20 | + |
| 21 | +如果您需要帮助,我们有很多资源来支持您。您可以加入我们的邮件列表、网络研讨会、我们的小组电话会议和我们的区域工作组,以您的母语、与您的同行讨论这些安全问题带来的挑战。您可以从这里开始: |
| 22 | +[https://www.openchainproject.org/community]{.underline} |
| 23 | + |
| 24 | +最后,如果您希望获得该项目的直接支持,您可以发送电子邮件至 [[email protected]]{.underline}并提出问题。我们提供免费支持。OpenChain项目由我们的白金会员资助,旨在帮助支持全球供应链向更有效、更高效的开源许可协议合规过渡。 |
| 25 | + |
| 26 | +# 自我认证清单 |
| 27 | + |
| 28 | +第3.1.1节 |
| 29 | + |
| 30 | +- [ ] 我们有一个关于所提供软件开源安全保证的政策。 |
| 31 | +- [ ] 我们有一个记录在案的程序,可以向组织内所有软件人员传达开源策略的存在。 |
| 32 | + |
| 33 | +第3.1.2节 |
| 34 | + |
| 35 | +- [ ] 我们已经确定了影响该计划绩效和有效性的角色和责任。 |
| 36 | +- [ ] 我们已明确并梳理、记录了每个角色所需的能力。 |
| 37 | +- [ ] 我们确定并记录了一份计划参与者名单,以及他们应如何履行各自的角色。 |
| 38 | +- [ ] 我们对每个项目参与者进行了能力评估,并进行了记录。 |
| 39 | +- [ ] 我们对安全治理情况定期审查、对流程更改优化,并进行记录。 |
| 40 | +- [ ] 我们有办法证明我们的流程符合当前的公司最佳做法和员工任务分配。 |
| 41 | + |
| 42 | +第3.1.3节 |
| 43 | + |
| 44 | +我们记录了我们的计划参与者对以下主题的认识: |
| 45 | +- [ ] 开源安全保证政策以及在哪里可以找到它; |
| 46 | +- [ ] 相关的开源目标; |
| 47 | +- [ ] 预期的贡献,以将确保该计划的有效性; |
| 48 | +- [ ] 未能遵循计划要求的影响。 |
| 49 | + |
| 50 | +第3.1.4节 |
| 51 | + |
| 52 | +- [ ] 我们有一个书面声明,明确界定了该计划的范围和限制。 |
| 53 | +- [ ] 我们有一套指标来衡量计划的绩效。 |
| 54 | +- [ ] 我们的每次审查、更新或审计中都有记录作为证据,以证明组织的持续改进。 |
| 55 | + |
| 56 | +第3.1.5节 |
| 57 | + |
| 58 | +- [ ] 我们有一个方法,以识别所提供软件的结构和技术威胁; |
| 59 | +- [ ] 我们有一个方法,以检测所提供软件中是否存在已知漏洞; |
| 60 | +- [ ] 我们有一个方法,来跟进已识别的已知漏洞; |
| 61 | +- [ ] 我们有一个方法,在需要时将已识别的已知漏洞传达给客户群; |
| 62 | +- [ ] 我们有一个方法,在所提供软件发布后分析新发布的已知漏洞所带来的威胁; |
| 63 | +- [ ] 我们有一个方法,来保障对所有提供的软件在发布前进行持续和重复的安全测试; |
| 64 | +- [ ] 我们有一种方法,来验证已识别的风险在所提供的软件发布之前已得到解决; |
| 65 | +- [ ] 我们有一个方法,可以酌情向第三方输出有关已识别风险的信息。 |
| 66 | + |
| 67 | +第3.2.1节 |
| 68 | + |
| 69 | +- [ ] 我们有一个方法,允许第三方进行已知漏洞或新发现的漏洞查询(例如,通过由计划参与者监控的电子邮件地址或门户网站); |
| 70 | +- [ ] 我们有一个内部文档化程序,用于回复第三方已知漏洞或新发现的漏洞查询。 |
| 71 | + |
| 72 | +第3.2.2节 |
| 73 | + |
| 74 | +- [ ] 我们已经记录了与该计划相关的人员、团体或职能; |
| 75 | +- [ ] 我们已确保,对已确定的项目角色配备了适当的人员,并提供了充足的资源(如资金); |
| 76 | +- [ ] 我们已确保,已经具有专业知识来解决已识别的已知漏洞; |
| 77 | +- [ ] 我们有一个书面程序,分配安全保证的内部责任。 |
| 78 | + |
| 79 | +第3.3.1节 |
| 80 | + |
| 81 | +- [ ] 我们有一个文档化的程序,确保在所提供软件的整个生命周期内持续记录所提供软件中使用的所有开源软件。这包括所提供软件中使用的所有开源软件的存档。 |
| 82 | +- [ ] 我们有所提供软件的开源组件记录,证明我们正确遵循了记录的程序。 |
| 83 | + |
| 84 | +第3.3.2节 |
| 85 | + |
| 86 | +- [ ] 我们有一个文档化的程序,用于处理所提供软件中开源组件的已知漏洞的检测和解决情况。 |
| 87 | +- [ ] 我们有所提供软件的开源组件记录,用于跟踪已识别的已知漏洞和采取的行动(即使不需要采取任何操作)。 |
| 88 | + |
| 89 | +第3.4.1节 |
| 90 | + |
| 91 | +- [ ] 我们有书面文件,以确认该计划符合本规范的所有要求。 |
| 92 | + |
| 93 | +第3.4.2节 |
| 94 | + |
| 95 | +- [ ] 我们有文件证实,在过去18个月内坚持了开源软件安全保证计划。 |
| 96 | + |
| 97 | + |
| 98 | + |
| 99 | + |
| 100 | + |
| 101 | + |
| 102 | + |
| 103 | + |
0 commit comments