阅读时间
6 分钟

认证本身并不能保证安全。真正的功能安全要求独立合规、完整的软件覆盖和验证的正确性，远远超出一个简单的认证标志。Elektrobit 的面向功能安全应用的 EB corbos Linux for Safety Applications 提供了经过 TÜV 评估的方案，并内置了治理机制，确保您不会单独管理风险。了解您的认证究竟涵盖了哪些内容。

 

认证 ≠ 安全保证

安全认证常被看作一个值得庆祝的里程碑。它表明软件已满足像 ISO 26262 这样的行业标准并通过关键测试。但事实是：认证并不是终点，只是漫长旅程中的一步。

想象你买车时只因为它挡风玻璃上贴有一个安全标签。若你不知道进行了哪些测试、检查得多彻底、认证是否覆盖所有关键部件，这个标签意义就非常有限。对于获得安全认证的 Linux 平台也是一样。 所以真正重要的不是挂在墙上的证书，而是这个证书背后的故事：它是怎么取得的，被检测了哪些软件部分。若不知道这些细节，这个闪亮的安全印章很容易让人产生错误的安全感。

 

合规性（Compliance），而不仅仅是认证（Certification）

人们常误以为认证是一种保证安全的“标签”。实际上，认证是一种在特定边界和范围内，声明某产品遵守某一安全标准的方式。它确认产品达到了被定义的标准，但并不保证在所有环境或所有用例下都安全。

独立性（independence）在展示合规性中起到关键作用。认证机构应当作为公正的评估者，不应在产品开发或最终结果中有利益关联。如果评估者过度参与制定合规包（compliance package），认证的客观性就可能受到影响。这会模糊评估与合作伙伴关系之间的界限，从而有损可信度。

 

 

在 Elektrobit，我们遵循一种清晰的独立评估模式。我们的 EB corbos Linux 安全扩展版本经过像 TÜV Nord 和 TÜV SÜD 这样的独立认证机构评估。评估过程与安全元素（safety elements）是分开审查的，以确保验证不带偏见。任何安全声明的强度在很大程度上取决于合规性是如何被证明的（是否独立被证明）。

 

完整性与正确性：不仅仅是内核

功能安全不只是对某些孤立组件进行技术检查。安全标准要求整个平台在完整性和正确性上都要达标。

• 完整性（completeness）：意味着覆盖所有相关的安全元素。
• 正确性（correctness）：意味着这些元素在所有条件下都按意图工作。

在许多基于 Linux 的、安全认证的平台里，可能只有系统内核的某些功能部分受到认证。平台的其他部分可能不在认证范围之内。这样就迫使使用者必须自己论证未被覆盖的部分如何使用或移除，把安全论证的负担压在用户身上。

很多安全论证依赖上游开源社区，而这些社区并不总是由严格的安全流程来管理。单靠开源软件本身并不能保证“安全设计”（safe-by-design）的质量，特别是当安全流程分散、由社区驱动而没有明确控制时。若你对每一个元素及其开发过程都没完全掌控，那么证明完整性与正确性就会变得困难，信任度也会降低。真正全面的安全需要从头到尾的控制与治理。

 

 

开源流程的瓶颈

开源开发强调速度、透明性与社区推动的迭代。这些都是很大的优点，但它们并非天然适配功能安全所要求的、可追踪的流程。与其事后迫使开源项目去满足所有流程要求，不如在系统中限制它们的角色来保证安全。

这就是为什么架构边界很重要。通过将像 Linux 这种通用组件与安全关键功能隔离开，并在它们之间强制定义严格接口，开发者可以在不重写开源开发规则的情况下限制风险。换句话说，系统的架构承担起重任，让安全不依赖于每个软件组件都完美地符合流程控制。

 

 

在购买前要了解清楚你买的是什么

在你承诺采用任何安全认证的平台之前，值得仔细看看那项认证到底覆盖什么，以及哪些没有覆盖。

总结如下：

• 认证本身不是终极目标。它是合规性被证明的结果，这个过程必须透明且独立。
• 功能安全要求完整性和正确性。部分评估或希望式假设会带来风险。
• 如果一个平台把安全责任转嫁给你（产品使用者/客户），即便它有认证，你也可能仍然面临风险。

Elektrobit 的 EB corbos Linux for Safety Applications 提供一个高度可靠、经 TÜV 评估的平台，带有内建的合规流程与安全执行措施。与我们合作，你不会独自承担风险。你将获得一个可信赖的合作伙伴，帮助你构建更安全的软件定义车辆。

欲深入了解此话题，请查看本博客：为什么功能安全从架构开始，而非审计。

准备好深入了解面向功能安全应用的 EB corbos Linux for Safety Applications 了吗？在此了解更多。