2025软件安全保障规范

信息技术软件安全保障规范 前 范 规范性引用文 术语和定 缩略 安全关键软件的确 确定过 软件安全分 软件安全保障一般分 软件安全计 人员认证及培 软件生存周 文档要 软件配置管理活 工具支持及批 现货软 外包管 偏离及豁 安全保密 概 软件安全需求分 软件设计的安全保障分 软件实现的安全保障分 软件测试的安全保障分 信息技术GB/T 信息技术GB/T11457故障隔离功能需求定义了系统或子系统为完成它的任务应做什么，以及时间及性能需求。可能导致或引发灾祸或意外事故的现存或潜在的情况。减少因危害发生而导致的风险的手段，包括用于减小危害后果发生的可能性、降低危害严重程度的设计或运行特性。减少或消除由危害导致的风险的任何措施。双方或多方之间的书面协定，它定义了与某一特定方案或项MOA有时也称为谅解备忘商业现货软件(COTS)是指经购买获得的软件，例如操作系统、库或应用程序；可修改现货软件(MOTS)典型的是指源代码可修改的COTS产品。物理上或逻辑上把安全关键功能与其他功能分离。，评估在系统运行的各种模式下可能发生的意外事故。组步骤或阶段，包括形成、构思到关闭并向客户交付，根据系统方案或项目遭遇非期望事件的可能性(定性或定量的)；维护性及质量等方面的技术开发和转移方面为客户提供支持。从其他组织通过文档化的协定获得软件的过程，或指从其他确保软件生存周期过程及产品符合需求、标准和规程要求的一组有计划的活动。逻辑上分离的软件项的组成部分。由软件对可能有危害的硬件的错误控制而造成的危害。这种软件可能是功能正确的(根据其需求),也可能处于失效模式之中。软件工程与软件保障的一个方面，它提供一种系统的方法来的软件缓解措施与控制。应用于整个软件生存周期的系统安全工程技术，以确保可能降低系统安全的错误已被消除或控制在可接受的风险水平上。对于已发现的危害源，标识并评价已有和潜在的危害以及所推荐的危害缓解方法，包括对安全功能和危害控制的验证和确认一个提供追踪能力的系统，能够在前向和后向两个方向上提供从需求的最初构思、后续细化到产品实现以及与产品相关文档的追踪能力。动作或操作。一个已记录在案的偏差，此偏差允许违背一个特定的安全需求，该需求已使用替代的方法来降低风险或者管理层已经接受了风险级别的增高。下列缩略语适用于本文件。 ComputerAidedSoftware 关键设计评审(CriticalDesignReview) 商业现货(CommercialOff-the-Shelf) 故障检测、隔离与恢复(FaultDetection,Isolationand 失效模式与影响分析(FailureModesandEffects 协定备忘录(MemorandumofAgreement) 可修改现货(ModifiedOff-the-Shelf) 谅解备忘录(MemorandumofUnderstanding) 软件和任务保障(SoftwareandMissionAssurance) 软件安全保障工程师(SoftwareSafetyAssurance 测试就绪评审(TestReadiness对危害提供控制或缓解；控制安全关键功能；处理安全关键命令或数据(见注1)；如果系统到达某一特定的危害状态，则检测并报告，或采取纠正动作；当危害出现时减少损害；与安全关键软件驻留在同一系统(处理器)上[见注直接导致安全决策的处理数据或分析趋势；提供安全关键系统(包括硬件或软件子系统)的全部或部分验证或确认。软件评价应在概念阶段进行，在为所有新项目中指定软件的获取或计划之前进行；评价结果应记录在适当的文件中；安全及任务保障组织应对评价结论进行审批。本标准的要求应适用于所有安全关键的软件元素，无论是否存在非软件的危害控制或缓解手段(例如操作员的干预、硬件补偿)。软件安全分析在标识项目特定的软件安全需求时首先要进行系统危害分析。系统危害分析将由软件安全人员进行评审以概要评估其中软件的潜在角色，然后，随着系统开发的完善成熟，保证系统级的变化能够根据需要加入到软件中。该软件安全分析反过来为系统安全活动提供输入，是整个系统的危害分析的一部分，并不是孤立进行的。系统和软件安全分析在系统生存期内随着系统定义不断完善以及变化的不断发生而迭代地进行。有效的系统安全分析工作需要所有团队成员(包括项目管理人员、系统安全人员、软件保障人员、软件开发人员、软件安全人员以及安全及任务保障组织)在项目生存周期内持续进行信息交流。初步危害分析标识潜在的系统危害，并可能进一步确定哪些子系统会被用于控制这些危害。该软件安全分析和活动，以及它们与系统的安全方案的交互作用，需要在项目生存周期的早期进行计划。软件安全分析的入口和出口准则宜是这个计划和协调工作的一部分。系统安全分析软件安全人员应参与如下的系统安全分析，包括初步危害分析(通常在概念阶段进行)：对已标识的与特定需求、设计概念和运行关联的危害，应评价在危害原因、控制或缓解中软件所起的作用；软件安全分析应与整个系统的安全分析结合起来进行。系统安全分析为软件安全分析提供输入，而软件分析的结果也会反馈给系统安全方案以用于更新并精化其分析结果。这些分析及反馈环路将在整个系统生存周期中随着更多细节(包括软件安全特性的设计和验证)的出现而持续进行系统安全分析，包括初步危害分析、系统危害分析以及软件缓解或分解任何软件危害，在那里软件是导致这些危害的潜在原因，或者对危害有促进作用，或者使软件能够被用作危害控制。已确定的软件安全需求以及软件危害的原因、促成因素和控制手段应记录在适当的文档中，并在安全计划中引用。这些需求通常都作为软件需求规格说明的一个章节进行文档化。而安全计划可以作为系统安全计划、软件管理和开发计划、软件或系统软件安全保障涉及软件开发的所有人员和组织。人员主要包括项目管理人员、硬件和软件设计人员、安全分析人员、质量保证人员以及软件运行管理人员。组织主要是安全及任务保障组织。开展软件安全活动的人员还会与来自诸如可靠性、安全保密性、独立验证与确认以及环境要素等其他领域的人员进行协调。开发安全系统及其软件元素的责任由项目经理与安全及任务保障组织共同承担。项目管理人员负责对系统中是否存在安全关键软件进行评价，负责实施软件安全方案，为方案提供足够的资源，并承担软件安全活动不够充分的风险。应将软件安全作为项目中所采用的连续风险管理过程中的一部分。项目管理人员应负责项目内的软项目管理人员应与软件安全人员就安全关键软件的获取以及对本标准的适用程度进行协商；项目管理人员应确保在所获取或开发系统中，实现安全关键功能的软件使用进行定期评价；项目管理人员应为软件安全方案提供足够的资源，包括受过培训的软件安全人员、时间安排、工具、预算；项目管理人员应安排人员(例如软件安全管理员)负责项目软件安全方案；项目管理人员应与软件安全及任务保障管理人员共同工作，为解决与软件安全需求或过程相关的冲突提供手段。项目管理人员应确保软件安全方案在整个软件生存周期中都得到规划和执行；项目管理人员应确保软件安全作为整个系统安全和软件开发工作的有机组成部分；根据组织需求和项目规模设立安全及任务保障或软件安全人员。无论是来自SMA还是在某个项目中工作，软件安全人员都担负着分析并实施系统和软件所需要的软件安全活动的责任。软件安全人员和SMA中的系统安全机构的人员协同工作，制订并标识软件安全需求，将那些安全需求分派给项目管理和软软件安全管理人员应遵循已批准的方法，提升那些不能在该项目中决定的软件安全关注点；任何审批可能影响安全关键系统的软件修改的变更控制小组应包含软件安全管理人员(或受指派的人员)作为成员；概要设计评审(PDRCDR)、设计认证评审(DCR)、测试SMA的职责。如果一个项目中的系统是不安全的，安全机构有责确保对组织内所有项目中是否包含安全关键软件进行定期评价，在各组织内对这些评价及其结果进行记录，在需要收集并维护组织内所有安全关键软件的列表。安全关键系统及软件列表在需要时将发送给组织有关部门，以帮助调整为解决或向上报告与软件安全需求或过程相关的冲突或关注点提供手段；建立一个安全关键软件认证的过程[见开发、验证、认证及维护安全关键软件所需要的安全关键过程及产品被适当地包含进来。从系统概念及获取开始一直到系统退役，利用软件专家以确保软件安全计划与执行的适当平衡；确保软件安全人员对将要集成到安全关键系统中的现货软件或先前创建(重用)软件的选择进目管理提供报告；确保如果一个项目需要独立验证与确认，那么项目风险及软件危险程度的确