直播回顾 | BSI&安在系列专题研讨（第二期）：供应链安全

11月8日，BSI联合安在围绕新版ISO/IEC 27001举行系列专题研讨线上直播会，内容涵盖供应链安全、安全运营、数据安全等等，专题研讨直播活动将贯穿11月和12月，并将于12月召开线下交流会。

本期直播即为系列直播的第二期，话题为“供应链安全”。此次受邀嘉宾有BSI审核专家姚丽娟、悬镜安全COO董毅、某电商科技公司安全专家杨文斌、某金融科技公司安全专家蔚晨。此次直播由BSI中国区ICT产品线技术总监万鑫担任主持。

姚丽娟从三个方面介绍了ISO 27001：2022。首先是标题的变化，ISO 27001：2022的标题改为信息安全、网络安全和隐私保护，信息安全管理体系要求其与ISO 27002：2022的标题一致。从标题中不难看出，新版ISO 27001的标准更加注重网络安全和隐私保护。

随着近年来国内和国际局势日益严峻，网络安全事件和隐私数据泄露事件频发，个人敏感数据的泄露、勒索软件、黑客攻击等层出不穷，可以看到有组织、有目的的网络攻击形式愈发明显。而ISO 27001新版标准顺应时代的潮流，与时俱进，通过增强网络安全和隐私保护的控制，达成了组织的全面安全目标。

第二部分是正文的变化，主要变化内容在于信息安全管理体系中明确了过程控制的安全。通过在信息安全管理体系中识别组织的业务过程，建立过程标准和推进过程的实施，使信息安全管理体系与组织业务过程紧密融合，促进组织业务的可持续发展。

正文内容的主要变化与其他采用高阶架构的ISO标准（比如9001）的描述更一致了，更能确保信息安全、网络安全、隐私安全融入到组织识别的业务过程中。

第三部分的变化是在附录a中，附录a的标题改成了“信息安全控制措施参考”，同时具体的控制措施也做了相应的修订，为了与新版27002的标准保持一致。其中只有控制的描述来自于27002，其他元素比如控制的目的和属性并没有包括在27001的附录a中，实施27001新标准的组织应参考该指导标准。

此外，在附录a中增加了11个新的控制措施，其中与网络安全和隐私保护相关的有八项。新增的控制措施基本上是当前业界优秀的信息安全控制实践，这些具有普遍性的优秀实践在新版标准中得到了固化和明确，并将惠及更多通过信息安全管理体系达成安全运营和持续发展的组织。

姚丽娟表示，新版标准整体上的逻辑更加严密，控制措施的可用性更强，整体安全控制更加全面，也更加贴合新时代、新技术、新发展中组织的安全需求。同时，新版27001更加关注过程控制，这与ISO 27034应用安全标准非常契合。

27034的过程框架通过一组组件、过程和框架，帮助组织在可接受的安全成本下获取、实施和使用可信的应用，27034引入了应用控制、安全控制等集合的理念，通过识别、选择应用安全控制，结合应用安全管理的过程控制，以达到软件系统可信的目标。

万鑫分享了一组数字。某软件供应链公司的研究报告表示，过去一年里，由第三方软件供应链引起的恶意攻击比例上升了633%，目前已经超过了88000起。报告还分析了企业常见的一些软件库，大概有12000个软件库，其中有10%的软件库其本身在代码里就直接存在漏洞，而这个库被应用在了软件里，成为组件被依赖、被继承后，此漏洞的上升率会提高到62%。

事实上每一个软件都有其软件依赖，平均下来一个库大概有5.7个依赖。所以可以看到，由于对IT系统、对网络有所依赖，这些软件和软件库的漏洞就会对企业造成重大的影响。

当下企业的现状是，软件工程看上去更像是积木工程，所做的内容就是将前人的一些预制件进行调试、进行装配，这就导致了软件供应链安全变成了一项非常庞大的工作，得从全生命周期的角度去解决。

万鑫指出，在27001标准的软件安全视图里，包括了十条控制措施，其中有五条和生命周期相关，另五条控制措施和软件的项目管理以及使用的环境相关。和生命周期相关的有应用程序的安全要求、安全系统架构、工程原则、安全编码、开发和验收中的安全测试；项目和使用环境相关的分别是，开发测试和运行环境的隔离、对源代码的访问、外包开发、变更管理、文件化的操作规程。

此外，万鑫认为新版ISO 27001：2022相较于之前有了较大的提升，特别是新增了安全编码这样的控制域，所以企业自己开发的代码或者所采购的商业件、所使用的开源件，都应该从代码的维度去提升代码的整洁度、代码的逻辑性，这样就可以极大地降低漏洞和bug的情况。

万鑫表示，研发企业存在这样的痛点，快速开发的时效性和安全强调的稳定性之间存在矛盾，即怎么把相对比较厚重的安全措施和比较敏捷的开发流程结合起来，这是一种学问。

董毅从SDL开始介绍。SDL最早由微软提出，是一种用于安全角度指导软件开发过程管理的实践模型，如今的SDL不止微软这一套体系，它有着软件安全开发生命周期实践方法的集合，这个集合里包含了非常多的元素，有各个企业自身的实践方法，也有监管机构推出的实践框架。

2008年之后，DevOps研发和运营一体化的生产模式在软件开发的领域里大行其道，目前为止，DevOps的生态一直处于高速落地的趋势中，已成为企业无法忽视的常态化的开发模式。然而，尽管DevOps提出了很多先进的理念，但始终没能解决一个重要的问题，就是怎么把安全比较高效地结合到这个体系里。

2012年，为了解决这个问题，DevSecOps应运而生，但在国内始终处于不温不火的状态，一直到2017年，随着DevOps整个生态的成熟，DevSecOps成为了众人都需要关注的内容。

董毅表示，以上背景和这次ISO 27001标准迭代中的供应链安全息息相关，此次改版最重要的更新就是在其中加入了保障软件供应链安全的概念和措施。

在此，董毅总结了SDL、DevSecOps、软件供应链安全的概念和它们相互之间的关系。广义SDL表述的是一类安全工作，是控制软件开发生命周期的安全工作的集合；狭义的SQL是微软的实践框架，它更具体但涵盖的面更小。

而DevSecOps更像是一种实践的体系，一种思想体系，它所要求的，是把安全敏捷化地贯穿到研发、运营的全流程中；最后软件供应链安全的涵盖面更广，其涵盖了从软件生产到软件上线运营全周期所有的环节，也就是说它几乎包含了软件全部的安全。

杨文斌表示，作为甲方安全专家，其企业软件供应链安全的建设路径和ISO 27001中的建设思路比较贴合。首先在软件供应链的前期需要处理相关的资产，比如组织资产、项目资产、开源组件方面的资产。

梳理完资产之后，可以通过平台化的方式把这些相关的资产串联起来，建立关联关系，只有打通了链条才可以非常高效地去预警，同时漏洞匹配之后可以下发到具体的整改责任人，这是准备工作。

从整改的角度来看，需要建立相关的链条。比如出现了新漏洞，作为企业的项目负责人需要知道这漏洞对其工作的影响，这就需要在项目的运行环境里建立类似的探针，探针会收集相关的信息并反馈到平台上，这样当平台上出现某一个漏洞时，它可以精准地关联到具体的漏洞路径上，项目负责人就可以直接寻找漏洞的位置并进行整改了。

在闭环方面，它具备实时监控的机制，比如漏洞整改完之后，漏洞会进行消削同时会反馈到平台，这样，从预警到整改、修复这么一套流程就可以搭建、运行起来了。

杨文斌建议，推动安全措施落地，得从上往下执行，比如让领导层下发一些措施，或者建立相关的制度，这样才能高效。此外，可以在建立制度或者规范时加入一些考核措施，有利于部门配合。而在平台建立之后也需要动态的维护，保证不管是漏洞更新还是项目新增，都能具备发现、整改的时效性。

接下去需要考虑的是量化的问题，比如在考核项目时，看还有多少问题没有整改，或者哪些问题在提出后已经过了多长时间，等等。可以从安全管理的角度去考核整改成效，然后通过考核机制来推进整改工作。

蔚晨从三个方面介绍了他在企业供应链安全中的实践。首先是外包管理，针对于外包人员、外包服务、外包开发商，最初所引用的方式是和他们签署保密协议，但随着外包工作进一步的精细化管理，外包规模越来越大，以及之后又引入了供应链安全的很多概念，所以现在更多地会用桌面云、虚拟桌面等方式，提供给外包人员、外包供应商一个隔离的环境，让他们在这个隔离环境中完成外包工作，避免让他们和企业的核心数据、核心资料进行接触。这是从技术上做的相关隔离。

在外包人员的职责方面，蔚晨所在的企业做了外包人员职责的风险岗位分析，最后明确出，在整个IT生命周期环节中，哪些岗位、哪些人员可以用外包，而哪些严禁使用外包的矩阵框架，对于此矩阵框架还要动态地去进行评估和优化。

第二，针对外包供应商的管理，则需要引入大量的外部威胁情报，通过这种方式及时地由安全部门主导，向该供应商所涉及到的业务部门、开发部门、运维部门发出类似于告警提示这样的信息，然后引发大家对该供应商相关产品做出一些评估，包括相应的整改和落地。

第三，针对开源框架方面，安全部门会协同开发部门、规划部门、运维部门，组成类似于标准化的制定小组，定期对操作系统、中间件、数据库，包括开源框架、标准化的组件、标准化的商业产品，对它们的版本、适用范围、使用的相关要求都会定期做一个评价和结论，这样就能使以后的项目在使用这些组件、软件相关的内容时，可在圈定的范围内用相应的版本和相应的产品来降低异化的安全风险。

接着，针对特定的应用，会根据应用所在的环境，应用所需的数据比如是否包含业务敏感数据等，通过复杂的计算模型去评估产品是不是一定要强制性地引入标准化框架，包括可不可以引入一些异化的框架，同时也会有评估的过程。

蔚晨表示，安全左移的趋势越来越明显了，所以针对相应的需求，企业会引入安全架构的评审，包括对第三方组件、第三方产品，都会在项目开展前期花较大的精力去做这方面的评审和认定，使之后的开发、测试、检测、上线、运营上的安全风险尽量往前过度，这样就能极大地降低软件安全风险。

姚丽娟通过新标准的两个控制项分享了新标准对软件实现和安全测试的指南。姚丽娟指出，新标准明确了对编码安全的控制指南，编码安全需要覆盖自研代码、外包开发的代码、定义三方软件组件及开源代码，并对软件产品全供应链上软件组件的代码安全提出了具体和全面的安全要求。

新标准在编码前、编码中、代码运行前后分别给出了编码安全的指导。比如，在编码前需要制定安全编码原则和实用指南，在IDE中集成代码安全的插件，学习危险编码规避的经验。研发人员应具有安全编码的资质，开展威胁建模以及安全的架构设计。

在编码中，需要为开发者提供安全的编码环境，确保代码来源可信，遵循安全的编码实践，编码中要充分考虑代码安全的容错机制，禁止使用有风险的代码，可以采用同行评审、结对编程、安全代码责任等安全编码基础技术，对存在风险的编码实例进行记录和积累，持续推进代码重构，开展静态代码安全扫描。

在代码运行前要确保安全漏洞全部清零，评估攻击面和最小权限原则，对于编程错误的纠正及效果进行记录，审视外部组件使用的安全情况。

在代码运行后要确保软件包更新安全留存错误和攻击风险记录，运行代码要防篡改，对信息安全事件做好应急响应的准备，应急响应的处置策略和应急响应的预案等等。以上实践可以指导组织开展具体的安全控制，也是审核重点关注的方向。

某供应链管理公司基于自己的实践得知，代码审查、避免危险的编码实践固定依赖项以及审查代码的提交，对降低项目漏洞可能性的作用更大。

另一个方面，姚丽娟分享了开发和验收中的安全测试控制。新版标准建议组织尽量搭建起生产环境一致的多个测试环境，测试环境要满足多种测试场景及测试目的的需求。新版标准还建议在安全测试中覆盖安全功能测试、安全编码测试、安全配置测试、安全系统测试。

安全测试可以借助代码安全分析工具、漏洞扫描工具，同时鼓励在一定的安全范围内开展渗透测试，识别不安全的代码、不安全的设计以及不安全的漏洞，对于风险要做到早发现、早处置、早安全。安全测试是系统测试和验收测试不可缺少的组成部分，同时也是重要的审核内容。

姚丽娟还分享了新版标准在审核方面的变化。新版标准通过业务流程在信息安全管理体系中的管控，让组织业务与体系有效结合，因此审核中会下探到组织的业务过程，使信息安全管理体系为组织业务的长足发展保驾护航。

新标准在网络安全方面有较为全面的控制措施，覆盖了网络访问控制、网络配置管理、网络安全监控。审核中需要充分识别组织的网络安全风险，结合控制措施对网络系统安全进行精准的审核。

新版标准在隐私数据和敏感数据的控制上提出了明确的要求。审核中要充分识别数据类型及处置的措施要求，确保适合于各类数据的安全控制措施得到良好的实施。

在新版标准的编码安全中，针对软件供应链安全的控制是更加具体和深入的。在审核中，审核员需要更多关注软件产品供应链全链路上软件组件的安全控制，需要覆盖自研软件、外包软件、三方软件以及开源软件。

新版标准认证对组织来说是一次机会，也是一次挑战，对审核员也有较高的要求，审核员需要具备深入领悟认证组织业务过程的能力和全面的网络安全专业知识储备，并要有敏锐识别数据安全和隐私合规要求的专业精神和专业经验。

杨文斌就如何迎审到最后怎么获得做了简单的介绍。首先运行期之内需要准备相关的沟通材料和文档，同时要结合体系不断地对公司内部在安全方面的运行情况做出调整，然后将和体系相关的一些程序文件、指导书进行优化。

接下去在运行了一段时间后，需要对内部的运行情况进行内审，不符合体系标准的内容需要及时调整过来，完成内部整改。另一方面，需要对管理体系进行评审，看管理方面有哪些缺陷，制定相应的纠正措施进行优化。

这些都完成之后，审核机构就可以根据文审的实际情况安排现场审核，到时会有具体的专家组进行审核，时间一般为2到3天。审核后相关机构会提出整改意见，会有整改期，在整改期的范围内，公司需要结合自己的实际情况完成整改，然后把整改的材料给到审核组长进行初审，接着再把整改的最终材料提到认可机构，认可机构进行二审之后会把这些材料提到最终的评定处完成上会决议，如果没有问题就可以下发证书了。

杨文斌强调，如果体系运行时出现了变更，需要及时和审核机构沟通，包括企业内部本身的变更，企业内部的信息调整，比如营业执照、地址这方面的信息调整，比如关键人员调动等，都需要及时地向审核机构报备。

董毅认为，未来的趋势之一是在软件物料清单方面会有很大力的提升和发展。从需求方来说，很多甲方企业头痛的问题是软件的源头控制不了，其次当企业用到一些开源软件时，虽然软件的代码是透明的，但对开源软件里的风险识别没有系统性的方案。并且某些开源软件只有在运行的时候才会引发漏洞事件，要怎么能迅速地定位到这个开源软件、解决它，这是很多企业的痛点。

另一个原因，在软件物料清单以及软件供应链安全方面，这两年有很多的机构都在做相应的法律法规标准，有团标、有国标、有行标。

第二个趋势，软件许可证合规的问题会得到更多的重视，去年GPL3.0许可证侵权事件，使很多甲方企业的法务都注意到了，开源软件的许可证会造成很严重的后果，虽然此案件里侵权方只赔了50万人民币，但未来的力度、案件都会越来越严格。

解决软件许可证合规问题需要用到SCA工具来做软件的成分分析，SCA工具可以把所用软件中的所有组件都分析出来，然后进一步分析这些组件中所用的许可证，最终再把许可证的风险分析出来，形成结果报告呈现给企业。

第三个趋势，代码疫苗技术的应用会继续深化。许多规模较大的甲方，他们的业务场景会出现组件无法替代但又存在风险的情况，通常那些组件已被运行了很久，它们的版本更新是颠覆性的，无法轻易迭代，一旦更新就会导致很多组件要做大幅地修改，企业的安全部门是承担不了这种责任的。

因此面对这种情况就需要采取相关的措施。第一步是针对此风险做风险评估，对它的威胁性、资产价值做综合的分析，然后将它的评分做一个量化处理。之后要和财务部门进行配合，对“如果出现问题将会有多少损失”进行估值，再将其值和“如果替换漏洞、组件将会有多少成本”进行比较，若最后发现损失更大，那无论如何都会建议甲方去执行替换的工作。

第二步，若评估完之后发现风险可以接受，就可以用代码疫苗技术的工具进行防御。代码疫苗技术可称之为软件业务安全领域里的第三次重大变革，它可直接运行在应用的内部，好比在人体中打了疫苗，它的工作原理是会在应用内部不断地监测此应用在执行过程中内存的上下文，包括一些网络协议栈等等。

当在应用内部发现了风险后，就会立刻做一些处置措施，这个处置措施是可以预置的，而且通常为函数级的封禁，不会影响应用的执行，这种方式的好处是力度更为精细。

在这个技术体系下，有三种主要的产品类型可以覆盖整个软件生命周期。首先在研发测试阶段，可用IAST交互式安全测试工具做上线前的安全检查；上线之后，可以用RASP工具做上线后的安全保护，它可以做到封禁函数的功能；最后是交互式SCA，其作用是在运行态监测保护第三方组件的安全性。

蔚晨认为，怎么样把产生价值的商业企业和能提供安全服务、安全产品的安全厂商，以及市面上提供开源框架的社区结合起来，形成一个动态的、高效的、快速的生态，让问题的发现到价值的评估都成为正向的过程，这是未来我们需要发展并关注的趋势。

在这样彼此联合的空间中，专业的安全服务专家、代码分析的专家、安全产品的提供商，都可以在这个生态中起到引领、带头的作用。这样，企业也可以在这样的生态里获取更多的利润。

其次，蔚晨认为构建基于企业内部的业务特色、技术特色，企业可以搭建属于自己的开源框架，这个开源框架的制定、架构的设计，包括它的维护都可以由企业内部的架构团队来做，包括一些关键的业务应用都可以逐步迁移到这个自主可控的开源框架下，以此降低大量异化应用的安全风险。

杨文斌表示，为了提高研发的效率，企业引入了第三方科研软件，也因此带来了大量的安全问题，后续在软件开发的过程中是否能加入一些人工智能的方式，可以自动化地规避掉开源组件的脆弱性，这可以成为未来的一种趋势。

其次，在零信任方面，杨文斌认为其更适合软件安全的场景，所以未来的发展趋势里，可以在软件安全上做些零信任的设计；在数据安全方面，杨文斌认为之后会有更多的建设会应用在软件安全上。

问题一：在有外包情况下，现在最好的办法是协议吗？还有其他更好的办法吗？

蔚晨：保密协议是最基本的要求，可以从外包的资质管理层面做进一步的管理，比如安排专门的外包管理岗去做人员的资质核定，甚至可以对某些特定岗位的外包人员进行入职考试；内容管理方面，可以从技术管控层面提供隔离的环境，要求外包人员必须得在企业指定的开发环境中进行操作。总之，对企业来说，就是有多少投入，就能做到多少管控。

问题二：从甲方角度，如何看待企业安全部门和其他各业务部门的分工和协作？

蔚晨：在软件供应链的链条里，不同部门的人员都需要起到自己的责任和作用，对安全部门来说，是从供应链安全的视角分析整个链条中有哪个环节可能会出现安全问题，并因此给出解决的方案和建议，所以安全部门最大的作用是协调。

其次，根据企业中安全部门所处的位置和责任，安全从业人员在整个链条中要搞清楚上下游，搞清楚关联的联系人是谁，学会和他们沟通，学会在别人可接受的范围内和他们达成一致，使相关的安全要求能在整个IT生命链条中有所落地。

问题三：新版ISO 27001在具体控制落地环节有哪些相对硬性的控制需求？因此会额外增加多少成本？

杨文斌：新增的标准是11项，具体体现在数据安全和云安全之上，比如关于数据屏蔽、数据防泄露的要求，是一定要有所改进的，再比如业务连续性方面，关于备份、基础设施的冗余，肯定需要增加投入。

问题四：能否讲一个成功导入的案例？

董毅：第一要循序渐进，建议先从咨询开始做起，逐步上工具，慢慢做迭代，先把一个工具研究透，把整个流程跑通，磨合上没问题了，再去安装更进一步的工具。

第二要结合场景，很多咨询专家都有场景化的落地经验，因此可以结合甲方具体的场景来做一些相应的建议，然后再分步实施。

第三要拥抱工具，云原生场景的变革造成了业务的迭代速率越来越快，用微服务、容器这种云原生体系做服务的研发，相应地就会对敏捷化的要求特别高，而传统的人工成分会降低敏捷性，所以在新场景的情况下，对工具大幅的接受和拥抱必不可少。

第四要强化培训，特别是针对研发、测试、运维等部门，要对他们做一些信息安全培训，帮助他们从底层建立知识体系，让他们意识到自己在安全层面上的责任。

第五要以评促建，即用评估认证的方式来促进整体安全体系的建设。

问题五：ISO 27001的局部认证该如何操作？如关键人员怎么选择及人数如何界定？

姚丽娟：局部认证根据体系覆盖的人数，包括正式员工、外包员工以及第三方人员总人数去认定。所覆盖的部门根据企业自己的需求，比如要在证书上体现哪些业务、哪些产品，然后根据这些产品业务覆盖的主要部门进行界定。主要就是从这两个维度进行复杂度和人员的计算。

问题六：27001包括了27701的部分内容，是否新版认证后27701就可以不做了？

姚丽娟：27001虽然包括了部分对敏感隐私数据保护的一些控制措施，但针对隐私保护还是太薄弱了，不能替代27701的审核。27701从个人数据控制者和处理者的角度，在隐私保护上给出了非常全面、非常系统的控制措施。