CN103383722B - 一种结合产品和过程的软件安全性举证开发方法 - Google Patents

Abstract

本发明公开了一种结合产品和过程的软件安全性举证开发方法。该方法是一个以危险及危险控制为核心从软件角度实现系统安全性的风险管理，围绕顶层目标，开展满足性和充分正确性二方面举证。满足性举证的目的是表明所举证对象都已经实现并且得到满足，以基于产品方法为主线，从危险、危险控制、危险控制实现的角度进行举证。充分正确性举证的目的是表明举证对象是完整并且正确的，采用基于过程方法通过‘过程规范、人员素质及开发方法’等因素来增强其实现的信心。本发明克服了单从产品或单从过程进行软件安全性举证的缺点，能快速有效地引导软件安全性举证的开发，为软件相关方审查安全性相关情况的提供了一种更有效的方法。

Description

一种结合产品和过程的软件安全性举证开发方法

技术领域

本发明属于软件安全性工程领域，涉及其中的软件安全性评估方法，具体涉及一种结合产品和过程的软件安全性举证技术。

背景技术

安全性是指不发生导致人员伤亡、职业病、设备损坏或财产损失的意外事件的能力。安全关键系统（Safety-CriticalSystem）的控制和安全防护是计算机的一个非常重要的应用领域。随着安全关键系统中软件（被称为安全关键软件（Safety-CriticalSoftware））比重的增加，软件也存在安全性问题。软件安全性对安全关键系统的正常工作和安全运行是至关重要的，已成为国防系统能否正常使用的关键因素之一，如何表明软件达到了系统所要求的安全性水平，一直是管理者和开发商非常重视又是非常困扰的问题。当今，安全性举证（SafetyCase）因为能通过建立合适的论证结构和证据表明目标实现，所以是解决该问题的一个不错的技术。

安全关键系统的开发一般离不开安全性标准的指导，如民航的DO-178B[1]、铁路的EN50128[2]、美军的NASA-STD-8719[3][4]及三军联合手册[5]等。这类标准被称之为过程标准，不仅规定了产品开发过程，也包括了安全性过程，包括使用相关安全性技术。它们最先遭到欧洲诸多学者的质疑[6-8]，如规定的开发过程和技术一般来源于过去的经验，这对于技术创新行业也许不合适；规定的开发过程和技术只能代表标准制定时的最好实践，可能最终阻碍开发人员采用更好的实践，反而可能限制软件产品质量的提高；规定的开发过程和技术可能造成这样的误解：软件安全性的责任在于标准的制定者，而不是软件服务的提供者等。

于是欧洲学者提出了基于目标论证的安全性举证方法，相比于上述过程标准，它将证实和展示系统安全性的责任更多地转移给系统开发方和运行者，由监管机构制定顶层目标，开发方和运行者自由灵活地建立合适的论证结构和证据来证实满足了这些目标。安全性举证方法适用性和易用性较强，不仅能够有效地解决上述问题，而且当缺乏过程标准指导时也能对安全性要求实现情况进行举证。目前安全性举证已经在欧洲核工业、航空、船舶、铁路、石油、医疗、矿产等行业得到了广泛应用，尤其在英国。这些行业一般是高风险的，其产品在部署运行前往往需要向监管部门和公众表明是足够安全的。安全性举证不仅关注开发过程更关注产品行为，也强调与上述标准进行集成，它不是取代当前安全性分析和审查活动，而是处于补充的角色来促进构建关键和系统化论证来证实系统开发、维护和运行安全性。

现有软件安全性举证的开发方法主要集中在二方面：一是基于过程的方法；二是基于产品的方法。Weaver在自己的博士论文中将基于过程的方法定义为：推荐或提供的开发过程和方法，安全性由过程质量来决定；基于产品的方法定义为：显式的、直接与系统安全性需求相关的安全性证据[9]。现在有些观点对基于过程的保证持批判态度[6]。首先，缺乏证据说明遵守过程的规范可以得到特定完整性等级的软件。另外，固定的过程规范阻碍了新过程方法的应用。最后，由于SILs和DALs在不同领域的详细要求不同，DAL/SIL的声明不能在不同领域间轻易的“转换”。比如，DO-178B的A级要求不能够直接横跨到IEC61508SIL4级的需求。单从基于产品的安全性举证方法也遭到质疑[10]。最主要表现为：产品论据的正确性依赖于证据，但是证据不一定是正确的。比如证据“黑盒测试结果”的正确性与测试过程有很大关系。这种方法中证据可能存在的可信性问题将会降低对评定结果的信心。

软件安全性举证技术因能通过建立合适的论证结构和证据表明目标实现而在软件安全性评估领域越来越受到重视，但单从过程和产品的方法对软件安全性进行举证都不充分，可以考虑将二者结合起来对软件安全性进行举证。

发明内容

本发明克服了单从产品或单从过程进行软件安全性举证的缺点，将二者相结合，以基于产品为主、基于过程为辅的思想，提出结合产品和过程的软件安全性举证开发方法，指明了软件安全性举证开发的“满足性和充分正确性”的举证思路及与此相关的证据类型。本发明给软件安全性举证开发提供了一个更有效更系统的视角。

本发明提供了一种产品和过程的软件安全性举证技术，该技术包括以下步骤：

步骤1：进行系统危险分析。获取并标识系统危险、危险原因和危险控制方法；明确系统危险列表中每个危险的等级及出现的可能性，选择安全性需要关注的危险。

步骤2：对系统危险进行充分正确性和满足性举证。结合影响系统危险获取的过程因素举证危险是完整的和正确的；通过举证软件安全性需求的实现来表明危险已消除或缓解，从而说明从软件角度而言系统的安全性水平是可接受的。

步骤3：进行软件安全性需求分析。获取并标识软件安全性需求，将与软件相关的危险原因和危险控制转换为软件安全性需求，同时再通过由底向上的方式、通用安全性需求补充软件安全性需求。

步骤4：对软件安全性需求进行充分正确性和满足性举证。结合软件安全性需求获取的过程因素举证软件安全性需求是完整的和正确的；通过举证危险软件失效原因已规避来表明软件安全性需求已实现。

步骤5：进行危险软件失效分析。获取危险的软件失效列表，针对每个软件安全性需求，分析软件安全性需求列表中每个软件安全性需求相应的危险软件失效、失效原因和失效改进措施。

步骤6：对危险软件失效进行充分正确性和满足性举证。结合危险软件失效获取的过程因素举证危险的软件失效是完整的和正确的；通过举证危险软件失效改进措施的实现来表明危险软件失效原因已规避。

步骤7：对危险软件失效改进措施进行满足性举证。获取程序代码和测试结果，从程序代码审查和测试两方面提供证据来表明危险软件失效改进措施已实现。

所属步骤1中的危险和危险状况的预防是安全性工作的关注对象，而危险指可能导致或者引起一个一个意外事故或者事故的现有条件或潜在条件。系统危险分析的目的是标识潜在的系统危险，并且可能标识哪些子系统会造成这些危险（标识危险原因）或者需要哪些子系统来控制这些危险（标识危险控制），而危险原因和危险控制可能与软件相关。因此系统危险分析是软件安全性举证的第一步，应由软件安全性人员参与，一般开始于使用所吸取的经验教训、意外事故数据、类似系统的初步危险分析和工程判断，最初是由硬件的激励器、末端效应和能源以及可能发生的危险，随着危险分析过程继续，在后续的安全性分析中对危险进行修订和更新。同时，还需要对危险的严酷度等级及发生可能性（即风险指数）进行分析。严酷度等级可分为：灾难的、关键的、适度的、轻微的及无影响；发生可能性可包括极可能、很可能、可能、不太可能及不可能。根据风险指数的不同，选择安全性举证需要关注的危险，重点关注严重性程度高、可能性概率高的危险。

所属步骤2中的系统危险的举证要求包括二个方面：充分正确性和满足性举证，即系统危险的确认和系统危险的消除或缓解。在系统级别必须能提供证据表明这二个方面已满足。如果能表明识别的系统危险是充分正确且均得到了消除或缓解，那么就可表明系统达到了一个可接受的安全性水平。

充分正确性举证的目的是要表明已标识的危险是完整且正确的，可以从系统危险的识别方法、识别人员、识别过程等方面让人信服。特别需要重点论证系统危险的识别方法，表明该方法能识别出与系统相关的所有可能的危险，能充分表明在识别系统危险方面所付出的努力。

满足性举证的目的是要表明已标识的系统危险已消除或缓解。可以举证“危险控制的实现”，即举证“硬件、软件和其它部分安全性需求的实现”让人信服。危险控制是一种用于预防危险、降低危险发生可能性或者降低危险影响的方法。对于每一个危险及危险原因，必须至少有一个控制方法，通常是一个设计特征（硬件/软件）或一个过程性步骤，也可使用硬件、软件、操作规程或者这些方法的组合，以避免危险。

所属步骤2中的举证的表述方法可以采用目标构建法GSN（GoalStructuringNotation），它主要包括目标、策略、解决方案、背景、合理性解释和假设等基本元素。这些元素组合在一起形成了目标结构，目的在于表明一个总目标是如何分解成子目标的，并最终由证据（解决方案）支持，同时通过策略解释证据是如何支持目标的，可用背景、合理性解释和假设对目标、策略和解决方案进行补充说明。基于GSN构建安全性举证的过程：第一步，确定安全性举证目标。第二步，确定目标提出的背景、假设、合理性解释等附加要素。第三步，确定按照什么样的策略对目标进行分解。第四步，定义策略的背景、假设、合理性解释等附加要素。第五步，按照策略分解目标，分解得到的证据，如果需要继续分解，还要返回第一步反复这个步骤。第六步，当一个子目标不能再进一步分解时，就需要确定证据以支持这个子目标。

所属步骤3中的软件安全性需求是指那些用于缓解或解决软件是潜在的危险原因或者保证软件用作危险控制有效的软件需求。一般而言，为了保证完全覆盖功能安全性的所有方面，将软件安全性需求分为以下两种类型：a）“必须工作”的功能，是为了软件正确地运行必须工作的那些方面。从安全性的观点出发，只考虑未来防止危险或者其它安全性相关事件发生而必须工作的那些功能。b）“必须不工作”的功能，是在软件正确运行时不应出现的那些方面。事实上，如果这些“必须不工作”的功能确实出现，那么，它们将导致一个危险的情况或者其它不期望的后果。通常软件安全性需求只根据软件必须工作的特性来表示软件的安全性，而常常忽略必须不工作功能的关键性。

软件安全性需求可以从二个方面进行获取：a）自顶向下流动而成的软件安全性需求。与软件相关的危险原因和危险控制，从而可直接将危险控制映射到软件，或通过头脑风暴，标识出软件危险控制特征并将其说明为软件安全性需求。这些软件安全性需求可直接追踪到系统危险（或系统安全性需求）。b）自底向上分析而成的软件安全性需求。在逐步成熟的软件相关信息的基础上，通过对软件功能或设计数据进行失效模式影响分析(FMEA)、危险和操作性分析(HAZOP)等自底向上分析，对系统需求允许但不期望的设计实现进行分析，并标识新的软件安全性需求。

所属步骤4中的软件需求的举证要求包括二个方面：充分正确性和满足性举证，即软件安全性需求的确认和软件安全性需求的实现。在软件级别必须能提供证据表明这二个方面的满足。如果能表明标识的软件安全性需求是充分正确且全部都已经实现，那么就可表明软件在系统环境下达到了一个可接受的安全性水平。

充分正确性举证的目的是要表明已标识的软件安全性需求是完整且正确的。许多归因于软件问题导致的系统危险最终都可以追踪到遗漏、不正确、误解或者矛盾的需求。因此，软件安全性需求的充分正确性论证是非常必须和重要的。可以从软件安全性需求的获取方法、获取人员、获取过程等方面让人信服已获取的软件安全性需求是完整且正确的。特别需要重点论证软件安全性需求的获取方法，表明该方法能识别出在系统环境下与软件相关的所有可能的安全性需求，能充分表明在获取软件安全性需求方面所付出的努力。

满足性举证的目的是要表明软件安全性需求已经实现。软件安全性需求没有实现即表明存在危险软件失效，所以可以通过论证危险软件失效已经消除或缓解来表明软件安全性需求的实现。针对每个需求进行独立的举证，可以通过举证软件的危险失效模式已经：a）在软件中消除；b）在软件中得到控制；c）通过系统的其他组件得到控制。

所属步骤5中的危险软件失效是指能引起危险的软件失效。软件失效模式一直是软件界的关注对象和研究重点。比较有代表性的软件失效模式分类有：GJB/Z1391-2006《故障模式、影响及危害性分析指南》、IEEE“StandardtoClassificationforSoftwareAnomalies93”标准、国标GB/T11457-1995《软件工程术语》（TermsofSoftwareEngineering）、Goddard,P.L.的分类方法。其中，IEEE标准中的软件异常分类最具有代表性。因此，在此采用了其中的“程序挂起、程序失败、输出问题、未达到性能要求、系统错误信息和其它”六类，安全关键软件一般是嵌入式软件，一般可不考虑“操作系统失败和整个产品失效”。

所属步骤6中的危险软件失效的举证要求包括二个方面：充分正确性和满足性举证，即危险软件失效的确认和危险软件失效的消除或缓解。在软件功能级别必须能提供证据表明这二个方面。如果获取的危险软件失效改进能够被表明是充分正确且全部都已被消除或缓解，那么就可表明软件的安全性需求都已实现。

充分正确性举证的目的是要表明已确定的危险软件失效是完整且正确的，可以从危险软件失效的获取方法、获取人员、获取过程等方面让人信服已确定的危险软件失效是完整且正确的。

满足性举证的目的是要表明确定的危险软件失效都已经实现，可以通过分析危险软件失效原因，进而确定危险软件失效改进措施，从而通过危险软件失效改进措施的实现来表明危险软件失效不会发生。

所属步骤7中的危险软件失效已消除或缓解最直接的证明手段是用程序代码表明引发危险软件失效的原因都有相应的措施来规避，从而进行举证，其目的是通过提供相应的程序代码表明危险软件失效不会发生。程序代码是危险软件失效消除或缓解得到实际实现的最直接体现。另一方面，危险软件失效已消除或缓解最好的证明手段是用软件测试结果（也可用分析、评审等其它手段）表明危险软件失效不会发生，从而进行举证，其目的是通过提供不同的测试结果表明危险软件失效不会发生。

结合产品和过程的软件安全性举证开发方法具有如下优点：

（1）提升了软件安全性举证的信心。将基于产品的方法和基于过程的方法结合起来，以基于产品为主、过程为辅的思想阐述了软件安全性举证开发的主要内容，克服了单从产品或单从过程进行软件安全性举证的缺点，从而增强了举证结果的信心。

（2）能快速有效地引导软件安全性举证的开发。该方法指明了软件安全性举证开发的“满足性和充分正确性”的举证思路及与此相关的证据类型，从危险识别、危险消除或缓解、软件安全性需求实现及危险软件失效改进措施的满足的角度系统而又完整地给出了软件安全性举证的开发过程，为软件安全性举证的开发提供了指导。

（3）为软件安全性的定性评估提供了途径。能直接有效地聚集和组织各种与安全性相关的证据；通过策略、假设、背景信息等，能够清晰地表述安全性需求和支持证据之间的结构和关系，便于审查论证、质疑证据，为软件相关方有效审查安全性相关情况的一种不错的手段。

（4）为软件安全性工作改进提供了方向。从过程改进角度来看，基于产品和过程的角度提出的框架指明了软件安全性工作的重点和方向，必须围绕危险识别-危险控制-控制实现开展软件安全性工作。

附图说明

图1是软件安全性举证开发框架示意图；

图2是软件安全性举证过程因素示意图；

图3是基于目标构建法GSN表示软件安全性举证流程；

图4是软件安全性需求获取流程；

图5是危险软件失效获取流程。

具体实施方式

下面结合附图和实施例对本发明进一步说明。

软件安全性举证的开发包含三部分的内容：确定软件安全性顶层要求、构建软件安全性论据、选择相应的证据。图1描述了结合产品和过程的软件安全性举证开发框架。该框架是一个以危险及危险控制为核心从软件角度来实现系统安全性风险管理的闭环，其构建思路是以基于产品方法为主、基于过程方法为辅的思想，将二者相结合。依据软件安全性定义，将软件安全性举证开发的最顶层目标设为‘软件在系统环境中运行产生的风险是可接受的’。为了表明这个目标的实现，软件安全性举证中论据开发从以下二个方面展开：

1）满足性举证：表明所举证对象都已经实现并且得到满足。以基于产品方法为主线，从危险识别、与软件相关的危险控制及控制实现等角度进行举证。

2）充分正确性举证：表明所举证对象是完整并且正确的。采用基于过程方法增强其实现的信心。

围绕软件安全性顶层目标，首先从系统危险出发，从危险原因、危险遏制及预防措施等角度来获知软件对危险的贡献，进而获取软件安全性需求。通过举证软件安全性需求的实现来表明软件对危险的贡献已消除，进而也表明软件安全性顶层目标的实现，其前提是能完整正确地获取了软件安全性需求，即需要对软件安全性需求进行充分正确性举证。

软件安全性需求没有实现即说明软件失效，这种失效称为危险软件失效，所以可以通过举证危险软件失效已经消除或缓解来表明软件安全性需求的实现，当然其前提是能完整正确地获取了危险软件失效，即需要对危险软件失效进行充分正确性论证。

危险软件失效没有被消除或缓解即说明软件存在缺陷（失效原因），没有合适的改进措施避免软件失效的发生，所以可以进一步通过程序代码和测试来验证软件中不存在导致危险软件失效的缺陷，当然基于提供的程序代码和测试结果是可信的。

为了进行充分正确性论证和可信论证，虽无法给出证据直接表明其实现情况，但可以从软件界达成的共识“软件质量源于软件过程”这个角度出发，通过论证“过程规范、人员素质及开发方法”等面向过程的因素来增强其实现的信心。

图2描述了进行充分正确性论证的软件安全性过程因素。将在工程中造成产品质量波动原因的六个因素‘人、机、料、法、环、测’引入其中，从软件人员素质、软件工具使用情况、软件过程规范性、软件开发方法正确性、软件验证方法正确性和软件相关环境合理性六个方面进行论证。

1）软件人员。人犯的错误是软件失效链的源头。人是影响软件安全性的核心过程因素，其主要要求有：

a）建立相应的软件人员梯队；

b）相关软件人员符合岗位技能要求，经过相关培训考核；

c）相关软件人员应具备专业知识和操作技能，考核合格者持证上岗；

d）相关软件人员严格遵守软件过程规范和标准，对工作和质量认真负责。

2）软件工具使用。软件开发本身不再是“算法+数据结构=程序”的结构，而是成为了“设计模式+对象组件+工具=程序”。因此，工具的选择和使用是影响软件安全性的重要要素之一，其主要要求有：

a)建立相应的软件工具集；

b)软件工具均符合软件实际需要，能满足软件开发各环节需要；

c)软件工具处于完好状态和受控状态；

d)有完整的软件工具管理办法，包括软件工具购置、维护、检测等均有明确规定；

e)软件工具各项管理方法均有效实施，有软件工具台账、工具技能档案、维护检测计划和相关记录，记录内容完整准确。

3）软件过程规范。过程规范是指影响软件安全性开发的过程保障的标准、规范、操作规程，能有效预防管理失误和操作失误，是预防软件失效的重要手段，要使每个软件开发人员、管理人员及软件安全性人员不违章操作，熟悉工作规程方法，明白工作流程，知道今天做什么、为什么做、谁做、什么时候做、怎么做才能减少失误，预防软件失效。一般过程规范要求包含：

a)建立相应的软件过程；

b)有正规有效的软件生产过程、质量控制、配置管理等操作文件。对人员、操作流程、技术方法等提出具体的技术要求；

c)对每个质量控制点规定检查要点、检查方法和接收准则，并规定相关处理办法；

d)规定并执行软件体系文件的编制、评定和审批程序，以保证生产现场所使用文件的正确、完整、统一性，软件体系文件处于受控状态，现场能取得现行有效版本的文件；

e)各项文件能严格执行，记录资料能及时按要求填报。

4）软件开发方法。软件开发方法是影响软件质量和安全性最直接的因素，其主要要求：

a)软件开发过程所使用的技术方法（包括需求分析方法、体系结构方法及所使用的语言等）选择正确并正确使用。

5）软件验证方法。软件的验证包括分析和测试二个方面，其主要要求：

a)选择合适的软件安全性分析方法且方法使用正确；

b)选择合适的软件测试方法且方法使用正确。

6）软件相关环境。软件开发环境及平台满足软件开发要求，其主要要求：

a)软件测试环境及平台满足软件测试要求；

b)软件运行环境及平台与文档描述一致。

图3描述了GSN开发流程、基本符号及一个简单的示例。GSN是GoalStructuringNotation的简称，是表达安全性论据结构的图形化表示法。GSN首先由ASAM-II（ASAM是Asafetyargumentmanager的简称）项目提出，随后在核工业、国防、航空和铁路企业广泛应用。它明确的表达了每个安全性举证的独立成分（目标、论据、证据和背景等）以及这些部分之间的联系，如论据如何支持独立的需求，证据如何支持论据和论据成立的假设或前提等。GSN的基本符号包括：

1）目标（Goal）：阐述了安全性举证的目的，应当采用简单的谓词形式，及它可以用是或否来回答，目标的层次由顶层目标和子目标组成。

2）策略（Strategy）：被认为是一种求解目标的规则。目标可以通过策略进行求解，也就是通过策略将目标分为一系列解决方案。

3）解决方案（Solutions）：描述了一个目标被满足的证据。可以直接用来求解目标，而不需要对目标进行分解。解决方案可以是独立的分析、证据或评审报告的结论以及参考的设计材料等。

4）合理性解释（Justification）：使用某个目标或策略的理由。策略的使用需要进行判断，判断产生了支持策略的要求或证据。

5）假设（Assumption）：是GSN其它元素有效的一个声明。

6）背景（Context）：是对目标及策略中的相关名词进行解释和备注，为了更好地理解GSN中其它元素的所需信息。

利用GSN构建符合要求的安全性举证的流程如下：

步骤1，确定安全性举证目标。目标是要举证的对象，目标可能来自安全工程师、供应商、客户和开发人员的小组会议得出，也可能是安全性需求文档的一部分。目标必须符合以下的规定：

●目标是二元的，只能成立或不成立，不存在第三种情况。如“代码中存在死循环吗”。这就是正确的目标，而“代码中存在多少错误”就不是一个正确的目标，因为它是无法去论证的；

●目标不仅局限于可被客观论证的对象，也可以包含主观性的观点；

●目标必须是“主谓结构”，主语是目标的主体，谓语是目标的行为。

步骤2，确定目标提出的背景、假设、合理性解释等附加要素。目标要被举证，那么它就不能让人存有疑问，必须对目标涉及的所有需要解释的术语进行实例化。如目标“软件的安全性是可接受的吗？”，就需要对“软件”、“可接受”两个概念做出界定，否则无法继续论证；

步骤3，确定按照什么样的策略对目标进行分解。策略的作用就是指出目标分解的方法。但并不是所有的目标分解都需要策略。如对目标“软件的开发是符合DO178B标准的”，分解策略就可以定为“按照DO178B规定的软件开发过程展开论证”。但如果目标是“需求X是否得到满足”，就可以直接得出下一级子目标“软件可以检测到发生的异常并立即关闭系统”。更准确的说，第二种情况分解的到的目标其实是对上层目标的解释和细化，而策略是将大范围的目标分解到小范围，它解释了下层目标和上层目标之间的关系。同一个目标可以用多种不同角度的策略进行分解；

步骤4，定义策略的背景、假设、合理性解释等附加要素。如果需要对策略做进一步的说明，要将这些说明纳入到背景或假设中，比如上一步的策略“软件的开发是符合DO178B标准的”，其假设可以是“软件按照D0178B第二等级要求开发”；

步骤5，按照策略分解目标，分解得到的证据，如果需要继续分解，还要返回第一步反复这个步骤；

步骤6，当一个子目标不能再进一步分解时，就需要确定证据以支持这个子目标。

图4描述了软件安全性需求获取流程。从系统角度确定的软件对危险的贡献将随着软件开发进一步转化为软件安全性需求，指导后续的软件开发。软件安全性需求可以从各种不同的来源中获得，一般可以分为二类：通用的和特定的。通用的软件安全性需求从一些需求和最佳实践的集合中推导出来，这些需求和最佳实践的集合可以在不同的项目和环境中用于解决共同的软件安全性问题。特定的软件安全性需求是系统独特的功能能力或者约束。为了完整地标识出所有的软件安全性需求，制定了如下步骤的软件安全性需求获取流程：

步骤1：从软件对危险的贡献直接映射到软件安全性需求。从系统相关信息出发可以识别出系统危险、危险原因及危险改进措施。其中，将与软件相关的危险原因及危险控制措施直接转换为软件安全性需求。这些就是软件安全性需求的一部分；

步骤2：通过SFTA、ETA、STPA等分析方法从自顶向下补充软件安全性需求。通过对系统设计需求进行自顶向下的分析，系统需求可以在早期标识出系统危险，并规定哪些功能是安全关键的，将这些功能的失效作为分析的顶事件，就可找出失效的原因链，与软件相关的原因可转换为软件安全性需求；

步骤3：对软件需求进行SFMEA、HAZOP等分析方法从自底向上补充软件安全性需求。通过对软件功能或设计数据进行失效模式影响分析(FMEA)、危险和操作性分析(HAZOP)等自底向上分析，对系统需求允许但不期望的设计实现进行分析，可标识出新的软件安全性需求；

步骤4：根据软件具体特点从软件安全性通用需求库选择并实例化后补充软件安全性需求。

图5描述了危险软件失效获取分析流程。软件失效并非都有相同的影响后果，危险软件失效强调会产生严重后果的失效，其获取流程如下：

步骤1：收集软件失效模式分类。

软件失效模式一直是软件界的关注对象和研究重点。比较有代表性的软件失效模式分类有：GJB/Z1391-2006《故障模式、影响及危害性分析指南》、IEEE“StandardtoClassificationforSoftwareAnomalies93”标准、国标GB/T11457-1995《软件工程术语》（TermsofSoftwareEngineering）、Goddard,P.L.的分类方法。其中，IEEE标准中的软件异常分类最具有代表性，如表1所示。

表1IEEE软件异常分类

步骤2：获取类似软件的已有的失效数据、分析软件的相关信息。尽可能通过各种渠道收集类似软件已经发生的失效，重点掌握软件自身信息，包括软件所在的系统结构、可能的系统危险、与软件相关的危险原因及危险控制、软件功能结构、软件外部接口等。

步骤3：参考软件失效模式分类、依据软件相关信息及类似软件的失效信息，针对每个软件安全性需求，分析其可能的失效，获取危险软件失效列表。

步骤4：针对每个危险软件失效，分析危险软件失效原因及改进措施。

软件失效的原因是软件中潜藏的缺陷，一个软件失效的产生可能是由一个软件缺陷引起的，也可能是由多个软件缺陷共同作用引起的。在进行失效原因分析时应尽可能全面地分析所有可能的软件缺陷，为制定改进措施提供依据，可参考已有的软件失效原因分类，如逻辑遗漏或执行错误、算法的编码错误、软硬件接口故障、数据操作错误、数据错误或丢失。而改进措施可以有两种途径，一是修改软件缺陷，二是增加硬件防护措施。

[1]RTCADO-178BSoftwareConsiderationsinAirborneSystemsandEquipmentCertification[S].1992.

[2]CENELEC,EN50128RailwayApplications:SoftwareforRailwayControlandProtectionSystems[S].EuropeanCommitteeforElectrotechnicalStandardisation,1997.

[3]NASA-STD-8719.13BNASAsoftwaresafetystandard[S].2004.

[4]NASA-GB-8719.13NASASoftwareSafetyGuidebook[S].2004.

[5]JointSoftwareSystemSafetyCommittee,SOFTWARESYSTEMSAFETYHANDBOOK[S].1999.

[6]FRedmill,SafetyIntegrityLevels–TheoryandProblems,LessonsinSystemSafety[C],ProceedingsoftheEighthSafety-CriticalSystemsSymposium,editedbyT.Anderson&F.Redmill,Springer-Verlag,2000.

[7]McDermidJA.Softwaresafety:where'stheevidence?[C].ProceedingsoftheSixthAustralianWorkshoponIndustrialExperiencewithSafetyCriticalSystemsandSoftware,AustralianComputerSociety,2001.

[8]BloomfieldR,BishopP.SafetyandAssuranceCases:Past,PresentandPossibleFuture-anAdelardPerspective[C].theEighteenSafety-CriticalSystemsSymposium.Bristol,UK:2010.2:51-67.

[9]R.A.Weaver.TheSafetyofSoftware-ConstructingandAssuringArguments[D].Ph.DThesis,DepartmentofComputerScience,UniversityofYork,2003.

[10]I.Habli,T.P.Kelly.ProcessandProductCertificationArguments-GettingtheBalanceRight[J].ACMSIGBEDReview,Volume3,Issue4,October2006.

Claims (6)

1.一种结合产品和过程的软件安全性举证开发方法，其特征在于包含以下步骤：

(1)进行系统危险分析：获取并标识系统危险、危险原因、危险等级、危险出现的可能性和危险控制方法，选择安全性需要关注的危险；

(2)对系统危险进行满足性举证和充分正确性举证：结合影响系统危险获取的过程因素举证危险是完整的和正确的，通过举证软件安全性需求的实现来表明危险已消除或缓解，从而说明从软件角度而言系统的安全性水平是可接受的；

(3)进行软件安全性需求分析：获取并标识软件安全性需求，将与软件相关的危险原因和危险控制转换为软件安全性需求，同时通过由底向上的方式、通用安全性需求补充软件安全性需求；

(4)对软件安全性需求进行满足性举证和充分正确性举证：结合软件安全性需求获取的过程因素论证软件安全性需求是完整的和正确的，通过举证危险软件失效原因已规避来表明软件安全性需求已实现；

(5)进行危险软件失效分析，获取危险的软件失效列表：针对每个软件安全性需求，分析相应的危险软件失效、失效原因和失效改进措施；

(6)对危险软件失效进行满足性举证和充分正确性举证：结合危险软件失效获取的过程因素举证危险的软件失效是完整的和正确的，通过举证危险软件失效改进措施的实现来表明危险软件失效原因已规避；

(7)对危险软件失效改进措施进行满足性举证：获取程序代码和测试结果，从程序代码和软件测试两方面提供证据来表明危险软件失效改进措施已实现。

2.根据权利要求1中所述的方法，其特征在于：所述的满足性举证和充分正确性举证体现了软件安全性举证思路是以基于产品方法为主、基于过程方法为辅二者相结合的思想，基于产品方法的举证称为满足性举证，基于过程方法的举证称为充分正确性举证：

(1)满足性举证：表明所举证对象都已经实现并且得到满足，以基于产品方法为主线，从危险识别、与软件相关的危险控制的角度进行举证，首先从系统危险出发，获取软件对危险的贡献，之后论证危险软件失效已消除或缓解来说明软件对危险的贡献已消除，最终的证据为程序代码和软件测试结果；

(2)充分正确性举证：表明所举证对象是完整并且正确的，采用基于过程方法增强其实现的信心，从软件界达成的共识“软件质量源于软件过程”这个角度出发，通过论证“人员合格、工具/环境合理、过程规范、方法正确”面向过程的因素来增强其实现的信心。

3.根据权利要求1中所述的方法，其特征在于：所述的满足性举证和充分正确性举证的表述方法采用目标构建法GSN(GoalStructuringNotation)，主要包括目标、策略、解决方案、背景、合理性解释和假设六个基本元素，利用GSN构建符合要求的安全性举证的流程包括以下步骤：

(1)确定安全性举证目标，目标是要举证的对象，具有如下特点：目标是二元的，只能成立或不成立，不仅局限于可被客观论证的对象，也包含主观性的观点；目标是“主谓结构”，主语是目标的主体，谓语是目标的行为；

(2)确定目标提出的背景、假设、合理性解释这些附加要素，目标要被举证，必须对目标涉及的所有需要解释的术语进行实例化；

(3)确定按照什么样的策略对目标进行分解，同一个目标允许用多种不同角度的策略进行分解，但并不是所有的目标分解都需要策略；

(4)定义策略的背景、假设、合理性解释这些附加要素，如需要对策略做进一步的说明，要将这些说明纳入到背景或假设中；

(5)按照策略分解目标，分解得到的证据，如果需要继续分解，需返回第一步反复这个步骤；

(6)当一个子目标不能再进一步分解时，就需要确定证据以支持这个子目标。

4.根据权利要求1中所述的方法，其特征在于：所述的过程因素包括软件人员素质、软件工具使用情况、软件过程规范性、软件开发方法正确性、软件验证方法正确性和软件相关环境合理性六个方面：

(1)软件人员，主要要求有：建立相应的软件人员梯队，软件人员符合岗位技能要求，具备专业知识和技能，严格遵守软件过程规范和标准，对工作和质量认真负责；

(2)软件工具使用，主要要求有：建立相应的软件工具集，软件工具符合软件实际需要，能满足软件开发各环节需要，处于完好状态和受控状态，有完整的软件工具管理办法并有效实施，有软件工具台账、工具技能档案、维护检测计划和相关记录，记录内容完整准确；

(3)软件过程规范，主要要求有：建立相应的软件过程，有正规有效的软件生产过程、质量控制、配置管理相关的操作文件，软件体系文件处于受控状态，现场能取得现行有效版本的文件，各项文件能严格执行，记录资料能及时按要求填报；

(4)软件开发方法，主要要求有：选择合适的软件开发方法且方法使用正确；

(5)软件验证方法，主要要求有：选择合适的软件安全性分析方法且方法使用正确；选择合适的软件测试方法且方法使用正确；

(6)软件相关环境，主要要求有：软件测试环境及平台满足软件测试要求；软件运行环境及平台与文档描述一致。

5.根据权利要求1中所述的方法，其特征在于：所述的软件安全性需求是指那些用于缓解或解决软件是潜在的危险原因或者保证软件用作危险控制有效的软件需求，包括“必须工作”和“必须不工作”的功能，其获取方法包括以下步骤：

(1)从软件对危险的贡献直接映射到软件安全性需求：从系统相关信息出发识别出系统危险、危险原因及危险改进措施，其中，将与软件相关的危险原因及危险控制措施直接转换为软件安全性需求；

(2)通过SFTA、ETA、STPA安全性分析方法从自顶向下补充软件安全性需求：通过对系统设计需求进行自顶向下的分析，在早期标识出系统危险，并规定哪些功能是安全关键的，将这些功能的失效作为分析的顶事件，找出失效的所有原因，并将与软件相关的失效原因转换为软件安全性需求；

(3)对软件需求进行SFMEA、HAZOP安全性分析方法从自底向上补充软件安全性需求：通过对软件功能或设计数据进行失效模式影响分析(FMEA)、危险和操作性分析(HAZOP)对系统需求允许但不期望的设计实现进行分析，标识出新的软件安全性需求；

(4)根据软件具体特点从软件安全性通用需求选择并实例化后补充软件安全性需求。

6.根据权利要求1中所述的方法，其特征在于：所述的危险软件失效是指能引起危险的软件失效，强调会产生严重后果的失效，其获取应包括以下步骤：

(1)收集软件失效模式分类；

(2)获取类似软件的已有的失效数据、分析软件的相关信息，尽可能通过各种渠道收集类似软件已经发生的失效，重点掌握软件自身信息，包括软件所在的系统结构、可能的系统危险、与软件相关的危险原因及危险控制、软件功能结构、软件外部接口；

(3)参考软件失效模式分类、依据软件相关信息及类似软件的失效信息，针对每个软件安全性需求，分析其可能的失效，获取危险软件失效列表；

(4)针对每个危险软件失效，分析危险软件失效原因及改进措施。