Merge pull request #37 from sectrend-feng/patch-2

Create OpenChain Security Assurance Specification 1.1 Self-Certificat…

Author: shanecoughlan

Self-Certification/Questionnaire/Security-Assurance-1.1/cn/OpenChain Security Assurance Specification 1.1 Self-Certification Questionnaire_CN_Simplified.md

@@ -0,0 +1,262 @@
+
+# 《OpenChain安全保证规范》1.1自行认证调查问卷
+
+## 检查项目是否符合规范最简单的方式
+
+版本：第1版
+
+英文版发布日期：2022年10月15日
+
+翻译：王峰 上海安势信息技术有限公司
+
+简体中文版发布日期：2022年11月9日
+
+# 背景及介绍
+
+《OpenChain安全保证规范》旨在指明和描述在使用开源软件的过程中高质量安全保证计划的关键要求。它明确关注的是整个开源安全中一个子集：通过公开的安全漏洞（如CVE）和GitHub/GitLab发布的漏洞报告等方式审查开源软件。
+
+你可以花一些时间通过自行认证的方式或与相关服务提供商合作进行独立评估或第三方认证来对《OpenChain安全保证规范》进行认证。我们推荐的途径是自行认证，本文档用一系列回答"是"或"不是"的问题来帮助你进行自行认证。如果你能对所有问题回答 "是"，就意味着你通过了自行认证。如果你对其中某些项目的回答是"否"，你就可以知道在哪些地方进一步加大投入来开发一个高质量的软件。
+
+如果需要帮助，我们有很多资源来帮助你。你可以加入我们的邮件发送清单，网络研讨会，小组交流会议和区域化的工作小组，与同行用母语讨论过程中遇到的挑战。
+你可以从这里开始探索：<https://www.openchainproject.org/community>
+
+最后，如果你希望得到本项目更为直接的支持，你可以通过电子邮件 <[email protected]> 提出问题。我们提供的所有支持均是免费的。OpenChain项目由我们的白金会员资助，旨在支持全球软件供应链向更有效和高效的开源许可合规转型。
+
+# 自行认证调查问卷
+
+## 第 3.1.1 节
+
+你是否有成文的制度来保障所提供的软件具有开源代码安全保证？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否有成文的步骤告知所有软件研发相关人员本组织存在开源制度？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.1.2 节
+
+你是否确定了会影响本计划执行效果和有效性的角色和相应的责任？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否确认并记录了每个角色所应该具备的能力？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否确认并记录了计划参与者的名单，以及他们如何履行各自的职责？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否对每个计划参与者的能力评估做了记录？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否有方法记录针对本流程的定期审查和修改？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否有办法核实这些规定的流程与公司当前的最佳实践和员工任务分配相一致？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.1.3 节
+
+你是否通过文档记录了开源安全保障制度，并确保计划参加者知道在哪里可以找到这些记录？
+
+- [ ] 是
+
+- [ ] 否
+
+您是否通过文档记录了针对开源的相关目标，并确保计划参加者知道在哪里可以找到这些记录？
+
+- [ ] 是
+
+- [ ] 否
+
+您是否通过文档记录了为确保本计划的有效性而需要做的工作，并确保计划参加者了解这一点？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否通过文档记录了不遵守计划要求的后果，并确保计划参加者了解这一点？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.1.4 节
+
+你是否有书面声明来明确界定本计划的范围和限制？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否有一套衡量本计划效果的指标？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否有在每次审查、更新或审计后都留下了证据来体现持续的改进？
+
+- [ ] 是
+
+- [ ] 否
+
+
+## 第 3.1.5 节
+
+你是否可以识别所提供软件的结构和技术方面的威胁？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以检测所提供的软件中存在的已知漏洞？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以对发现的已知漏洞进行跟踪？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以在必要时向客户沟通发现的已知漏洞？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以分析所提供的软件在发布后新公布的已知漏洞？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以在发布前对提供的软件进行持续和重复的安全测试？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以验证在发布提供的软件之前得到确认的风险已被解决？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否可以酌情向第三方输出有关已识别风险的信息？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.2.1 节
+
+你是否可以通过一些方式允许第三方查询已知的漏洞或新发现的漏洞（例如，通过电子邮件或由计划参加者跟踪的网站）？
+
+- [ ] 是
+
+- [ ] 否
+
+对于回应第三方的已知漏洞或新发现的漏洞查询的流程，你是否有内部文档？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.2.2 节
+
+你是否通过文档记录了与本计划有关的人员、组织和职能？
+
+- [ ] 是
+
+- [ ] 否
+
+您是否可以确保为参与计划的相关角色配备适当的人员，并提供足够的资金？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否确保可以使用专业的知识或者人才解决被发现的已知漏洞？
+
+- [ ] 是
+
+- [ ] 否
+
+你是否有成文的规定来在内部划分安全保障项目的责任？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.3.1 节
+
+你是否有成文的步骤来确保在所提供的软件中使用的所有开源代码在其生命周期内被持续记录？这包括对所提供软件中的所有开源软件进行存档。
+
+- [ ] 是
+
+- [ ] 否
+
+你是否对所提供的软件的中的开源组件进行了记录，来证明它们遵循了内部针对开源组件的相关要求？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.3.2 节
+
+针对所提供的软件中开源组件的已知漏洞，你是否具有成文的步骤来进行识别和处理？
+
+- [ ] 是
+
+- [ ] 否
+
+针对所供应软件中开源组件中被识别的已知漏洞的追踪和处理（即使不需要采取行动），你是否有相关的记录？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.4.1 节
+
+你是否有文档证明本项目符合规范中的所有要求？
+
+- [ ] 是
+
+- [ ] 否
+
+## 第 3.4.2 节
+
+你是否有文档证明在过去18个月内对项目的一致性进行了审查？
+
+- [ ] 是
+
+- [ ] 否
+
+## 下一步的工作
+
+如果你已经按照本规范进行了自行认证，请通过电子邮件告知我们，[[email protected]](mailto:[email protected])。我们希望在OpenChain网站上添加贵组织的Logo。这是一个可选项，但对我们的工作非常重要。