ICS 35.080 L 77 GB 中华人民共和国国家标准 GB/T 30998--2014 信息技术 软件安全保障规范 Information technology--Software safety assurance specification 2014-09-03发布 2015-02-01实施 中华人民共和国国家质量监督检验检疫总局 发布 中国国家标准化管理委员会 GB/T 30998--2014 目 次 前言 范围 2 规范性引用文件 3 术语、定义和缩略语 3.1术语和定义 3.2缩略语 安全关键软件的确定 4.1. 确定过程 4.2软件安全分析 5软件安全保障-般分析 5.1 人员、组织及职责 5.2 软件安全计划 5.3 人员认证及培训 5.4 资源 10 5.5 软件生存周期 10 5.6 文档要求 11 5.7 可追踪性 11 5.8 差异和问题的报告、追踪 12 5.9 软件配置管理活动 12 5.10 软件保障活动 12 5.11 工具支持及批准 13 5.12 现货软件 13 5.13 外包管理 13 5.14 认证过程 5.15 偏离及豁免 5.16 安全保密性 14 软件开发的安全保障分析· 6.1. 概述· 14 6.2 软件安全需求分析 6.3 软件设计的安全保障分析 6.4软件实现的安全保障分析 6.5软件测试的安全保障分析 软件运行使用的安全保障分析· 18 参考文南献 GB/T 30998-2014 前言 本标准按照GB/T1.1-2009给出的规则起草。 本标准由全国信息技术标准化技术委员会（SAC/TC28)提出归口。 本标准起草单位：中国电子技术标准化研究院、复且大学、总装备部武器装备论证研究中心、北京东 方通科技股份有限公司、上海计算机软件技术开发中心、万达信息股份有限公司、装备学院、 本标准的主要起草人：王卫国、李海波、丛培勇、冯惠、陈志峰、杨丽蕴、李春青、张鲁峰、钱乐秋、李光亚、 龚波。 GB/T 30998-2014 信息技术软件安全保障规范 1 范围 本标准规定了获取或开发安全关键软件所必需的软件安全活动、数据和文档。 本标准适用于定制、重用和现货的安全关键软件的开发和获取过程，也适用于固件。 2规范性引用文件 下列文件对本文件的应用是必不可少的凡是注日期的引用文件，仅注甘期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 11457. 信息技术软件工程术语 术语、定义和缩略语 3.1术语和定义 GB/T 11457 中界定的以及下列术语和定义适用于本文件。 3.1.1 事故accident 造成人员伤亡，职业疾病，设备，财产损坏或损失，环境破坏等的一个或一系列非预期事件 3.1.2 组件component 个系统或子系统的组成元素。 3.1.3 客户customer 获取其他组织所开发的软件的实体，包括工程、项目，设施。 3.1.4 分解decomposition 将个系统或组件划分为组成部分的过程。 3.1.5 失效模式与影响的分析failure modes and effects analysis 种自底向上系统的、归纳的、有条理的分析，用于在指定的级别上标识并记录所有可识别的失效 模式并详迷失效模式的后果。 3.1.6 故障树分析 fault tree analysis 种故障分析技术，用来识别非期望的系统状态，在系统环境和运行的上下文中对其进行分析以找 到所有非期望事件可能出现的可信途经。 3.1.7 故障检测fault detection 发现故障的能力，判断故障已经发生的过程。 GB/T 30998--2014 3.1.8 故障隔离fault isolation 确定故障位置或源头的过程。 3.1.9 故障恢复fanlt recovery 不必经过长时间的重配置，系统就可以克服故障的过程。 3.1.10 功能需求functional requirements 功能需求定义了系统或子系统为完成它的任务应做什么，以及时间及性能需求。 3.1.11 危害hazard 可能导致或引发灾祸或意外事故的现存或潜在的情况， 3.1.12 危害控制hazard control 减少因危害发生而导致的风险的手段，包括用于减小危害后果发生的可能性，降低危害严重程度的 设计或运行特性。 3.1.13 危害缓解hazard mitigation 减少或消除由危害导致的风险的任何措施。 3.1.14 协定备忘录 memorandum of agreement 双方或多方之间的书面协定，它定义了与某一特定方案或项自协同工作有关各方的角色和责任。 注,MOA 有时也称为谅解备忘录(MOU)。 3.1.15 任务关键mission critical 任务的项或功能应保持运行能力以确保任务不会失效。 3.1.16 现货软件off-the-shelf software 在系统中原样使用的已存在的软件，其中包括： 1）商业现货软件（COTS)是指经购买获得的软件，例如操作系统、库或应用程序； 2）可修改现货软件（MOTS)典型的是指源代码可修改的COTS产品。 3.1.17. 划分 partitioning 物理上或逻辑上把安全关键功能与其他功能分离。 3.1.18 初步危害分析 preliminary hazard analysis 初始系统概念的粗略研究，用于识别所有构成内在危害的根源，评估在系统运行的各种模式下可能 发生的意外事故。 注，该分析也用于标识预防所有意外事故可能性的保护方法。 3.1.19 项目生存周期project life cycle 项目从其开始到完成及退役的进展过程。项目进展所经历的一组步骤或阶段，包括形成、构思到关 闭并向客户交付，粮据系统如何定义还可能包括运行、维护和退役。 注：运行和维护阶段直到退役可能是一个独立的项目生存周期。 2 GB/T 30998-2014 3.1.20 重用软件reused software 为其他系统创建，并被组合到正在开发的系统中的软件。 3.1.21 风险 risk 如下二者的结合： 1）：方案或项目避遇非期望事件的可能性（定性或定量的） 2）、非期望事件出现时，将造成的后果、影响的严重性。 3.1.22 安全关键safetycritical 直接或间接导致人员伤害、系统损坏，系统外的财产损失或环境破坏的潜在可能性的任何条件、事 件、操作、过程、设备或系统。 3.1.23 安全及任务保障·safetyandmission assurance 在方针、过程以及标准制定，监管和洞察，及安全、可靠性、可维护性及质量等方面的技术开发和转 移方面为客户提供支持。 3.1.24 安全保障safety assurance 确保所识别的软件的需求、设计、实现、验证及运行规程能使潜在的危险最小化或将其排除。 3.1.25 软件获取，softwareacquisition 从其他组织通过文档化的协定获得软件的过程，或指从其他组织获取软件产品的一组活动。 3.1.26 软件保障.softwareassurance 确保软件生存周期过程及产品符合需求、标准和规程要求的一组有计划的活动。 注：道常软件保障包括软件质量（软件质量工程、软件质量保降、软件质量控制等功能）软件安全性、软件可靠性、 软件验证与确认以及独立验证与确认等学科领域。 3.1.27 软件元素：software element 逻辑上分离的软件项的组成部分。 注：软件元素依赖于上下文，可以是需求、软件设计、软件源代码或任何软件实体的二个子集。 3.1.28 软件开发生存周期：software development life cycle 分析、定义、开发、测试以及交付一个软件产品所必需的所有活动。 注：当软件可以运行并且对于客户的使用或运行已被正式验收时，该开发生存周期结束。一且进人可运行状态，任 何变更及升级都被视为小规模的软件开发生存周期： 3.1.29 软件危害：softwarehazard 由软件对可能有危害的硬件的错误控制面造成的危害。这种软件可能是功能正确的（根据其需 求）也可能处于失效模式之中。 3.1.30 软件补丁software patch 无需对源程序重装配或重编译，直接对目标程序所做的修改。 GB/T 30998-2014 3.1.31 软件安全softwaresafety 软件工程与软件保障的个方面，它提供一种系统的方法来标识、分析和追踪对危害以及具有危害 性的功能（例如数据和命令）的软件缓解措施与控制。 3.1.32 软件安全分析softwaresafetyanalysis 应用手整个软件生存周期的系统安全工程技术，以确保可能降低系统安全的错误已被消除或控制 在可接受的风险水平上。 3.1.33 软件安全变更分析 software safety change analysis 评价所提议的变更引起危害性状态、影响危害控制、增加危害状态的可能性、对安全关键软件造成 负面影响或改变一个已存在的软件组件的安全关键特性。该活动明确对于假设规格说明、需求、设计 代码、设备、测试计划、环境、用户文档以及培训材料的变更所带来的影响。 3.1.34 软件安全计划 software safety plan 作为系统安全方案一部分，详细记录软件安全相关活动、进度安排、联系渠道和责任的文档。 注，该文档不一定要作为独立的文档存在，可以作为系统安全计划的一部分，或对于小项目而言，可以作为总体保 障计划的一部分。无论编制者是谁，都需相关人员签署批准。 3.1