通过了安全测试，就一定是安全的么？
最近，成都发生了一起小米汽车碰撞事故，车辆起火燃烧后，汽车门打不开，延误了救人的宝贵时间，最终造成车内乘员死亡的惨剧……
这个事件引起许多人对于汽车安全的关注，更多人则和小米汽车在宣发时候强调的安全性做对比，却发现宣传时候的安全性在这起事故中并没有起到作用，最关键的是事故后车门打不开。
这不难让人起疑，厂家不是说各项安全测试均通过，甚至超过20倍以上么？为什么在真正考验安全的时候，安全却不起作用了。
在网络安全领域，当我们说起【安全测试】时候，可以进一步细分为多种类型、不同级别的测试，包括：
资产发现： 通过文档或实际检测，发现资产信息、结构，包括系统、模块、组件、接口，以及主机、设备。
漏洞扫描： 使用漏洞扫描工具对被测对象进行漏洞扫描，得到扫描结果，无需人工干涉和参与。
漏洞评估： 基于漏洞扫描的结果，进行人工漏洞分析，排除误报，确保漏洞的准确性。
安全评估： 在漏洞评估的基础上，进行人工安全测试和评估，确保测试覆盖率以及测试准确性，目的是全方位发现安全漏洞，通常也被称为安全测试。
渗透测试： 更贴近真实攻击的测试方式，在安全评估的基础上，利用发现的安全漏洞，目的是测试漏洞的危害和影响，测试手段强调“点到即止”。
红队测试： 在渗透测试基础上，进一步贴近现实攻击，全方位考验目标系统的安全防护能力，攻击手段的多样性和复杂性要超过渗透测试，手段应用突出“分高下，决生死”。
安全审计： 涵盖组织、人员、管理、流程、技术现状，从企业合规性角度进行的审计，部分审计涉及资产发现、漏洞评估，但不涉及渗透测试。
安全评估： 针对产品安全要求的评审，基于产品的设计、技术实现和安全要求做差距分析，不涉及技术工作。
可以看到，如果我们将上面的测试手段进行划分，可以分为技术类测试和非技术类测试。
前者是通过攻防技术或者检测技术检查被测系统的安全漏洞，是在单位级进行的基本测试，主要用于确保系统的基本技术运行和实现的安全。
后者是通过审计、评估进行差距分析，检查系统设计、实现、运行时候的安全风险，是在业务层面进行的宏观测试，主要用于确保系统设计、技术实现与业务目标吻合，且尽可能不受人为因素的干扰或影响。
在元件、系统或产品的安全测试中，上述的测试手段在不同维度只会开展更多，而不会更少。但技术类测试只能检测单点技术实现上的安全风险，无法发现场景使用和产品设计的安全风险。
在SDL（软件安全开发生命周期）中，前期的需求和设计阶段，有三项工作非常重要，分别是确立安全要求、设立安全门槛（bug bar）和威胁建模。顾名思义，安全要求是对产品的安全目标设立目标，安全门槛明确的是安全风险的边界，而威胁建模则是在技术工作投入前尽可能发现潜在的安全威胁并设计对应的应对手段（转移、缓解、消除）。
这在软件开发的安全实践中是可以行得通的，因为软件产品无论有多么严重的安全风险，只要不通过硬件与现实产生交互，其危害程度不足以直接产生人身危害。又或者在有限的硬件能力的交互下，其影响是能够控制在一定程度之下的。
例如，某项业务由资产管理系统与贷款评估系统共同构成。从风险管理角度，应同时关注操作风险与技术风险。在此基础上，必须确保两个子系统之间的数据处理逻辑、接口机制及结果输出的一致性与完整性。
若贷款评估系统核定的贷款金额为人民币30,000元，而资金管理系统实际执行的放款金额为人民币29,999.90元，即便仅存在0.10 元的差异，也表明存在数据一致性缺陷。该缺陷不仅可能引发资金划拨风险，还可能导致会计核算偏差与业务运行风险，从而影响整体资金安全与业务合规性。
但汽车不同，汽车产品被用户使用时是开放世界的开放场景，上述的安全要求设立的前提是场景，一系列技术实现和安全测试都需要基于场景来设计和实现。所以，汽车的可靠性、适应性和安全性测试都只能在大的环境和场景下测试，比如碰撞测试，但产品设计者无论如何也无法穷尽使用者所有的使用场景。
有一家国外厂商生产过一种两面开刃的菜刀，这个产品在使用场景上是无法被国内用户广泛接受的，因为国内菜刀用户许多会在使用菜刀时习惯性使用另一只手按压刀背切开较硬的菜品，这样的菜刀无疑会在用户习惯下会造成用户受伤。
同样，在稳定的、正常场景下使用车辆，即便是没有安全气囊的五菱Mini也不会产生危害，但在不同条件的车祸下，汽车的安全性就很难全方面保证，这既是对于产品设计的考验，也是对驾驶人员能力的考验。
这就是为什么，初次造成，短短三年上市的小米汽车会在安全方面遭遇众多非议，虽然同样的事故换做其他车辆也未必能够保证车内乘客安全。但从产品设计角度，将跑车的性能用于普通民用车就非常糟糕，尤其是发布会时候竟然说有功能可以解锁汽车常见的安全保护，比如ABS等，这无疑是把AK47交给孩子使用，安全隐患非常大。因为厂商永远无法知晓用户对于产品的驾驭能力，更何况为了这样的产品能力而夸大的安全宣传。