不同行业的软件安全标准介绍和对比

转载于知乎Jessie Yang ：https://zhuanlan.zhihu.com/p/112735361

---

引言

随着工业各个领域的系统复杂度和软件功能的快速发展，在每个行业都有相应的软件开发保证标准，来保证所研制的软件达到相应的安全级别。那么各个行业的软件安全标准之间有什么共性和差别呢？

这里简要介绍六种不同的软件开发保证标准，包括民航（DO-178C)、汽车(ISO 26262) 、航天（ECSS-Q-ST-80C）、工业自动化(IEC61508)、核工业（IEC 60880 ） 和轨道（EN 50128），并且比较每个标准在规定的目标、活动、方法和工具上的异同。

各行业安全标准概述

我们先从工业通用标准 IEC61508说起—

• 创始祖师 IEC61508

1985年： IEC成立了一个PESs 工作组，试图对安全相关软件设立一个国际安全标准1998-2000： IEC 61508 Part 1~7 发布

2002年： 开始更新改进标准

2005年： IEC61508 - 0 发布 (Part 0: Functional safety and IEC 61508)

2010年： IEC 61508 Edition 2.0 发布

工作组的本意是建立一个基础模板 — 仅仅用于设定起草各行业标准的规则。但实际上，现在IEC 61508 往往被直接用于工业领域。之后，各分支行业的具体标准从IEC 61508 派生：

各分支行业的具体标准从IEC 61508 派生

过程工业，机械（IEC 61511：2003,62061：2005），电力驱动系统，可编程控制器（IEC 61800：1997，61131-6（CDV）），通信网络（61784-3：2007） ，爆炸性环境，检测，测量，设备（EN 60079,50271,5042），医疗设备（IEC 60601：2005），铁路（EN 50126,50128,50129），汽车（ISO / DIS 26262），其中最接近的一个是过程工业的IEC 61511，因为大多数IEC 61508工作组成员来自该领域。

注：IEC 61508对某些标准的派生关系受到争议，因为某些“行业特定”标准（例如 IEC 61513 核工业）早于IEC 61508发布，并且开发出非常不同的安全方法。

值得注意的是，尽管系出同门，但各行业在标准应用时，与原有运行标准和整体系统方法往往有冲突。比如航空的DO-178C与IEC 61508有很大差异。

• 核能领域

IAEA（国际原子能机构）于1957年在联合国成立，旨在促进和支持安全利用核技术促进和平应用，目前有151个成员国。

已有标准： “安全导则”[IAEA NS-G-1.3]（2002） 为“核电厂安全重要的仪器与控制（I＆C）系统”提供了一般指导，介绍了这些系统的分类，安全要求和设计。它结合和修订了1980年发布的早期指南（50-SG-D3：保护系统和相关功能）和1984（50-SG-D8：安全相关仪器和控制系统）。

根据与国际原子能机构的协议，IEC 在技术细节方面制定了实施国际原子能机构安全原则的标准。自1980年代以来，IEC已经定制了以下设计和验证基于计算机的系统的方法，以满足核电厂的需求：

IEC 61226- 核电厂I＆C（仪器和控制）功能分类方法。

IEC 61513-为用于执行安全重要功能的I＆C系统提供一般指导，并考虑到其分类。

IEC 60880-对核电站最高级I＆C系统的软件提出要求，以实现高可靠性的软件。

• 民用航空领域

1980年，无线电航空技术委员会（现在的RTCA）成立了一个开发和记录软件实践委员会，以支持开发基于软件的机载系统和设备。 欧洲民用航空电子组织（现在的EUROCAE）此前已经成立了一个工作组来制作类似的文件，并于1980年10月准备出版文件ED-35“软件建议书” 机载系统的实践与文献。EUROCAE决定停止编辑自己的文件，并加入RTCA来制定一套通用的指南。 1982年出版了名为ED-12 / DO-178“机载系统和设备认证中的软件注意事项”的联合文件，1985年修订版A，1992年修订版B。2012年发布 ED-12 / DO-178C，包括特定技术或方法的指导原则。

在修订DO-178BB的开发过程中，委员会发现，系统级信息需要作为软件开发过程的输入。 许多系统级决策对于飞机系统的安全和功能方面至关重要，有必要将与这些决策有关的过程和结果进行监管。因此，SAE（汽车工程师协会）和EUROCAE在1995年出版了ED-79 / ARP-4754“高度集成或复杂的飞机系统的认证注意事项”。 它涉及实现飞机级功能的系统总体生命周期。 它重点关注对系统建立安全性的问题，而不覆盖各系统、软件和硬件的具体设计流程。2010年，委员会又进一步发布了ED-79 / ARP-4754A。

2000年4月，EUROCAE / RTCA又发布了文件**ED-80 / DO-254“机载电子硬件设计保证指导”**来解决复杂硬件设计方面的具体要求。

在系统层面，同时还有一个重要的 EUROCAE / SAE文件ED-135 / ARP-4761详细说明了安全评估过程的方法。

民航领域的主要安全标准

• 航天领域

航天领域的监管历史可以追溯到上世纪更早期。联合国COPUOS（和平利用外层空间委员会）于1958年成立，该委员会制定了一系列条约和原则，特别确定了各国本地发射造成的潜在损害的责任。因此，大多数国家已经制定了适用于太空发射活动的规则和法律授权方案。

除了法律制度之外，航天业已经认识到建立和实施空间产品和方案的标准的价值和需要。例如在欧洲，欧空局标准化体系PSS（程序，规范和标准）逐步阐述之后，欧洲航天局与欧洲航天机构和行业在九十年代初建立了欧洲空间标准化组织（ECSS）ECSS，以制定和维护单一、一致、公认的共同标准体系。

ECSS标准不具有法律强制性，可以根据具体情况的协议采用和改编。其实现是通过涉及所有利益攸关方的合作工作来阐述的。
ECSS系列组织为三大分支（M：空间项目管理; Q：空间产品保证; E：空间工程）。
每个分支都有一级标准、可能补充附加文件（更详细的标准或指导，以应用一级标准，或提供额外的非规范性信息的手册）。

• 汽车领域

汽车行业最知名、应用最广泛的安全标准当属 SAE ISO 26262，ISO 26262:（Road vehicles – Functional Safety）是在IEC 61508 标准的基础上，以道路车辆电子及电气系统应用产业的角度，具体规范汽车电子安全系统从开发到使用的安全生命周期的技术与管理要求。

近年来，随着自动驾驶、智能网联的快速发展，ISO PAS 21448、21434 、UL4600 等相关标准也在制定中。

• 轨道领域

轨道行业的国际安全标准主要由CENELEC是欧洲铁路电工设备标准化委员会（替代国家标准）发布，CENELEC与IEC合作，其标准通常被接受为全球标准。目前CENELEC/IEC标准主要包括：

轨道行业主要安全标准

•EN 50126 :1999 (IEC 62278) **（Part2 ：2017）**铁路控制和保护系统的RAMS（可靠性，可用性，可维护性和安全性）规范和演示

•EN 50129:2003 (IEC 62280) 铁路控制和保护系统的安全案例

•EN 50128:2011 (IEC 62279) 铁路控制和保护系统软件

EN 50126 和 EN 50129 关注系统层需求 ， EN 50128 关注软件层需求

预告：下一篇讲继续介绍基于以上标准，各个行业的认证、鉴定、信用批准，以及各个标准的技术比较。

【参考文献目录】

1. Emmanuel Ledinot(1), Jean-Marc Astruc(2), Jean-Paul Blanquart(3), A cross-domain comparison of software development assurance
2. P. Baufreton1, JP. Blanquart2, JL. Boulanger3，Multi-domain comparison of safety standards，2010

---

引言

上一篇文章简要介绍了各个行业主要的安全标准，这一篇继续分享— 基于各行业的安全标准，怎样进行软件认证、工具鉴定、信用批准等方面。

首先，我们来看两个概念----

认证 Certification Vs. 评估 Assessment

谈到安全标准，我们就避不开两个基本概念：认证和评估。

• 评估 Assessment： 为某个实体（个人、组织或人工产品）授予某置信水平的一系列活动。其有效性依赖于： 项目、参与者、使用情况、时间线。
• 认证 Certification: 评估申请人向认证机构证明其工程过程，表明制造商通过遵守安全标准来确保对安全目标的监管。认证旨在验证在一个领域（如能源或运输）提供安全关键产品或服务的工业行为者确实提供了安全的产品或服务。 认证涉及申请人，标准条例，管理局和必须独立或部分独立于申请人的评估机构。

大多情况下，这些标准条例是由国际组织成员国设立的，成员国同意建立共同的规则来防止共同的风险。比如： ICAO在民航，IAEA核工业，联合国在航天工业。某些情况下，标准条例在国家级生效，然后在国际层面上解决跨境互操作性问题。 比如铁路行业，欧洲成员国目前正在执行标准的统一进程 — 相互接受其国家证书。

*注意：工业领域的认证并不会导致责任从申请人转移到认证机构。 在发生严重事故的情况下，涉及的制造商或服务提供者是唯一可以起诉的实体。*

此外，还有一个概念也经常被提及，那就是鉴定 Qualification：

鉴定针对**特定项目中的特定任务，**是为一个实体（可以是一个组织、一个人、一个工具）提供置信水平的一系列活动。

例如，用鉴定来确保通过使用工具自动化的软件生命周期过程将导致与手动执行过程相同或更高质量的输出。

目前，无论是航空、轨道、汽车等领域，还是工业领域，都对工具使用有着特别的要求，如果通过使用工具，消除或者自动化了部分人工工作，都需要根据所涉及的软件安全级别，对所使用的工具进行相应等级的工具鉴定。这实际上是把软件开发人员的部分工作转移到了工具开发商那边。

各行业对评估和认证的信用批准

根据各行业的不同情况，管理局和评估机构可能是同一机构（例如，民用航空局的FAA和EASA），也可能只有颁发证书的机构，但没有与申请人（例如工业自动化和航天业）独立的评估机构的情况。

申请人和评估机构之间的利益无关，是核工业（IRSN）、铁路（ERA，EPSF，STRM-TG）和航空（EASA-FAA）认证的关键要求。

• 航空

由FAA或EASA等独立机构负责飞机及其嵌入式系统的安全认证。

认证通常适用于飞机或发动机类型。

认证机构将软件视为安装在认证飞机或发动机中的机载系统或设备的一部分; 也就是说，认证机构不会将该软件作为唯一的独立产品。 目前，计算机硬件和软件必须做为每次安装的一个“系统”被批准。

• 航天

适用于欧洲航天领域的一系列标准，由ECSS、欧洲航天标准化合作，欧洲航天局，国家航天机构和欧洲工业协会为发展和维持共同目标而合作制定。

ECSS标准不是法律强制的，而是通过合同逐案提出、采用、修改。这并不意味着航天业不会以更严格的方式进行认证 — 大多数国家对于在其领土上发射的航天设备，都制定了与发射装置、航天器、发射程序有关的特定法律规则，以及相应的许可证制度。

• 汽车领域

SAE ISO 26262提供了一系列要求，即所谓的确认措施，以确保对E/E方面的安全性进行适当的评估。

执行确认措施的行为人员应具有与负责发展和释放生产的人员的最低程度的独立性。 **ASIL（汽车安全完整性等级）**越高，所需的独立性就越高。 值得注意的是，所需的最高独立性, 可能允许在同一家公司内。

确认措施包括：

**安全评估，**以验证关键的可交付成果，

安全审计，以验证过程的适当性，

评估整个安全项目的安全评估。

• 轨道交通

主要认证标准是法律要求的欧洲铁路标准 CENELEC 5012x系列标准， 它们是欧盟铁路行业的“实践守则”，也是铁路安全相关应用审批的先决条件和促进市场准入的国际标准，在欧洲各国具有法律的约束力。

认证和鉴定根据符合特定标准和/或规范要求确定。可能需要第三方认证，或进行自我评估。

比较成熟的评估体系包括：英国CASS安全评估框架、德国TUV评估体系等，他们主要以EN铁路标准为基准，依托第三方评估机构对已有线路和在建项目的进行安全性论证。

• 工业自动化

标准IEC 61508 不提供任何类型的认证。

欧洲机械业指令（EMD）要求完成具有CE标识的认证 — 由制造商完成自我认证。

• 核工业

所有使用核能的国家都设立了安全管理局，以控制其使用，保护人民和环境免受辐射的有害影响。比如在法国，安全管理局是ASN大学， 其技术支持是无线电保护和核保安学院（IRSN）。核电厂不是去提交“认证”申请，而是通过授权运营。 根据ASN的提案，授权必须通过政府的正式法令。

一张图总结：

各行业的申请人、评估机构与认证机构

我们可以看到，通常在航空、轨道、航天、核能领域，都要求由独立的第三方机构进行认证，而自动化、汽车领域，并没有强制要求第三方认证（近年来，汽车行业随着自动驾驶的快速发展，安全性要求进一步提升，已经有改变的趋势）。

不同行业，评估和认证独立性要求严格程度递增

预告： 不小心写太长，下一篇继续介绍各行业标准的技术比较。

【参考文献目录】

1. Emmanuel Ledinot(1), Jean-Marc Astruc(2), Jean-Paul Blanquart(3), A cross-domain comparison of software development assurance
2. P. Baufreton1, JP. Blanquart2, JL. Boulanger3，Multi-domain comparison of safety standards，2010

---

引言

上两篇文章简要总结了不同行业的软件安全标准概况和认证、取证，这篇接着来说说各个标准在技术上的具体差别。

Jessie Yang：不同行业的软件安全标准介绍和对比 （上篇）9 赞同 · 0 评论文章

Jessie Yang：不同行业的软件安全标准介绍和对比 （中篇）5 赞同 · 0 评论文章

各个标准的软件安全标准技术比较

不同行业对于软件安全的标准和要求各有特点，基本上可以从几个方面来做个比较和总结：

• 集成安全系统 Vs. 独立安全系统
• 规定目标 Vs. 规定方法
• 严重程度和保证级别分类
• 容错或故障预防
• 概率评估与确定性分析
• 安全案例

1)集成安全系统 Vs. 独立安全系统

根据不同应用和领域，“安全”是通过不同架构来确保的。

比如， 核电、机械自动化、航天和轨道领域通常采用一个专门的安全系统：安全由一个相对独立的系统来监控和保证，与执行所需功能的系统区分开来。而汽车和航空领域，安全性通常是“集成”在功能系统中。

在具体实践中，这种选择是根据风险与保护系统的结构来确定。例如，如果没有特定的安全状态，分离的保护系统是没有作用的，因为在保护系统故障时，不可能将受控设备驱动到安全状态。因此，必须专注于安全控制系统，而不是去开发专用的独立保护系统。

汽车行业，硬件成本是关键的设计驱动。因此，不会考虑专用的独立保护系统。在大多数应用中，控制系统提供内置机制来检测故障并将系统置于安全状态。在某些情况下，当可以使用另一个系统的现有功能作为保护机制时，则会考虑外部安全。

2）规定目标 Vs. 规定方法

各个安全标准，或者对满足高级别安全目标的方法进行规定，或者对目标进行规定，至于方法，则完全由申请人负责。

**方法规范性标准，**在严格按照作者所设想条件的情况下，易于使用。然而，它不能很好地应对新技术、方法和工具的出现。
目标规范性标准可适用于各种技术、生命周期、工具等，但需要在使用前进行解释 ; 并且解释可能存在问题，可能与标准作者的意图有很大差异。

在这两个极端之间，不同的标准采取了各种立场：

IEC 61508和EN 50128是指定方法的，因为它“建议”、“强烈建议”甚至“命令”具体的方法来实现安全目标；

ED-12 / DO-178 一般认为是目标性规定标准；

ISO / DIS 26262和ECSS，通过建议技术方法，混合了一些针对目标的要求。

3）严重程度和保证级别分类

在各个行业领域中，标准都有 “级别”的分类，比如安全完整性级别、关键类别等。其思想是将系统（或功能，组件等）与潜在故障的最坏后果（严重程度）相关联 ，某些领域（例如汽车）里，可能与曝光频率相结合。 经典的基于风险评估的方法中，每个“级别”对发生故障的可能性设置了限制，从而将风险控制在可接受的范围内。

关键类别通常都是分配给功能, 这样就定义了用于开发（和验证）该功能的实施元素（系统\硬件\软件项目）的（部分）需求，以便针对不同类别适当地处理可能的故障来源：

• 随机硬件故障：对于每个类别，安全标准定义了目标最大故障率、导致故障的最小独立错误数。
• 影响系统、硬件或软件设计的开发错误：安全标准定义了适用于所有开发和验证过程的要求，特别是开发和验证流程。对于不同的关键类别（或类似概念)，有着不同的要求，定义不同的DAL（开发保证级别）。 其思想是，不试图量化评估由于这些错误而导致的故障概率，而是考虑满足这些要求，提供了与风险严重程度相当水平的信心。

所有标准在基本原则上都是一致的，并且都认为必须强制隔离不同级别元素之间的故障传播。但是，针对如何对后果的严重程度定义和排序，以及如何分配关键类别（例如，是否以及如何，通过在较低级别采用某种冗余方案，来实现某个级别的功能），标准之间存在着明显的差异。

• IEC 61508 分为SIL 1-4 ，EN50128分为SIL 0-4 ，ISO / DIS 26262分为ASIL A，B，C，D
• ED-12 / DO-178 分为 DAL A，B，C，D ，其中A级针对灾难性后果，为最高级别

每个类别相关的要求甚至其性质也存在差异。

• ED-12B / DO-178B对不同的级别规定了过程目标
• IEC 61508或EN 50128明确列出了不同级别推荐的技术
• ISO / DIS 26262和ECSS，通过建议技术方法，混合了一些针对目标的要求。

4）容错和故障预防

基本上，各个领域中，容错都是在系统级别要求，而不是在软件层面进行要求：软件标准基本上针对如何实现无错误的软件，或明确规定（IEC 60880 或 EN 50128），或隐含要求（ED-12 / DO-178等），通常是通过对过程（例如，清晰全面的文档、遵守规范、设计和代码标准）和产品（例如，验证、确定性结构、管理并行性、完全由输入确定功能的行为）提出要求。

软件标准（如 IEC 60880）通常要求的自检，主要面向随机硬件故障的检测，例如内存损坏或传输错误。在检测到故障的情况下，标准不要求继续正常处理，但要求采取预定义的行为（例如，将输出设置到安全位置）。软件不考虑对自身错误的容错，因为检测和重新配置算法，可能比功能软件本身更复杂，反而增加错误的可能性。

• IEC 60880等标准要求自检不会对预期功能产生不利影响。
• 轨道行业标准 CENELEC EN 50128 指出，不建议软件的向后和向前恢复、动态重新配置和/或故障校正。

**在系统级别或顶层架构上，可以通过冗余设计，实现对潜在软件容错。**例如，系统内的次计算机可以监视主计算机，并使用不同的算法检查其输出的合理性，或者基于涉及不同物理测量的不同算法，两个不同的系统可以独立地触发给定的安全动作。这些架构解决方案之间的选择主要取决于底层受控过程的特征。

5）概率评估与确定性分析

航空，自动化，汽车，核能，铁路和航天领域的可靠性标准中，系统故障风险量化方法是相同的。

各个领域的标准都没有要求/支持对软件故障的概率评估。与硬件相反，软件被统一视为确定性的人为因素，功能故障只会由规范、设计或实现中的错误引起。 因此，软件安全的建设、评估和衡量，通过设计保证来统一处理 ---- 通过基于流程和产品开发活动的标准组合来实施。各个标准根据不同质量和开发活动目标，对于回避开发缺陷的策略的严格程度可分为3~5个级别。但是，每个级别的残余故障或功能障碍无法量化，对于可能引发系统故障的残余软件故障，是通过容错机制来处理的---- 这些机制无论是在软件还是硬件中实现，仍然是确定性的。

概率评估一方面可以量化组件级硬件故障的可能性，另一方面，可以量化系统级别针对用户的灾害事件的可能性。所有的标准都在系统级别，根据灾害事件的严重程度来设置基于概率的目标，从而防范这些事件。

基于“分而治之”的策略，作为实践中唯一易行的方法，各个标准明确或暗示推荐，针对系统级失效行为的概率评估方法不依赖于系统级行为分析 ---- 而是依赖于架构建模，其中可能包括时间依赖的容错重配置逻辑，通过可靠性图表、故障树或状态机捕获事件到功能、功能到部件的依赖关系。

所有标准中，一方面，由设计保证策略规定局部行为（硬件或软件）的确定性分析，另一方面，基于严重程度的概率目标规定了通过“全局功能 – 部件”依赖关系图对事件进行概率分析。

**软件安全标准的重点在于确定性验证。**例如，通过选定的测试来覆盖所有功能，并进一步验证通过这些测试达到适当的结构覆盖。对于安全关键软件（例如，在核能或航空领域），这些测试由独立于开发团队的人员完成。

符合行业特定标准的软件开发，使得根据系统概率目标分配的安全要求得以满足。

6）安全案例

一个安全案例是“一个文献记录的证据体系，提供了令人信服和有效的观点，即系统对给定环境中的给定应用程序是足够安全的”， 目的是展示产品的安全性。所以可以说，安全案例其实就是一篇有论点、论据和认证过程的完整议论文，是认证的基石。 它通常在生命周期内逐步生成，并且在某个里程碑交付，比如进展到详细开发之前，或安装和调试之前。

安全案例是有因果支撑的论据，是一种记录和向利益相关者提供保证的方式，保证由于遵守特定的安全标准，系统是可接受的、安全的。它必须在产品的所有生命周期内（甚至在停产后）更新、可用。

根据不同工业领域或国家，安全案例的构成可能不同。它可以像开发过程中产生的信息集合一样简单，或者是在完整的安全生命周期中收集的完备证据。

• 轨道领域（CENELEC EN 50129）和汽车领域（ISO / DIS 26262）的安全标准就是一个安全案例，CENELEC EN 50129甚至定义了安全案例的内容。
• 航空，核能或航天领域，标准则没有明确提及安全案例，但为了符合该领域安全标准而提供的文件和保证，本身也就是安全案例的内容。

题外话

在和各行业安全人员的交流中，大家常常会问，软件安全分析怎么做？其实，不同行业，软件安全分析的定位各有不同。

**在民航[ARP-4754A; ARP4761; DO-178C]，核[IEC-61513，IEC-60880]，航天[ECSS-Q40; ECSS-Q80]领域，在一定程度上，安全分析在系统级和功能、子系统和设备上执行，但不是以专门的安全分析形式应用于软件。**在这些领域中，软件主要通过遵守软件开发和验证规则来促进系统安全，即通过在相应故障后果的程度上对软件正确性的置信度进行论证。但值得注意的是，对故障后果进行评估，从而确定开发保证级别或软件关键类别，来源于对系统层的安全分析，而不是软件层的安全分析。

**相反，在轨道[EN-50129]或汽车[ISO-26262]等领域，总体的安全理论非常相似，但需要对软件执行专门的安全分析。**在基本安全标准IEC 61508中，软件安全分析包括一套支持功能安全评估的规范性手段。在过程行业领域标准 IEC 61511 中，这个概念才刚刚出现。

总结

对于如何最小化软件开发和验证错误带来的风险，各个领域的安全标准存在许多显著的差异。但这些标准之间主要的差异点并不是程度的多少：比如规则和标准的多少、结构覆盖面或核查独立性的严格程度等等，更主要的差异在于一些更原则的问题：规定目标还是规定方法？ 安全系统如何规划等等。

看看不同领域的标准异同，互通有无，也是蛮有启发的事情。

【参考文献目录】

1. Emmanuel Ledinot(1), Jean-Marc Astruc(2), Jean-Paul Blanquart(3), A cross-domain comparison of software development assurance
2. P. Baufreton1, JP. Blanquart2, JL. Boulanger3，Multi-domain comparison of safety standards，2010