如何根据GJB 102A开展软件安全性分析 —— 上篇
逐步普及
目前，国内军用领域软件大多要求按照GJB 102A标准开展软件安全性分析。在不同领域或型号中，叫法略有不同：比如较早开展的航空航天型号叫做“软件失效风险分析”，后来的型号更多叫做“软件安全性分析”以及“软件可靠性分析”，还存在少数不太规范的叫法如“软件失效性分析”等等，在民用航空等功能安全领域，则称之为“软件健壮性分析”。
不论叫法如何，这些要求背后的含义都是相同的，就是通过失效分析等手段，获取让软件更可靠更安全的需求，即尽力预防 “软件功能设计错误→系统失效→不安全的系统运行结果”这个事件链，也可以称之为“软件功能安全”。
要求清晰
为了让我们的软件更加安全可靠，型号研制主管和总体可谓是煞费苦心，近些年制定了一系列非常详细的要求，细化到了操作指南级别，比如某航空型号的软件安全性分析操作指南，已经细化到了步骤级，甚至每一步如何填写表格都做出了指导，这种级别的指南在功能安全性发展史上都是少见的。
为了确保软件设计中落实了上述要求，还开展了一系列经过周密部署的工程验证，不仅组织同行专家进行评审，还给评审专家制定分发了详细的评审检查单，在某型号的软件失效风险分析评审中，专家手持具有80多个检查项目的辅助检查单进行评审，使评审过程具备足够客观的标准和量化的手段。
理解标准、平衡利弊
这样严格细化的手段，作为一个专业发展的初期是非常必要的，它会促使形式上的统一和内容上的及格；另一方面弊端也是存在的，作为一个以逆向思维作为发散性分析的专业，过于严格的规程有些时候反而会容易使人陷入被动的满足从而降低主观能动性的调动。无论如何，在这个专业目前国内所处的发展阶段看，细化严格的手段还是利大于弊。随着对这个专业的不断理解，势必会逐渐过渡到对标准的严格性和灵活性之间的平衡。
在这个平衡中，天平的一端是用户的严格要求，天平的另一端就是对专业技术和标准的深入把握。如果技术标准都不知道如何去操作，甚至都没有通读过一遍，那么如何有信心做到灵活应用呢？所以，准确理解技术标准GJB 102A是目前需要做的重要工作。
GJB 102A《军用软件安全性设计指南》是GJB 102《软件可靠性和安全性设计准则》的替代标准，最明显的变化是在名称上将“软件可靠性、软件安全性”统一为“软件安全性”。
对于软件来说，可靠性与安全性虽然概念上有所区别，但关于开展的生命周期工作，软件可靠性与安全性区别甚微。特别在设计阶段，软件可靠性与安全性分析设计涉及的工作内容几乎一样，因此使用“大安全性”来统筹“可靠性”与“安全性”术语。
这一变化也符合国外民用航空、轨道核电、汽车电子等功能安全领域趋势，即在“安全性”或者“功能安全”的大目标下，开展软件可靠性、安全性、可信性、健壮性等通用质量特性工作。关于软件可靠性与安全性关系，可以参考：软件安全性与可靠性本是“一回事儿”。
GJB 102A增加了软件需求、软件设计和软件实现三个阶段的安全性要求，也体现“软件安全性”应该与软件研制过程相结合的特点。
GJB 142《军用软件安全性分析指南》发布于2004年，比较忠实于国外标准原文，我们可以从这个标准看到IEC-61508和NASA-8719的影子。该标准体现了系统-软件自顶向下、软件-系统自底相上的双向安全性闭环过程。
GJB 102A相较于GJB 142，更强调软件-系统自底相上的安全性分析设计过程，对于这部分，GJB 102A的篇幅和要求比GJB 142更细致。
开展系统与软件完整的双向安全性工作是正确的目标，但现阶段更适合我们工程基础的，可能还是以自底向上为主的软件安全性要求（软件好改嘛），再传递给系统。因此，依据GJB 102A进行软件安全性工作，是现阶段更为现实的方式。但是我们必须认识到，经过一个阶段的发展，最终还会走上类似GJB 142这种双向分析之路。
GJB 1391《故障模式、影响及危害性分析指南》的最大优点是给出了详实的软件FMEA实施方法，包括过程、表格、参考失效模式数据等非常具体的指导。但标准发布于2006年，对于日益复杂的软件，标准中推荐的软件失效模式数据有很大完善空间，并且与之后发布的软件文档、开发过程等标准的结合性也需要在实施中考虑。
当按照GJB 102A开展软件FMEA分析时，参考GJB 1391仍然是一个直接和有效的途径。
GJB 900A《装备安全性工作通用要求》规定装备生命周期开展的系统安全性工作，是对装备安全性计划、管理、组织、使用的纲领性要求。
软件安全性要求是GJB 900A中的一个章节，可以认为通过GJB 102A的指导，能够达到GJB 900A中关于软件的安全性要求，两者有接口关系。
国外常用的。与软件安全性可靠性有关的系统/软件标准有：
航空领域的SAE ARP 4761《民用航空机载系统和设备安全性评估过程和方法指南》、DO-178C《机载系统和设备合格审定中的软件考虑》；
航天领域的NASA 8719《软件安全性标准与指南》；
军用领域的MIL-STD-882《系统安全性实践标准》、MOD-DEF-STD 00-55 《军用设备软件安全性要求》、美国国防部《三军联合软件系统安全性工程手册》；
工业领域的IEC 61508《电气/电子/可编程电子安全系统的功能安全》；
轨道交通、道路车辆、核电等领域的EN 50128、ISO 26262、IEC 61513、IEEE STD 603等等。
SAE ARP 4761 + DO-178C是民航客机适航审定依据性标准，典型应用如波音B777/787、空客A 330/340/380等机型。标准规定了机载系统-软件、软件-系统的安全性闭环：
SAE ARP 4761给出整机/系统级安全性目标、软硬件组成项安全性目标、以及之间的接口和追溯关系。其中功能危险评估FHA（可参考：系统向软件分配安全性需求方法——FHA）、功能导向的初步系统安全性评估PSSA（可参考：系统体系结构的安全性分析——PSSA与FTA）、实现导向的系统安全性评估SSA（可参考：系统体系结构的安全性分析——IDAL与软件安全性需求）是三个最为核心的部分。为实现系统安全性评估SSA中与软件相关的安全性目标，软件研制过程按照DO-178C标准。
DO-178C中，软件安全性要求与其他功能要求同等地位，都是软件研制过程应当满足的目标。为了满足这些目标，DO-178C提出软件生命周期的V&V（确认&验证，可参考：适航功能安全中的软件V&V），在软件需求阶段确认安全性与功能要求（可参考：软件的FMEA的概念与作用），在软件设计实现等阶段实现这些要求；再由软件实现一步步逐层向软件需求验证，证明软件实现了安全性与功能目标。
NASA 8719-13B是美国宇航局发布的软件安全性系列标准，主要应用于美国航天工程。NASA 8719-13B阐述软件安全性分析与评估的过程和方法，并给出丰富的指导检查条目。
MIL-STD-882是美国国防部发布的系统安全性标准，典型应用包括美军天基导弹警告系统研制，美国洛马公司F-35综合航电软件研制等。其主要安全性目标与SAE ARP 4761基本一致。
IEC 61508是由IEC（国际电工委员会）发布的一项工业领域国际标准，针对由电气/电子/可编程电子部件构成系统的全生命周期，给出安全性分析与评价方法。该标准分为7个部分，涉及1000余项规范和要求。作为一项基础的通用标准，IEC 61508在多个技术领域衍生出一系列标准，包括EN 50126/50128/50129（轨道交通）、ISO 26262（道路车辆）、IEC 61513（核电）、IEC 61511（过程工业）、IEC 62061（机械）、IEC 60601（医疗）等。
国外标准强调系统-软件生命周期的安全性证据体系，其系统性、规模和追溯性非常值得学习。而对于“系统-软件安全性”其中的“软件安全性”部分，GJB 102A主体思想与国外标准基本一致，在具体软件工程实施时，更适合国内型号软件研制现状，可以作为软件安全性工作的依据。
要想好好贯彻一个技术标准，首先要客观分析和看待标准自身的不足，否则一味照本宣科只会机械地形成“两张皮”，这才是最不可取的方式。
GJB 102A发布于2012年，按照我国研制国军标的规律，该标准实际的科研阶段应该在2010年左右。而此时，GJB 438B也刚刚发布，在工程型号中宣传贯彻软件工程化要求的行动也才刚刚开始。
这就会造成一个客观现象，那就是GJB 102A中对于软件开发阶段的内容描述未必符合我们今天的理解和习惯，毕竟现在我们是在与GJB 438B折腾了十年左右才逐步形成了对软件需求、设计、实现等概念的正确认识。
标准之间的不同步，研究领域关联性兼顾的不够，都会造成标准本身存在一些问题或不足。主要体现在以下几点。
GJB 102A名称是《军用软件安全性设计指南》，标题中的“设计”二字，容易使我们误解，这是给软件生命周期中的“设计阶段”使用的。所以每当谈到参考GJB 102A进行软件安全性需求分析的时候，总有人会疑惑搞错了标准。
此处的设计，并非指的是“设计阶段”的设计，而是设计人员进行的“脑力设计”活动。这个设计活动，在软件的“需求”、“设计”、“实现”3个阶段都有所实施（其实在验证阶段也应有“验证设计”活动，但本标准并未提及），可以理解为“需求阶段的安全性设计”“设计阶段的安全性设计”和“实现阶段的安全性设计”。在同一个标准中，此设计非彼设计，这是首先需要注意的一个困扰。
GJB 102A把安全性设计分为3个阶段考虑：需求阶段、设计阶段和实现阶段。但由于标准研究时期较早，各个阶段的设计考虑未必完全合适，比如，需求阶段的某些安全性设计考虑放在设计阶段更合适；而设计阶段的某些安全性考虑放在需求阶段更合适。
例如：
在软件需求分析阶段，安全性详细要求的5.2.2.7中的d）条款“内存的使用与可用性”，要求考虑未释放所分配的内存、重复释放内存、缓存溢出等异常情况。这应属于详细设计级别的防错设计考虑，放在需求阶段是不合适的。
例如：
5.3.2中的h）条款“机械限位控制”，对具有机械安全限位要求的硬件设备，软件应该对输入给硬件的控制数据进行极限限位和容错处理，比如火炮的射击限位和传感器天线转动的限位控制处理等，以避免不当的输入信息造成系统安全问题或设备故障。这又是典型应该在软件需求阶段，进行考虑并与系统需求进行迭代的安全性分析；类似的还有5.3.4.3人机界面设计，5.3.5通讯设计等。
但总体来说，某些安全性条款位置的不适宜，并不会对标准的使用造成太大影响，只要理解其本质，做到活学活用即可，毕竟这些条款本身都是对失效防护非常有益的措施。
我们需要认识到，任何标准都是不断演化和发展的，标准本身的不足并不成为不能正确应用其长处的理由。相反，正是在对标准的不断理解、应用、质疑和修订的迭代中，才有可能发展出好的标准。事实上，国外一切的好标准也都是经过这样的过程迭代而成的。
实现阶段与现有编码及测试实践融合
5.4.2软件编码中的条款，在编码标准得到不断普及的今天，实际通过贯彻编码标准即可覆盖，此处建议可以直接参考GJB 8114、MISRA-C等标准。
5.4.3代码验证中，对于代码验证的具体指南也有不少改进余地。例如5.4.3.7代码审查本身就是软件测试的一个规定动作；5.4.3.8中对定时、吞吐量和规模的测试要求，又引发了为什么其他方面没有提出测试要求等疑惑？
随着软件研制能力成熟度的不断提升，软件编码手段的不断进步，编码将越来越多的承担起“按照设计来实现需求”这一单一职责，由软件编码造成的安全性问题将越来越少。因此，实现阶段的安全性考虑，建议应该与现有的编码规范、规则检查、静态分析、人工审查、动态测试等实践过程结合，重点放在代码“一致性”地实现需求与设计的验证上，即可以适合的成本满足标准的要求。
重点放在需求
安全性作为系统的外部属性，需求是最重要的，一旦安全性需求明确，设计和实现的功能就是无偏差的实现需求。当然设计和实现的偏差也有可能由于异常情况识别和防护不周造成，从而引发了设计和实现的“安全性”问题。
软件研制采用的技术和实现手段日趋复杂，软件需求和设计，特别是需求造成的安全性问题越来越多，因此对于安全性考虑应该聚焦在需求和设计阶段（可参考：软件安全性需求分析）。目前型号上的做法，也是普遍要求开展需求阶段的安全性分析，获取安全性需求。
近年来国内外一系列安全性的案例也表明，系统和软件需求阶段分析识别遗漏造成的后果更容易导向安全性事故，例如夏帕瑞丽卫星坠毁事故，以及耳熟能详的波音737 MAX坠毁事故（可参考：狮航737MAX事故给我国软件验证的启示），都是典型的缺少安全性需求造成的。这种情况下，无论设计和实现规避了多少异常，都无法避免安全性需求遗漏造成的事故发生诱因。
体系结构设计应考虑的
虽然重点放在需求上，但设计特别是体系结构设计中，仍然有不少安全性考虑，值得我们注意。
例如5.3.4.2软件模块间接口设计
很多软件研发过程缺少规范的体系结构设计，特别体现在模块间接口设计的随意性，这在单元集成测试中体现的尤为明显，随意的接口设计会使调用测试、控制耦合测试和数据耦合测试都变得难以评估，但到了单元集成测试阶段才发现显然为时已晚；
5.3.7中断设计
如果不在设计中断时尽可能考虑并实施这些准则，那么只能在后期依靠更加复杂的高成本手段去识别中断随意使用带来的苦果；
等等。
上 篇
1、GJB 102A的型号应用现状
2、GJB 102A与其他标准的关系
3、GJB 102A的不足
4、GJB 102A的使用建议
下 篇
5、GJB 102A应用的详细分析
第一步，分析软件特点，确定适用条款
第二步，根据适用条款，形成细化指南
第三步，根据细化指南，形成分析准则
第四步，根据分析准则，选取失效模式
第五步，根据失效模式，评估影响后果
第六步，根据影响后果，形成安全需求
6、证明自己的软件符合GJB 102A
第七步，过程举证，结果举证，列出举证矩阵
第八步，根据举证矩阵，回溯标准条款，得到安全结论
- 用户评论