GB∕T22081-2024《网络安全技术-信息安全控制》之84：“8技术控制-8.26应用程序安全要求”专业深度解读和应用指导材料（2025A0）

GB/T22081-2024《网络安全技术——信息安全控制》之84:

“8技术控制-8.26应用程序安全要求”专业深度解读和应用指导材料(编制-2025A0)

GB/T22081-2024《网络安全技术——信息安全控制》

8技术控制

8.26应用程序安全要求

8.26.1属性表

应用程序安全要求属性表见表86.

表86;应用程序安全要求属性表

控制类型信息安全属性网络空间安全概念运行能力安全领城

#保密性

#应用安全#防护

#完整性

#预防#防护#系统和网络安全#防御

#可用性

8技术控制-8.26应用程序安全要求-8.26.1属性表

应用程序安全要求见表86。

“表86:应用程序安全要求”属性表解析

属性维度属性值属性涵义解读属性应用说明与实施要点

(1)通用涵义：“控制类型”指从控制何时和如何改变信息安全事件发生风1)适用场量：所有组织在应用程序“开发阶段”(需

险的视角进行分类的属性，其中“预防”类控制是旨在防止信息安全事件发求分析、设计、编码)和“获取阶段”(供应商选型、

生的前瞻性措施。通过提前识别风险、建立规则或部署防护机制，阻断威胁合同评审、验收测试)均需优先部署预防类控制，避

控制类型#预防触发路径，避免事件发生。免安全缺陷嵌入应用程序生命周期早期。

(2)特定涵义：2)实施要点：需将预防控制与应用程序安全需求识别

针对应用程序安全场景，“预防”特指在应用程序开发或获取过程中，通过(如风险评估)绑定，例如在需求阶段明确“防止SQL

提前定义安全要求、嵌入安全设计、实施安全测试等措施，防止因应用程序注入”的预防要求，而非事件发生后补救。

加油努力你行的

属性维度属性值属性涵义解读属性应用说明与实施要点

自身缺陷(如逻辑漏洞、权限管控缺失)或配置不当引发安全事件的控制类3)与其他控制类型协同：虽属性表仅列“预防”,但

型。其覆盖“需求-设计-开发-验收”全流程，核心是“源头控险”。雷与“检测”(如应用漏洞扫描)、“纠正”(如漏

洞修复)控制联动，形成全生命周期防护闭环。

1)保密性实施：

(1)通用涵文。“信息安全属性”指控制有助于保护的信息核心特征，是信-应用程序需对敏感数据(如用户隐私信息、交易数

息安全的基础三元组：据)采用加密存储(如数据库加密)、传输加密(如

一保密性：确保信息不被未经授权的实体访问或披露：TLS1.3),并限制敏感数据访问权限(如基于角色的

完整性；确保信息在创建、传输、存储过程中不被未经授权篡改、破坏访问控制);

或丢失；一避免在日志、错误提示中泄露敏感信息(如不返回

-可用性：确保授权实体在需要时能及时访问和使用信息及相关资产。数据库报错详情):

(2)特定涵义。针对应用程序场景，三者需结合应用程序功能特性针对性落2)完整性实施；

#保密性

信息安全地：一对应用程序输入数据进行验证(如防止XSS、SQL注

#完整性

属性-保密性：重点保护应用程序处理的敏感信息(如电子支付中的银行卡信入的输入过滤),对关键交易数据生成哈希值(如

#可用性

息、政务应用中的个人身份信息),防止因权限漏洞、数据泄露接口导致信SHA-256)进行完整性校验；

息外泄；禁止未经授权的程序代码修改(如代码签名验证):

-完整性：重点保障应用程序代码完整性(防止恶意算改)、数据处理完3)可用性实施；

整性(如交易金额计算无误)、配置完整性(防止安全配置被篡改);-应用程序需具备容错能力(如异常捕获机制)、过

-可用性：重点确保应用程序服务不被拒绝服务攻击(如DDoS)、自身缺载保护(如流量限流),避免因单一故障(如数据库

陷(如死循环)或资源耗尽(如内存泄漏)中断，尤其对交易类、服务类应连接超时)导致服务中断；

用(如电商支付、政务服务)需满足高可用要求。-关键应用需部署冗余机制(如多实例部署),确保

业务连续性。

加油努力你行的

属性维度属性值属性涵义解读属性应用说明与实施要点

1)防护措施分类：

-技术防护：如应用程序部署Web应用防火墙(FAF),

(1)通用涵义：“网络空间安全概念”指控制与网络空间安全框架关联的属启用输入验证模块、配置安全的会话管理(如JVT令牌

性，其中“防护”是网络空间安全“识别-防护-发现-响应-恢复”闭环中的有效期管控);

核心环节，通过部署技术、管理或物理措施，建立安全屏障，抵御已知威胁管理防护；如制定应用程序安全开发规范、供应商

,减少脆弱性被利用的可能性。安全准入标准、安全测试流程；

网络空间(2)特定涵义：针对应用程序场景，“防护”特指通过在应用程序生命周期2)与“识别”环节联动：

#防护

安全概念各阶段嵌入安全控制，建立应用层安全屏障，抵御针对应用程序的典型威胁应用程序防护措施需基于“风险识别”结果(如风险

(如注入攻击、权限越权、恶意代码植入)的措施。既包括“开发端防护”评估识别的“SQL注入风险”)针对性设计，避免无差

(如安全编码培训、静态应用安全测试SAST),也包括“运行竭防护”(如别防护；

动态应用安全测试DAST、实时入侵检测),核心是“主动抵御应用层威胁”3)持续优化：

雷定期结合威胁情报(如新出现的应用漏洞类型)更

新防护措施，如针对“Log4j2漏洞”升级应用程序依

赖组件。

(1)通用涵义。“运行能力”指从从业者信息安全能力视角分类的属性，反1)应用安全能力建设：

映姐织实施控制所需的核心能力；-人员能力；需培养开发人员安全编码能力(如识别

#应用安-应用安全：确保应用程序从设计、开发到运行的全生命周期安全管理能OWASPTop10漏洞)、测试人员安全测试能力(如使

全力，包括安全需求分析、安全设计、安全测试等；用SAST/DMST工具);

运行能力

#系统和一系统和网络安全：确保支撑应用程序运行的系统(如操作系统、数据库)-工具能力：部署应用安全测试工具、代码审计工具，

网络安全和网络(如通信链路、网络边界)安全的管理能力，包括系统加固、网络隔建立安全需求管理平台：

离、流量管控等。流程能力：建立“安全需求-设计评审-编码检查-验

(2)特定涵义。针对应用程序场景，两者是“应用自身安全”与“支撑环境收测试”的应用安全流程，嵌入开发管理体系；

加油努力你行的

属性维度属性值属性涵义解读属性应用说明与实施要点

安全”的协同关系：2)系统和网络安全能力协同：

-应用安全：聚焦应用程序“自身”的安全能力，如通过安全需求定义“-系统层；对应用程序依赖的操作系统进行安全加固

用户身份鉴别强度”(如多因素认证)、通过安全编码避免“缓冲区溢出”(如关闭不必要端口)、数据库(如MySQL、Oracle)

漏洞，是应用程序安全的核心能力：进行权限管控(如最小权限原则);

系统和网络安全；聚焦应用程序“依赖环境”的安全能力，如通过系统-网络层；通过防火墙、网络隔离(如VLAN划分)限

加固防止“操作系统漏洞被利用进而攻击应用程序”、通过网络防护防止“制应用程序通信范围，对应用程序访问链路加密(如

应用程序通信数据被拦截”,是应用程序安全的基础支撑能力，两者缺一不VPN)。

可。

1)防护领域实施：

(1)通用涵义。“安全领域”指从四个信息安全领域视角分类的属性：

-应用程序开发阶段：制定应用安全需求清单(如依

防护：属于“防护领域”,覆盖“IT安全架构、身份和访问管理、物理

据8.26.4指南确定“输入控制”“访问隔离”要求)、

和环境安全”等，核心是“提前建立安全控制，防止安全事件发生”;

开展安全设计评审(如评审权限架构合理性)、实施

-防御：属于“防御领域”,覆盖“检测、计算机安全事件管理”,核心

安全编码培训；

是“及时发现安全事态，快速响应安全事件”。

一应用程序获取阶段：对供应商提供的应用程序进行

(2)特定涵义。针对应用程序场景，两者形成“事前防护-事中防御”的协同

#防护安全评估(如漏洞扫描、渗透测试),在合同中明确

安全领域闭环；

#防御安全要求(如数据保护条款》;

-防护：重点在应用程序“开发/获取阶段”提前植入安全控制，避免安全

2)防御领域实施：

缺陷引入，如通过“雷求定义”明确“交易抗抵赖要求”、通过“安全测试

"发现并修复权限漏洞，核心是“源头防险”;-部署应用程序安全监测工具(如VAF日志分析、异常

访问检测),及时发现“异常登录”“高频错误请求”

-防御：重点在应用程序“运行阶段”监测安全事态、响应安全事件，如

等事态；

通过实时监测发现“应用程序异常数据传输”、通过应急处置修复“零日漏

建立应用程序安全事件响应流程，明确“漏洞发现

洞”,核心是“事中控险”,两者结合实现应用程序全生命周期安全管控。

评估-修复-验证”的响应步骤，如发现SQL.注入漏洞后

加油努力你行的

属性维度属性值属性涵义解读属性应用说明与实施要点

4小时内启动应急修复。

GB/T22081-2024《网络安全技术——信息安全控制》

8.26.2控制

在开发或获取应用程序时，宜识别、规定和批准信息安全要求，

8.26.2控制

(1)“8.26.2控制”解读和应用说明表

“8.26.2(应用程序安全要求)控制”解读和应用说明表

内容维度“B.26.2(应用程序安全要求)控制”解读和应用说明

1)在应用程序开发或采购全生命周期中，以“源头控险”为核心，系统性识别、明确规定并正式批准信息安全要求，确保应用程序在实现业务

功能的同时，满足组织信息安全策略、合规义务(如《中华人民共和国网络安全法》《中华人民共和国个人信息保护法》)及数据保护目标，

对齐GB/T22081-2024第8.26.1属性表中“预防”类控制的核心定位，从应用生命周期早期阻断安全缺陷(如逻辑漏铜、权限管控缺失)嵌入，

本条款核心控

避免后期整改带来的业务中断与成本损耗；

制目标和意图

2)本条款的根本意图是打破“重功能、轻安全”的传统开发/采购模式，通过“识别-规定-批准”三环节形成前置控制闭环，确保安全要求

与应用程序设计、开发、验收同步推进，而非事后补救。这一目标与GB/T22081-2024“技术控制”章节中“主动防护”的整体理念一致，旨在

将安全融入应用全生命周期关键节点，

1)风险前置管控：通过早期识别安全需求，降低应用上线后因漏洞(如SQL.注入、权限越权》引发的数据泄露、服务中断等风险，减少后期漏洞

本条款实施的

修复的时间与经济成本；

核心价值

2)合规符合性保障：确保应用程序安全要求覆盖法律法规、行业标准(如等级保护)及合同约定，满足e中“司法管辖区法律合规要

加油努力你行的

内容维度“8.26.2(应用程序安全要求)控制”解读和应用说明

求”,避免合规处罚；

3)安全质量提升：为应用程序安全测试(如SAST/DAST)、代码审计、渗透测试提供明确依据，提升软件产品安全韧性：

4)与8.26.4指南“风险评估驱动安全要求”的原则深度契合，通过前置管控减少“安全左移”落地阻力，支持组织建立可信应用生态，同时为

供应商选型(获取阶段)提供安全准入标准(8.26.1实施要点)。

“在开发或获取应用程序时，宜识别、规定和批准信息安全要求。”

1)关键场景界定：“在开发或获取应用程序时”明确覆盖两个核心场景——白主开发(需求分析、设计、编码阶段)与外部获取(供应商选型、

合同评审、验收测试阶段),需同步嵌入安全要求，符合8.26.1中“覆盖需求-设计-开发-验收全流程”的预防控制要求；

2)“宜识别”的内涵：

-核心任务：基于风险评估(总则),系统性识别应用程序面临的威胁(如注入攻击、DoS)、处理的信息类型与分缀(b.

如个人身份信息、交易数据)、实体身份信任程度(8.26.4.la,如多因素认证需求》、访问隔离需求(e,如基于角色的权限划分)

及合规要求(如跨境数据传输规则);

-方法支撑：可借助威胁建模(如STRIDE模型)、数据流分析等工具，确保识别无遗漏(8.26.1实施要点):

本条款深度解

3)“规定”的内涵：

读与内涵解析

一核心任务：将识别的安全需求转化为具体、可执行的技术与管理规范，需覆盖数据保护(传输/存储加密，i),输入控制(完整性

检查与验证，j)、错误消息处理(避免泄露敏感信息，p>、交易抗抵赖(n)等内容，同时针对交易服务(

)需补充“身份可信验证、交易完整性校验”,针对电子订购与支付()需补充“订单信息保密、支付信息验证”;

-文档固化：通过《安全需求说明书(SRS)》《安全设计文档》纳入开发/采购流程，确保可追湖：

4)“批准”的内涵：

核心任务：由组织信息安全管理部门、法务部门等有权限的机构，审核安全要求与组织整体安全策略(8.26.1属性表)、风险容忍度的一致

性，确认其充分性(如是否覆盖所有敏感数据保护》与可行性；

流程要求：需形成正式审批记录(如评审会议纪要、签字文件》,批准结果需同步至开发/采购团队及供应商《若获取场景),避免形式化审

加油努力你行的

内容维度“8.26.2(应用程序安全要求)控制”解读和应用说明

批。

1)建立风险评估驱动的识别机制：

一结合总则要求，在应用需求阶段开展专项风险评估，明确戚胁、脆弱性及影响，确保识别的安全要求与风险等级匹配；

-制定《应用安全需求识别清单》,覆盖“实体身份信任、信息分级、访问隔离、数据加密、合规要求”等维度，避免遗漏：

2)规范安全要求的“规定”流程：

一开发场景：将安全要求嵌入《开发任务书》,明确安全编码标准(如避免缓冲区滥出)、安全设计规范(如权限架构),并纳入敏捷开发“

用户故事”或瀑布模型“雷求规格说明书”;

一获取场景：在供应商合同中明确安全要求(如漏洞修复时限、安全测试义务),参考(交易服务)、(电子支付)补充专

项条款；

3)明确“批准”责任与流程；

本条款实施要

-成立跨部门审批小组(信息安全部、业务部、法务部),明确审批权限(如高风险应用需高管审批);

点与组织应用

一建立审批变更机制，若业务/合规要求变更，需重新评审安全要求并记录版本变更：

建议

4)推动安全左移与工具支撑；

-在CI/CD流水线中集成SAST(静态应用安全测试)、DAST(动态应用安全测试)工具，验证安全要求落地情况(8.26.1实施要点);

开展开发人员安全编码培训(如识别0WASPTop10漏洞)、采购人员供应商安全评估培训；

5)建立全生命周期闭环：

一建立安全要求的持续监控机制，与漏洞扫描(检测控制)、漏洞修复(纠正控制)联动，定期(如每季度)评审安全要求有效性：

一针对运行中的应用程序，结合威胁情报(如Log4j2漏洞)更新安全要求，确保与新兴威胁同步；

6)场景化落地：

-交易类应用：重点落实中“身份可信、交易完整性，抗抵赖”要求；

-电子支付类应用：重点落实中“支付信息验证、交易信息保密存储”要求。

加油努力你行的

(2)“8.26.2控制”条款与GB/T22080-2025相关条款的逻辑关联关系；

“B.26.2控制”与GB/T22080相关条款的逻辑关联关系分析表

关联GB/T22080条款逻辑关联关系分析关联性质

在应用程序开发/获取初期，需通过6.1.2定义的风险评估过程(建立风险准则、识别风险、分析风险级别),

6.1.2信息安全风险评估识别应用程序潜在的保密性、完整性、可用性风险(如代码漏洞、数据泄露风险),为后续精准规定安全要求实施基础

提供风险依据。

根据6.1.2的风险评估结果，通过6.1.3的风险处置过程选择适宜的处置选项，而“识别，规定应用程序安全要

6.1.3信息安全风险处置执行依据

求”是风险处置中确定的关键控制措施之一，需验证其与附录A控制的匹配性，并纳入风险处置计划。

需将应用程序安全要求对应的具体目标(如“开发阶段100%识别高危应用安全需求”“获取的第三方应用100%

6.2信息安全目标及其实现

通过安全要求审核”)纳入6.2的信息安全目标体系，并明确实现目标的资源(如安全评估工具)、责任人(如目标衔接

策划

开发团队负责人)及完成时限，确保安全要求落地有目标支撑。

应用程序安全要求的具体内容(如加密标准、访问控制规则)、批准记录(如管理层审批文件)、风险评估与

7.5成文信息处置的关联记录(如风险与安全要求对应表)等，需按7.5要求形成成文信息，确保标识清晰、存储保护到位、文档支持

可迫溯可审计。

应用程序的开发或获取属于组织核心运行过程，需通过8.1的运行策划和控制(建立过程准则、控制计划内变更

8.1运行策划和控制、管控外部提供的应用服务),将“识别、规定、批准安全要求”嵌入开发/获取全流程(如需求评审阶段必审执行框架

安全要求),确保安全要求不遗漏。

除开发/获取初期的风险评估外，需按8.2要求，在应用程序发生重大变更(如功能升级)或按计划间隔，对其

8.2信息安全风险评估持续评估

安全要求的有效性进行再评估(如原有安全要求是否覆盖新风险),确保安全要求持续适配风险场景。

加油努力你行的

关联GB/T22080条款逻辑关联关系分析关联性质

针对8.2再评估发现的应用程序新风险，需通过8.3实现风险处置计划，包括更新或补充应用程序安全要求(如

8.3信息安全风险处置处置实施

新增隐私保护要求),并落实对应的技术或管理措施(如部署数据脱敏工具),

9.1监视、测量、分析和评需按9.1要求，确定监视对象(如应用程序安全要求的合规率、安全漏洞修复率)、测量方法(如定期扫描应用

绩效评价

价程序是否符合安全要求),分析评价安全要求的落实效果，为后续优化安全要求提供数据支撑。

通过9.2的内部审核(按审核方案执行、确保客观性),验证应用程序在开发/获取过程中是否按8.26.2要求完

9.2内部审核合规验证

整识别、合规规定、正式批准安全要求，以及相关成文信息是否齐全，排查不符合体系要求的问题。

当发现应用程序开发/获取过程中存在“未识别关键安全要求”“安全要求未获批准即落地”等不符合项时，需

10.2不符合与纠正措施通过10.2的不符合处理过程(评审不符合、分析原因、实施纠正措施如补充审批流程),消除问题根源并防止纠正保障

同类情况再发生。

(3)“8.26.2控制”与GB/T22081-2024其他条款逻辑关联关系，

“8.26.2控制”与GB/T22081-2024其他条款逻辑关联关系分析表

关联GB/T22081条款逻辑关联关系分析关联性质

5.8要求在项目早期阶段提出信息安全要求(如应用安全要求),并将其纳入项目全生命周期管理：8.26.2是在应用

5.8项目管理中的信息

程序开发/获取场景下具体落实该要求，明确安全要求的识别、规定与批准流程，确保项目层面的安全目标传递至应直接支持

安全

用层。

8.26.4指南明确应用程序安全要求需“确定要处理的信息类型和分级”,5.12提供了信息分级的通用方法(基于保

5.12信息分级直接输入

密性、完整性、可用性),为应用程序层面确定差异化安全要求(如敏感信息加密、普通信息访问控制)提供直接

加油努力你行的

关联GB/T22081条款逻辑关联关系分析关联性质

依据。

8.26.4指南要求应用程序安全要求包含“对访问应用程序中的数据和功能的隔离需求及访问级别”,5.15规定了访

5.15访问控制直接实施

问控制的总体原则(如按需所知、按需使用)和规则设计方法，是应用程序访问控制安全要求的直接实施依据。

8.26.4指南明确要求应用程序安全要求考虑“交易产生、处理、完成或存储所在司法管辖区的法律、法规和监管要

5.31法律、法规、规章

求”(如数据保护法、电子交易法规),5.31提供了识别此类法律/合同要求的通用框架，为应用程序安全要求的合直接输入

和合同要求

规性提供直接依据。

8.26.4指南强调应用程序安全要求需纳入“所有相关方的隐私需求”“个人可识别信息(PII)保护要求”(如PII

5.34隐私和个人可识

传输加密、访问权限限制),5.34规定了PII保护的通用控制(如隐私影响评估、PII处理规程),是应用程序隐私直接输入

别信息保护

类安全要求的直接依据。

8.26.4指南提出应用程序安全要求需包含“对所有相关方之间的通信进行安全加密”“通过密码技术解决保密性，

8.24密码技术的使用完整性、抗抵赖性问题”(如数字签名、数据加密),8.24提供了密码技术使用的规则(如算法选择、密钥管理),直接支撑

是应用程序落实加密等安全要求的技术依据。

8.25安全开发生存周8.25要求在软件开发生命周期(需求、设计、开发、测试、部署)中集成安全：8.26.2是在“需求阶段”明确应用

直接衔接

期程序安全要求，是安全开发生命周期的起点，为后续设计、编码、测试环节提供安全目标。

8.27系统安全架构和8.27提供了系统级安全架构原则(如纵深防御、默认安全、零信任),8.26.2是在应用层具体落实这些原则(如基

直接落实

工程原则于零信任的身份鉴别要求、基于纵深防御的多层访问控制要求),确保系统架构安全目标传递至应用程序。

8.28安全编码8.28要求开发过程中遵循安全编码原则(如防范SQL注入、缓冲区溢出),而安全编码的具体方向需依据8.26.2所规直接指导

加油努力你行的

关联GB/T22081条款逻辑关联关系分析关联性质

定的安全要求(如“输入验证”“恶意攻击防护”要求),是安全编码的直接指导依据。

8.29开发和验收中的8.29要求通过安全测试(如漏洞扫描、渗透测试)验证应用程序安全性，而测试的核心依据是8.26.2所批准的安全

直接验证

安全测试要求(如“访问控制有效性”“数据加密正确性”),确保应用程序符合预设安全目标。

若应用程序通过外包开发，8.26.2所确定的安全要求雷在外包合同中明确(如8.30指南要求的“安全设计、编码和

8.30开发外包直接约束

测试活动的合同要求”),8.30提供了外包过程中安全要求的传递与监督机制，对8.26.2要求形成直接约束。

8.31要求隔离开发、测试与生产环境，避免测试活动影响生产安全：而应用程序安全要求在不同环境中需保持一致

8.31开发、测试和生产

性(如测试环境的访问控制要求与生产环境一致),8.31为安全要求的跨环境落实提供环境保障，避免环境差异导间接支持

环境的隔离

致安全要求失效。

应用程序开发/获取过程中，若需调整已批准的安全要求(如新增合规要求导致的加密算法变更、业务变更导致的访

8.32变更管理问权限调整),需遵橘8.32的变更管理规程(如变更评估、授权、测试),确保安全要求的变更受控且不引入新风直接约束

险。

8.29的安全测试需使用符合8.26.2安全要求的测试信息(如敏感信息需脱敏、测试数据需模拟真实业务场景),8.33

8.33测试信息规定了测试信息的选择、保护和管理要求(如“不将敏感信息复制到测试环境”“测试后删除敏感测试数据”),直接协同

确保测试过程不违反应用程序的安全要求，与8.26.2形成协同。

GB/T22081-2024《网络安全技术——信息安全控制》

8.26.3目的

确保在开发或获取应用程序时，识别升满足所有信息安全要求。

8.26.3目的

加油努力你行的

“8.26.3(应用程序安全要求)目的”解读说明表

内容维度“8.26.3(应用程序安全要求)目的”解读说明

本条款旨在强调在应用程序开发或获取过程中，应系统性地识别、评估并满足所有相关的信息安全要求，确保信息安全在应用程序生命周期

总述(本条款的的起始阶段即被纳入考量。其核心意图在于强化信息安全的“前置控制”理念，防止因开发初期忽视安全需求而导致后续难以弥补的安全漏