热门问题
时间线
聊天
视角
软件系统安全性
来自维基百科，自由的百科全书
Remove ads
软件系统安全性（software system safety）也称为软件安全（Software safety），要确保用在生命攸关系统的软件，不会让系统产生危害。 许多不同领域的安全标准，会指导安全相关软件如何开发和如何测试。大部分会依软件应用的关键程度为软件分级，并针对不同等级的软件，说明在开发和验证过程需要用的技术和量测方式：
- 通用电子安全关键系统的软件：IEC 61508[1]（标准中的第3部分）
- 车用软件：ISO 26262[2] （标准中的第6部分）
- 铁路软件：EN 50716[3]
- 飞航软件：DO-178C[4]
- 空中交通管理软件：DO-278A/ED-109A[5]
- 医疗软件：IEC 62304[6]
- 核电厂：IEC 60880[7]
 |
Remove ads
词语
系统安全是总体性的要求，目的是要将技术系统中的风险降到可接受的程度，以此实现安全性。根据功能安全标准IEC 61508[1]，安全是“不会有无法接受的风险或伤害”。软件本身可以视为是单纯的资讯，本身不会造成伤害，因此有时会将“软件安全”一词改为“软件系统安全”（例如Joint Software Systems Safety Engineering Handbook[8]和MIL-STD-882E[9]就使用此一词语）。后者强调软件只会造成其技术系统的伤害（参考NASA Software Safety Guidebook,[10] chapter 2.1.2），而其伤害会对系统周围有影响。
软件安全的目的是确保软件不会造成所在系统的危害，而且此事可以确认并且证明。这一般是用指定软件的“安全等级”，并且选择适当的开发程序以及证认程序来达到。
指定安全等级
创建安全相关软件时的第一步是依照其安全关键程度来分类。不同安全标准有各自的分类：像是DO-178C的软件等级A-E[4]、IEC 61508的SIL（安全完整性等级，Safety Integrity Level）1-4[1]、ISO 26262的ASIL（车用安全完整性等级、Automotive Safety Integrity Level）A-D[2]。 一般会在系统层级指定安全等级，也会评估软件失效的最坏后果。例如，车用标准ISO 26262要求在整车等级进行危害分析与风险评估（Hazard Analysis and Risk Assessment，简称HARA），以此推导某一元件上软件的ASIL。
流程遵守与保证
在考虑软件的安全性时，需要依软件的安全关键程度，使用充足的开发流程以及验证流程，配合适当的方法或是技术。软件安全标准可能会建议一些方法或是技术，甚至强制使用特定方法或技术，视安全等级而定。 大部分的标准都会建议生命周期模型（像是EN 50716[3]、IEC 61508的SIL 1-4[1]会要求V模型），并且说明在软件开发的不同阶段需要进行的活动。例如，IEC 61508要求软件需要有充份的规格说明（可能用型式方法或是半型式方法）、软件设计需是模组化且可测试的、需使用有充份功能的编程语言、需进行文件化的程式码评审、需有多层级的测试，以达到充够的测试覆盖率。
对软件开发流程和验证流程的注重是源自于一个事实：软件品质（和安全）会高度的受到软件流程的影响，如IEC 25010所述的一样[11]。IEC 25010提出流程会影响内在的软件品质属性（程式码品质），因此也会影响外在软件品质属性（像是功能性和可靠度）。
以下是一些安全软件的开发流程中会提到的活动和概念。
在本质上，所有软件安全标准都会要求针对开发流程和验证流程全面且完整的文件。通常这些文件需经过第三方的评审和核可，是安全相关软件核可的前提。文件包括许多的计划文件、需求规格、软件架构以及设计文件、不同抽象程度的测试案例、工具鉴定报告、评审证据、验证和确认（verification and validation）结果等。在EN 50716的图C.2[3]中列出在开发生命周期中需要创建的32份文件。
需求可追踪性（Requirements traceability）是建立不同种类的需求之间的关系，需求和设计、实现和测试文件之间关系的实务。依照EN 50716[3]，其目的是“确保所有需求都已妥善满足，没有引入任何无法追踪的东西”。透过建立可追踪性的文件，并且维护，就可能让一个安全需求对应到系统设计（以验证设计时已有充份的考量）、再对应到软件程式码（以验证程式码符合需求）、以及适当的测试案例以及测试实做（验证安全需求已被充份的测试）。
未解决的问题
相关条目
脚注
参考资料
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads