在传统的概念里，汽车相对是偏硬件的设备，随着网联化、自动驾驶、智能座舱的发展，汽车的软件代码最近已经超过了1亿行，未来可能还会更多，现在正处在软件吞噬汽车的时代。
汽车行业开源软件现状与挑战
新思科技每年都发布开源软件安全风险报告。我们可以看到在汽车领域里面，软件70%左右都是由开源组成。在这样的前提下面，新思科技还有另外一组数据和大家分享一下，大家可能关注开源软件安全的风险。
在安全领域，像蓝色的部分，开源代码里面至少包含有一个漏洞的比例也在逐年上升，这些漏洞称之为已知安全漏洞。这些安全漏洞里面也会分等级，不同等级可能对用户造成严重的或者中高的风险。我们再来看看橙色的部分，高危漏洞的比例也是不低的，超过60%。这个意味着什么？如果今天你的软件里面包含了高危漏洞，整个系统很容易被穿透，很容易造成数据的泄露，或者系统的主机被远程的控制。再回到汽车行业来看，包含漏洞的比例也不小，有超过60%，希望引起大家的关注。
我国“十四五”规划也提到，国家鼓励知识产权和创新，在越来越重视知识产权的前提下面，举一个例子像“MySQL”，它其实是双许可证的，它有一个GPL许可证，还有一个商用的许可证，还有的可能是GPL或者Apache或者MIT，我们称之为的许可证，不同的许可证之间也会有冲突的风险。
还有另外的风险，包含无许可证的或者自定义的许可证，这块的比例也不低，也是会给客户造成比较大的潜在风险。相当于什么？它的许可证是一张白纸，随时可以往上写东西。尤其是在汽车行业里面，合规这块的风险远远大于平均的值，超过80%的比例。
由于安全漏洞和开源相关的真实法律案件的不断出现，开源对汽车网联安全而言显得十分重要。现在的车都是全球供应链下的协同生成的，车也会涉及到出口，涉及到GDPR 和美国的出口法，还涉及到汽车软件的使用的加密算法。这些都需要引起我们的重视。
汽车行业与开源相关的可信会越来越重要
汽车行业是一个非常注重安全和合规的行业，像各种法律法规，或者是各种标准。比如ISO21434里面涉及到的和开源相关的条款：
第一个条款是RQ-09-05，在进行威胁分析和风险评估的时候，在这样一个阶段的时候，也需要考虑开源的风险的，如果用到了一个开源的组件，也要做威胁建模或者风险分析，因为软件最终是由代码组成的。代码设计安不安全，代码设计有没有潜在的风险，所以在这个阶段进行主动的分享分析也是非常重要的。
第二个条款是RQ-06-16，这里明确写在集成现成的组件开发流程中，扫描开源组件相关的漏洞，这个跟OWASP Top 2021里面的A6，脆弱过时组件（Vulnerable and Outdated Component），这个也是明确需要治理的
第三是条款是RQ-07-01，对新发现的漏洞提供预警的工具，作为对持续网络安全监测活动的投入，我们知道汽车有召回的概念，其实软件也是一样的，汽车也是软硬的结合体，汽车交付发布之后，要对它已有的软件进行监控，如果发现0Day漏洞，主机厂要及时监控，评估风险，同时告知客户，如要做OTA升级，IQ-0710也跟开源相关的，软件的开源组件也要持续的监控，有持续告警的能力。
以上是跟大家分享一下ISO-21434跟开源相关的一些条款。
2020年12月份发布的ISO-5230，也是一个国际的标准，它是基于Linux基金会孵化的OPENCHAIN的开源项目，这个项目的背景就是做开源组件合规治理的国际标准，一标准主要基于三块，流程、规范，以及培训。
这个标准背后汽车行业也是重要的推手之一，包括一些日本的厂商，很早就在推动这样一件事情，所以这个标准目前从趋势来看，未来几年会成为共识，汽车工业也是一个依赖上下游供应链的行业，供应商在交付软件给下游的时候需要提供软件物料清单(SBOM)。可能会有人问这个跟开源有什么相关的，其实关系很大，根据我们之前的报告，之前分享的汽车行业里面数据来看，汽车行业的阮籍哦按70%的代码是开源代码组成的，所以要解决问题的话要抓住主要问题。开源软件的治理是我们需要关注的重中之重。
汽车行业开源软件安全可信治理方面的实践
应该如何去做，或者有没有一些可以入手的点，其实还是有的，首先从企业治理的框架而言，在开始的时候，一般企业都是冲从使用开发入手的，使用肯定会涉及到开源组件，比如Linux或者glibc，或者是其他的一些开源工具也好，很多企业为了快速迭代和创新，很大的情况下会在开源软件的基础上集成和二次开发。
在这个情况下，很多都是研发同学自发的拿过来使用，但是可能没有意识合规和安全的风险，无意中引入了一些潜在的风险，这些需要通过一些技术手段，通过一些规则来来对开源软件进行识别，构建明细表，进行系统化的治理。
大家可能看到现在的自动驾驶非常热，有些公司，尤其是国外或者国内，通过构建生态，吸引开发者一起参与。比如国内百度的阿波罗也是一个开源的平台。
再往上通过构建生态战略，和生态链的企业进行协同互动，使开源成为一个企业的数字化战略，有些公司如果做的非常好，它会推动整个公司有一个非常长远或者非常好的发展和未来。
我们发现，开源大部分是自下而上来推动，通过我们接触的汽车行业来看，大部分还处于技术使用和安全可信的阶段，我们看看有哪些具体的行动项。
一个是团队，从开源参与的角度来讲，涉及到的面还是非常广的，涉及到法务，也涉及到一些合规、专利的问题，这是需要法务参与的，另外一个也会涉及到技术的选型，也需要架构师参与进来，考量开源组件的技术架构，学习的成本，使用的成本，另外也会有安全同事参与进来，像开源组件的安全漏洞梳理，它的安全漏洞分布，从安全的视角来讲，它的哪些版本比较安全，或者有没有一些缓解的手段。
第二是可信，我们刚才介绍的OPENCHAIN社区，为什么要加入这样的社区？就是为了和社区或者整个社区的参与者，建立非常可信的合作生态。还有比如供应链也好，合规也好，推动整个企业级安全治理合规框架的发展。
再往下走，如果探讨到规则或者流程或者技术，这个就更多了，从流程角度来讲，或者是漏洞的角度来讲，或者是许可证来讲，整个开源合规的培训，贯穿到整个体系能力的建设过程之中。
人工的审核重要性，当工具识别出问题的时候，需要有专业的专家同事介入，然后再做住家的审核的过程。比如发布的时候，很多开源的漏洞是由配置软件组成的，在这些项目里面也需要去检查，在做渗透测试的时候需要关注和开源漏洞相关的风险。
最后即使这个软件和车一起交付了，但是我还需要有开源软件的清单，我们讲持续交付，持续构建，如果有问题，我可以在第一时间知道这个漏洞它影响到我哪个版本，这个版本影响到哪些车型，使我们有能力快速地进行追溯和管理。
如果是对应着ISO -21434，其实也是有据可循的，从左到右，在前期阶段进行威胁建模和风险分析，中期进行过程中的识别和系统的开源风险风险，最后即使软件进行发布了之后，也要持续对开源的漏洞进行监控，这些都是和ISO-21434息息相关的。
网络安全ISO-21434的开源相关的风险的接触点
第一个接触点，很多公司说我的产品要发布，第一步他可能想到的是生成一个开源组件分发说明清单。那么如何做成一个持续性的方案？他想到能不能在我的软件集成测试的时候去扫描识别，在这个阶段发现问题，我们发现预留整改的也不一定够，一般情况下识别出来之后我还要去做整改和修正，在这个基础上，我们可以考虑在编码的时候识别开源组件，这些都是在编码和测试的时候进行治理，那么有没有可能更早一些开展呢？比如在需求分析，设计阶段，其实开源软件是非常丰富和多样的，比如像开源数据库其实有很多选择，，那么在需求和设计的时候，需要架构师针对产品的特点和业务的特性，选择合适的开源组件，同事也需要考虑未来有潜在的开源组件的安全合规风险，指定响应的应对的策略，
在ISO-21434的安全的概念阶段，开源安全合规的培训融入到整个的研发过程中，并做成一个持续性的事，针对开发同事，项目经理已经管理层，准备不同的培训课程和目标，同时可以考虑针对相关的案例，讨论为什么会触发这样的风险，违反什么规范，知道相关人员如何做避免违犯相关的法规和规范，安全的漏洞分为两块，一种是代码级别的，另外一种是逻辑层面的，但这种逻辑层面的东西，可能不是扫描代码就能发现，危险建模和风险分析也是非常重要的。
最后比如说在做开源组件需求管理的时候，代码的来源是非常多样的，有供应商、外部社区的来源，在这样的前提下面，我们需要做好统一的规划，要求我的供应商什么样样的信息给我，或者我对我的供应商有哪些要求，比如交付的软件不能使用包含高风险漏洞的组件或者含有GPL的组件，也是很重要的。
还有两个是贯穿整个流程体系建设，合规培训和安全合规文化的建设。始终贯彻在我的整个的研发流程开发体系中。
新思的Black Duck开源合规的解决方案，新思科技是提供一站式的自动化解决方案。这个解决方案国内很多高科技公司、ICT公司，甚至是银行都采用了方案。它的特点，很多实现自动化，同时它应对的场景比较多，针对开源合规体系里面已经内嵌了很多最佳实践的功能，同时接触点比较多，企业里面还有一个特点比如高可用，还需要有一些专业的专家服务。整个通过新思科技提供的一系列解决方案和产品，来帮助客户更好地去达成开源合规的目标。通过更好地使用开源，来去帮助企业里促进创新、保驾护航
