新思科技:智能汽车时代,如何构建可信软件?

小微 阅读:54360 2024年03月05日

随着智能汽车深入发展,汽车产业正从多独立域走向跨域融合。同时,软件定义汽车已成为共识,汽车要拼算力、更拼软件,出现硬件预埋与软件选装——软硬隔离的趋势,将硬件模块化和标准化,以便通过软件实现更多功能。

新思科技:智能汽车时代,如何构建可信软件?
图片来源于网络,如有侵权,请联系删除

新思科技高级安全架构师肖率武表示,智能网联汽车时代,一辆汽车上运行着上亿甚至数亿行的软件代码,而从安全角度看,汽车的攻击面也在同样与日俱增,因软件导致的汽车安全事件也层出不穷。因此,软件风险即车辆风险,一旦成为汽车网络攻击活动的受害者,汽车制造企业会在多个方面受到严重的损失和负面影响。

新思科技:智能汽车时代,如何构建可信软件?
图片来源于网络,如有侵权,请联系删除

在智能汽车时代软件安全的严峻形势下,如何来构建智能汽车可信软件,保障第三方及自研代码安全?2023年12月19日,在长城汽车2023技术研讨会上,肖率武围绕上述问题展开经验分享。

肖率武 | 新思科技 高级安全架构师

以下为演讲内容整理:

智能汽车时代软件安全的挑战

随着智能汽车深入发展,汽车产业正从多独立域走向跨域融合。同时,软件定义汽车已成为共识,汽车要拼算力、更拼软件,出现硬件预埋与软件选装——软硬隔离的趋势,将硬件模块化和标准化,以便通过软件实现更多功能。

那么,我们所面临的挑战是什么呢?

E/E 架构不断调整传统的汽车主要集中在车辆本身,而现代的智能汽车则涉及到车端、后端和云端等多个方面。这导致了开发模式的转变,使得我们使用的各种框架、操作系统和语言变得更加复杂。如果事情变得复杂,出错的可能性也会相应增加。

供应链安全挑战。随着前端与后端的交互增多,统一的安全传输和交互变得至关重要。

软件开发和部署更加复杂。由于开发模式、框架和语言的多样性,我们需要找到一种方法来简化这些复杂性。

攻击面剧增,安全漏洞层出更进一步,每一个管控环节在供应链中都扮演着重要的角色。最薄弱的一环往往决定了整体的安全性。随着供应链的扩大,来自硬件、软件、应用、数据的多类隐患更多,每个汽车制造商都需要考虑更全面的安全防护措施。

TTM加速VS合规监管的挑战传统的汽车制造上市周期已经受到挑战,从过去的48个月缩短到了如今的12个月。与此同时,还需要满足汽车安全、数据、代码的各类法规标准。

SDV时代,软件风险即车辆风险安全攻击对汽车行业造成的损失和影响巨大,汽车软件漏洞层出不穷。

首先,让我们看一下近年来对车企造成影响的常见安全攻击手段。根据统计,近五年来,35%的攻击集中在软件漏洞上。同时,与远程网络攻击相关的攻击手段也是最明显的,它导致了很大一部分安全问题,例如信息泄露。统计数据显示,这些攻击大部分是由于编码错误导致的。为了解决这些问题,车企需要在编码阶段就采取措施。这意味着在开发阶段就需要考虑到安全问题,并在编码阶段就解决这些问题。

此外,我们还需要关注攻击目标。攻击目标包括操作系统、应用程序、设备和网络。对于车企来说,如何在发布设备时解决这些安全问题是一个挑战。为此,我们需要探索如何在没有代码的情况下通过其他方式来解决安全问题。

智能汽车时代软件安全的要求

汽车行业需要遵循一系列标准和联盟规定。排名前15的公司中,有11家采用了世界汽车OEM厂商采用的标准。

对于车企来说,安全是一个重要的关注点。首先,我们应关注“ISO/SAE 21434-网络安全工程”这个标准,“UNECE WP.29 (UN R155, UN R156)-网络安全和软件更新”与之对应参考。如何达到这一标准?在软件开发领域,有一些成熟的方法可以借鉴。例如,微软的SDL或B CMO sm或BS7799的理念。

对于车企来说,关键是如何将安全融入开发过程。从21434中我们可以看到,这涉及到软件更新的管理,因为软件安全与软件更新密切相关。通过组织这些安全活动并纳入日常开发活动中,我们可以确保在开发过程中考虑安全问题。相应的文档和产出可以通过车企的认证申请流程进行管理。

图源:演讲嘉宾素材

展示一个开发模型,我们可以看到传统车辆开发中如何应用这些理念。从安全需求开始,到安全设计、安全编码、测试等环节,每一步都有相应的安全活动,环环相扣,共同实现软件安全。

接下来,我想谈谈测试阶段的相关内容。在此阶段,我们进行了边界值测试等一系列的测试方法。此外,我还强调了漏洞扫描、渗透测试以及模糊测试的重要性。渗透测试涵盖的范围很广,包括大家熟知的安全测试和逆向测试等。对于不同类型的协议、设备、ABC型应用以及操作系统,我们需要采用不同的测试方法,以确保全面覆盖。

智能汽车时代构建可信软件的实践——第三方代码安全保障

与其他行业一样,汽车行业也不可避免地需要使用供应商提供的代码或开源代码。以金融行业为例,许多项目都会使用开源代码。据某知名机构发布的安全与风险分析报告,他们每年会审计大量代码库,去年甚至审计了100703个代码库。这些代码库涵盖了各行各业,报告发现90%的项目都使用了开源代码。然而,平均有40%-60%的代码库包含高风险的漏洞。这是一个普遍存在的问题,无论是金融行业还是其他行业都难以避免。

对于车企来说,情况也类似。根据相关数据,车企在最近两年内对开源代码的使用明显增加。这既带来了便利,也带来了安全风险。因此,我们需要更加重视代码审计和漏洞扫描工作,以确保车辆软件的安全性。

另外值得关注的一点是,车企中的高危漏洞比例明显高于平均水平。通过统计数据可以明显看出,在开源代码中,车企的高危漏洞排名第五。

图源:演讲嘉宾素材

然而,除了安全漏洞外,在车企的开源代码中还存在着两个重要问题:许可证合规性和软件健康度。

企业必须关注代码中使用的开源组件是否符合许可证要求。例如,如果代码中使用了某个GPS相关的开源组件,而该组件存在许可证问题,那么企业可能需要自己开发相应的补丁来解决这个问题。这对于商业公司来说是不可接受的。事实上,很大比例的代码中存在许可证冲突等问题。

软件健康度也是一个关键问题。如果一个代码中使用了已经不再维护的开源组件,或者使用了长时间没有更新的软件,那么就可能存在风险。这就像一个企业如果继续使用已经不再维护的产品,那么可能会出现问题。因此,我们需要及时更换更活跃、健康的开源组件,以确保软件的安全性和稳定性。

间接依赖也是需要关注的问题。有时候,我们可能没有直接使用某个开源组件,但是我们的框架或者其他依赖可能已经将其包含进来。这些隐藏的问题可能会给我们带来安全风险。因此,我们需要仔细审查我们的代码和依赖,确保没有任何潜在的安全风险。

在实际开发过程中有一些常见问题。比如,开发人员可能会从网上获取代码,修改后直接使用。这其中可能存在一些安全隐患,例如代码中可能存在GPS问题,具有传染性。此外,开发人员可能会在没有充分审查的情况下引用其他代码或算法,这可能带来安全风险和许可证合规性问题。在引用代码时,我们需要确保所引用的代码是安全的,并且符合许可证要求,否则可能会给企业带来潜在的安全隐患和法律风险。

为了解决这些问题,我们需要建立完善的供应链管理和代码审查机制。首先,对于从外部获取的代码或组件,需要进行源代码审查和安全漏洞扫描。同时,需要将扫描结果与知识库进行匹配,以获取更详细的信息和修复建议。此外,企业可以制定一些规则和限制,例如禁止使用某些特定的开源组件或限制使用特定版本的软件。

图源:演讲嘉宾素材

在这个过程中,安全团队和法务团队的合作也是必不可少的。开发人员可能不具备足够的安全知识和法律知识,因此需要安全团队和法务团队提供指导和支持。

在部署阶段,实际情况是怎样的呢?大家都知道,一旦软件投入使用,就可能出现新的安全漏洞。为了应对这种情况,我们需要持续监控并及时修复这些漏洞。要做到这一点,关键在于获取完整的软件清单,这样一旦有新的漏洞出现,就可以迅速定位并修复问题。

第三方组件的占比很大,我们需要特别关注。在日常开发中,开发人员主要编写自然代码。为了确保其安全性和质量,我们可以采用一些基本概念进行检查。例如,什么是weakness?在C和Java中,这类似于一个类的问题。具体来说,一个实例可能存在一个安全漏洞,例如命令行注入漏洞。

漏洞分为已知和未知两种。已知漏洞是已经被黑客或其他人员发现的漏洞,而未知漏洞则是尚未被发现的漏洞。对于这些漏洞,常用的检测手段包括CVE(Common Vulnerabilities and Exposures)等工具进行扫描。这些工具需要及时的更新其漏洞库以保持其有效性。

除了工具扫描外,还有一些零日漏洞的检测方法,例如模糊测试和深度测试等。这些方法的目标是发现未知的或零日的漏洞。然而,这种方法往往依赖于开发人员的经验和知识,因此可能并不总是能够有效地发现所有的问题。

为了解决这个问题,我们可以借助一些工具进行静态代码检查和SCA(Software Composition Analysis)等工具。这些工具可以帮助我们快速发现潜在的安全问题,提高软件的安全性。

图源:演讲嘉宾素材

另外,还有一个概念需要澄清。大家常说的代码规范,如MR规范或OLED规范等,与我们的代码规范是有差异的。它们并非完全重叠,就像我们常说的健身和饮食安全,虽然都对身体有益,但不能保证不感冒。代码规范也是如此,它指导我们如何编写代码,避免某些不良的编程习惯,如强制类型转换等。但仅仅依赖代码规范并不能完全避免系统出现问题。

一个现实问题是,即使有了代码规范和代码审查机制,仍然可能出现一些难以检测的问题,如不恰当的指针操作导致内存问题,或敏感信息泄露等。这些问题可能是由于对某些复杂的上下文情境理解不足所导致的。

为了解决这些问题,我们需要借助一些工具进行静态代码检测。但需要注意的是,这些工具也有其局限性,误报率可能较高。例如,对于C++的静态代码检测工具,其误报率可能高达90%以上。因此,我们需要合理使用这些工具,并根据实际情况调整策略,以达到最佳效果。

如何将工具引入到我们的日常工作中呢?一种情况是按照代码规范进行检测,另一种情况是处理代码流问题。在提交代码后,我们可以将其放入代码仓库中,然后通过定时触发等方式进行扫描。但实际情况中,我们可能面临许多第三方或合作伙伴的代码,这些代码我们无法直接修改。此时,我们可以针对特定组件或目录进行扫描,提高检查的效率和针对性。

除了代码规范,我们还需要关注真正的bug问题。这时,我们可以启动实际问题的检查规则,例如办公楼、td等,这些规则能够实际检测出代码中的问题。如果能够将这些问题与后端系统、缺陷管理系统等完全整合,那么我们就可以实现自动化,提高工作效率。

在目前的安全工作中,SST和SCA是两个投入产出最容易见效的方法。它们可以完全融入到开发流程中,提高工作效率。同时,我们还可以进一步将检查时间提前,甚至在编写代码时就开始进行检查,这样可以更早地发现和修复问题。

对于模糊测试、人单、渗透测试等安全检测方法,我们也可以根据具体情况选择使用。例如,对于设备安全测试,可以在发布阶段或无源代码情况下进行立项。

(以上内容来自新思科技高级安全架构师肖率武于2023年12月19日长城汽车2023技术研讨会发表的《智能汽车时代构建可信软件的优秀实践——保障第三方及自研代码安全》主题演讲。

搜索
排行榜
标签列表