软件成为越来越多的系统中的一个至关重要的部分，它控制硬件并提供任务关键的数据，软件应是安全的。故而，自上世纪80年代以来，以美国国防部为代表的软件采办方率先启动了将软件安全性集成到系统安全性工作（SSP）中，提出了软件安全性任务（300系列任务）扩展集，并纳入美军标MIL-STD-882B《系统安全性工作要求》；1997年，在航天工程等推动下我国制定并发布了GJB/Z 102-1997《军用软件可靠性和安全性设计准则》。
自GJB/Z 102-1997发布以来，软件可靠性和安全性工作越来越受到重视，例如，航天载人工程、航空航天多个型号等均以GJB/Z 102-1997为基础，制定并实施了适用于本工程项目的软件可靠性和安全性设计指南，为保证工程项目和型号的可靠性和安全性发挥了重要的作用。
GJB/Z 102-1997广泛应用于武器装备软件的设计过程中，并取得了良好的效果。但由于GJB/Z 102-1997的制定时间较早，限于当时技术水平及军用软件开发单位的能力，有些要求（如有关软件开发方面的要求）变得不能适应当前的形势，有些原来认为不可行的方法和技术（如SFMEA和SFTA等）已经在武器装备软件开发过程中得到了应用；另外，在军用软件开发过程中，人们也积累了许多良好的实践，并从失败和挫折中总结了许多宝贵的经验和教训；十多年来，国外在软件可靠性和安全性设计研究与实践方面陆续取得了一些新的成果，例如，美国航空航天局（NASA）在2004年发布了NASA-STD-8719.13B《软件安全性标准》、美国军方发布了《软件系统安全性手册》等等。在这种情况下，为了使GJB/Z 102-1997更加符合我国军用软件开发的实际，迫切需要对GJB/Z 102-1997进行修订，删除或修改与当前实际情况不符的有关要求和准则，增加国内外的最佳实践和经验教训，以便更好地指导军用软件的开发，提高武器装备的可靠性和安全性。
GJB/Z 102-1997修订主要是在总结GJB/Z102-1997实施经验基础上，结合国内外软件可靠性和安全性的研究和实践现状，补充国内外相关研究成果和优秀实践，如，NASA-STD-8719.13B《软件安全性标准》、NASA-STD-8719.13－2004《NASA 软件安全性指南》、美国军方发布的《软件系统安全性手册》、 HSE OP-871《在安全性有关应用中的可编程电子系统：通用技术指南》、DO 178B、以及我国航天员安全性设计工作指南等中的一些内容，提出适用于我国军用软件的安全性设计要求和准则，补充、细化和修订原有设计要求和准则（如“4 一般要求”中有关软件开发规范化的要求等）。修订后的标准将主要涉及软件需求分析、软件设计和软件实现三个方面的安全性设计要求、方法和准则，力求与GJB 900A-2012《装备安全性工作通用要求》保持协调。
GJB/Z 102修订时指导原则如下：
a) 先进性：尽量采用当前先进有效的软件可靠性和安全性设计实践，尤其要考虑NASA、欧空局、美军有关软件可靠性和安全性方面的标准、指南和手册。
b) 有效性：规定的要求和准则应有助于提高或者保证软件的安全性。
c) 可操作性：规定的要求经国内或国外工程实践证实具有可操性。
d) 可行性：基于我国军用软件研制单位当前技术水平，规定的要求和准则应能够做到，或者通过努力能够在近几年内做到。
e) 协调性：GJB/Z 102修订主要是根据国内外软件可靠性和安全性的研究和实践现状，结合军用软件的特点进行的，是GJB 900A-2012支撑标准，标准框架和技术内容保持与GJB 900A-2012协调一致。
表1 GJB/Z 102A的结构
与GJB/Z102-1997相比，本次修订主要有如下变化：
名称改为《军用软件安全性设计指南》；
增加了软件安全性工作通用要求、外购（协）或重用软件的要求、工具的验证要求；
增加了中断设计、通讯设计、自检查设计、异常保护设计、指针使用等方面内容；
对接口设计、简化设计、余量设计、防错设计、多余物处理、编码原则等方面内容进行了修改和完善；
删除了GJB/Z 102的附录A和附录C，增加了附录B～附录F，GJB/Z102的附录B纳入了GJB/Z102A的附录A。
a）软件安全性工作是其所属系统安全性工作的重要组成部分，由系统提出要求，依据系统要求进行检查和验证，具体要求见GJB 900。
b）软件安全性工作贯穿于软件生存周期全过程,应与软件工程过程活动紧密结合地进行。安全关键软件的开发应按照GJB 2786A-2009的要求进行，同时进行软件安全性策划，开展软件安全性工程活动。软件开发人员应参与软件安全性需求的拟定，并负责实施软件项目策划规定的有关活动，确保所开发的软件产品满足系统的安全性需求。
c）确定计算机软件配置项（CSCI）的安全性等级。在系统分析和设计阶段，系统人员根据系统危险分析结果，确定软件的安全性等级，软件开发人员应参与并提出建议。确定软件安全性等级的方法参见附录A。软件开发人员应依据软件安全性等级确定软件安全性工作的具体范围。
a）决定重用某软件来完成安全关键功能之前，应确定其适用性，并充分分析其安全性影响。在软件开发过程中，应对重用软件产品进行安全性分析和评价工作，并对其进行验证，确保其不存在不可接受的安全性风险。
b）外购（协）软件应按照GJB 5000A-2008中供方协议管理过程域的要求进行管理，并进行安全性分析和评价。
在软件生存周期过程中，通常要使用很多工具，诸如编辑程序、编译程序、调试程序和集成开发环境之类的工具，以及项目管理和配置管理等方面的工具。 为避免工具对安全关键软件的影响，GJB/Z 102A对安全关键软件开发过程中使用的影响可执行代码的软件工具提出了基本要求：
b）依据软件工具使用说明，验证开发过程中所使用软件工具功能和性能的正确性、一致性和完整性。
b) 通用的安全性需求：是某一应用领域或多个类似的项目常常有一些共同的安全需求。
系统特定的软件安全性需求的开发与分析应依据系统安全性需求、环境需求、标准、项目专用规范、工具或者设施需求、接口需求、系统危险报告和系统危险分析报告，查找安全关键功能，确定安全性需求，并应根据危险发生的可能性和严重性等对需求的安全关键性进行排序。在软件需求规格说明中，应明确标识出软件安全关键功能。对于比较复杂的软件需要采用专门分析方法找出安全关键功能，常用的有基于软件功能的故障树分析（FTA）方法和软件失效模式、影响及危害分析（FMECA）方法。
g) 可测试性。
f) 禁止程序正常执行时直接从过程中跳出等等。
1）导致或者造成某个危险；
2）为危险提供控制或者缓解；
3）控制安全性关键功能；
4）处理安全性关键的命令或者数据；
5）检测并报告系统是否进入某个特定的危险状态，或者在系统进入某个特定的危险状态时采取纠正措施；
6）在出现危险时缓解其损害；
7）与其它安全性关键软件一起驻留在同一个系统（处理器）之中。
1）采用初步危险分析的方法，确定系统潜在危险；
2）分析确定危险的严重性和可能性；
3）确定系统风险指标；
4）确定软件在系统中执行的控制类别；
5）最后确定软件安全性等级。
