信息安全技术应用软件供应链安全技术规范

软件供应链安全检测是确保软件在整个生命周期内的安全性、稳定性和可靠性的重要环节。以下是对软件供应链安全检测的详细解答：一、软件供应链安全检测的重要性防范安全风险：通过安全检测，可以及时发现并修复软件中的安全漏洞，从而有效防范潜在的安全风险。提高软件质量：安全检测能够确保软件的质量和稳定性，提升用户体验和满意度。 符合法规要求：许多行业对软件的安全性有严格的法规要求，进行安全检测有助于确保软件符合相关法规标准。二、软件供应链安全检测的主要内容源码检测：对软件的源代码进行审查，以发现潜在的安全漏洞和不合规的代码实践。组件检测：检测软件中所使用的第三方组件的安全性，确保这些组件没有已知的安全漏洞。应用功能检测：对软件的功能进行全面测试，以确保其功能正常且没有安全隐患。渗透测试：通过模拟黑客攻击的方式，测试软件的防御能力，以发现潜在的安全漏洞。环境检测：检测软件运行环境的安全性，包括操作系统、数据库、网络等，以确保软件在安全的环境中运行。

信息安全技术 应用软件供应链安全技术规范

• 引言
• 范围
  • 本文件规定了应用软件供应链安全技术规范。
  • 本文件适用于应用软件供应链安全的设计、开发和测试。
• 2　规范性引用文件
  • GB/T 25069 信息安全技术 术语
  • GB/T 20220164-T-469 信息安全技术 软件供应链安全要求
• 3　术语和定义
  • 制品 artifact
    • 由某一种软件开发过程所使用的或产生的一种信息的物理件。制品的实例有模型、源文件、文字和二进制可执行文件。制品可构成可部署构件的实现。
    • [来源：GB/T11457—2006，定义2.76]
  • 反编译 decompile
    • 将软件中的程序文件还原成汇编或者高级语言代码的过程。
  • 软件成分 software composition
    • 软件中包含的组件和代码。
  • 访问控制 access control
    • 防止对资源的未授权使用， 包括防止以未授权方式使用某一资源。
  • 投毒 poisoning
    • 软件成分中被加入非预期逻辑，如执行恶意代码、输出额外数据、创建与预期功能无关文件等，包含篡改和仿冒两种实现方式。
  • 篡改 tamper
    • 修改开源组件的内部逻辑，并以相同名称发布，以达到破坏系统或窃取信息等目的。
  • 仿冒 counterfeit
    • 对开源组件的标识、功能或外观进行模仿，创建与合法组件外观或功能相似的组件，以达到破坏系统或窃取信息等目的。
  • 对称加密算法 symmetric encryption algorithm
    • 源发者和接收者使用同一秘密密钥进行变换的加密算法。
  • 非对称加密算法 asymmetric encryption system
    • 基于非对称密码技术的加密方法,其公开变换用于加密,而私有变换用于解密。
• 4　缩略语
  • IAC 基础设施即代码 （Infrastructure as Code）
  • TLS 传输层安全 （Transport Layer Security）
  • SSL 安全套接字层 （Secure Sockets Layer）
  • SLA 服务级别协议 （Service Level Agreement）
• 5　安全技术要求
  • 5.1　开发阶段安全要求
    • 5.1.1　代码安全要求
      • 5.1.1.1　代码安全
        • 软件产品应遵循最佳安全编码实践，包括：
        • a)应避免密码硬编码、资源未释放、野指针、线程死锁、参数未校验等常见编码规范风险；
        • b)应避免SQL注入、XPath注入、跨站脚本、缓冲区错误、密码硬编码、路径遍历、系统信息泄露等常见中高风险代码安全漏洞，或具备补救措施防范漏洞安全风险； 注：漏洞风险等级参照国家网络安全漏洞分类分级指南（如GB/T 30279等标准）等国家有关规定。
        • c)源代码不应存在广告投放、后门、病毒、蠕虫、木马、隐蔽信道等恶意操作代码。
      • 5.1.1.2　代码质量
        • 软件产品源代码编写应满足代码质量要求，包括：
        • a)应遵循高内聚低耦合的原则，将代码划分为模块和组件，每个模块或组件负责特定的功能；
        • b)不应包含冗余代码，包括未使用接口（含远程调试接口）、无关功能等，不应捆绑无关软件等。
        • c)应添加必要的注释，注释应简洁明了，解释关键部分的输入输出。（增强级）
    • 5.1.2　软件成分安全要求
      • 5.1.2.1　第三方组件漏洞
        • 应用软件中三方组件应不存在已知公开安全漏洞。
      • 5.1.2.2　开源合规风险
        • 应用软件成分应不存在开源许可合规风险，包括：
        • a)应采用开源许可互相兼容的开源组件；
        • b)应满足开源许可中要求的使用和发布方式；
        • c)以源码方式引入开源组件时，应保留原开源许可声明。
      • 5.1.2.3　供应连续性风险
        • 应用软件使用的三方组件不应存在停止维护、长期未更新、自研率较低等供应中断风险。
      • 5.1.2.4　组件投毒风险
        • 应用软件成分应不存在投毒风险，包括：
        • a)应保障所使用开源组件未被篡改或仿冒；
        • b)应保障所使用开源代码及组件未包含恶意代码。（增强级）
    • 5.1.3　功能安全要求
      • 5.1.3.1　业务安全
        • 5.1.3.1.1　身份鉴别
          • 软件产品应遵循GB/T 22239-2019网络安全等级保护基本要求中对身份鉴别的相关要求，包括：
          • a)应对登录的用户进行身份标识和鉴别,身份标识具有唯一性,身份鉴别信息具有复杂度要求并定期更换;
          • b)应具有登录失败处理功能,应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施;
          • c)当进行远程管理时,应采取必要措施防止鉴别信息在网络传输过程中被窃听;
          • d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别,且其中一种鉴别技术至少应使用密码技术来实现；
          • e)使用口令鉴别方式时，应支持首次管理产品时强制修改默认口令或设置口令，或支持随机的初始口令，支持设置口令生存周期，支持口令复杂度检查功能，用户输入口令时，不应明文回显口令；（增强级）
          • f)支持口令复杂度检查功能，口令复杂度检查包括口令长度检查、口令字符类型检查、口令与账号无关性检查中的至少一项；（增强级）
          • g)应支持启用安全策略或具备安全功能，以防范用户鉴别信息猜解攻击；（增强级）
          • h)应支持启用安全策略或具备安全功能，以防止用户登录后会话空闲时间过长。（增强级）
        • 5.1.3.1.2　访问控制
          • 软件产品应遵循GB/T 22239-2019网络安全等级保护基本要求中对访问控制的相关要求，包括：
          • a)应对登录的用户分配账户和权限;
          • b)应要求重命名或删除默认账户,修改默认账户的默认口令;
          • c)应授予管理用户所需的最小权限,实现管理用户的权限分离;
          • d)应由授权主体配置访问控制策略,访问控制策略规定主体对客体的访问规则;
          • e)访问控制的粒度应达到主体为用户级或进程级,客体为文件、数据库表级;
          • f)应对重要主体和客体设置安全标记,并控制主体对有安全标记信息资源的访问。
        • 5.1.3.1.3　安全审计
          • 软件产品应遵循GB/T 22239-2019网络安全等级保护基本要求中对安全审计的相关要求，包括：
          • a)应启用安全审计功能,审计覆盖到每个用户,对重要的用户行为和重要安全事件进行审计;
          • b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息;
          • c)应对审计记录进行保护,定期备份,避免受到未预期的删除、修改或覆盖等;
          • d)应对审计进程进行保护,防止未经授权的中断；
          • e)应提供日志信息本地存储功能，支持日志信息输出；（增强级）
          • f)应具备对日志在存储和输出过程进行保护的安全功能，防止日志内容被未经授权的查看、输出或删除。（增强级）
        • 5.1.3.1.4　个人隐私保护
          • 软件产品应具备个人隐私保护功能，应遵循GB/T 35273-2020和GB/T 34978-2017中对个人信息保护的相关要求，包括在搜集、存储、使用、共享、转让、公开披露、删除等个人信息处理活动的原则和安全要求。
        • 5.1.3.1.5　安全退出
          • 软件产品应具备安全退出功能，包括：
          • a)应提供安全的退出功能，确保用户在离开系统时能够有效地终止会话；
          • b)应能够自动登出用户，在一段时间内没有操作时，以防止未经授权的访问；
          • c)应清除在用户会话期间生成的临时数据和缓存，避免信息泄露和安全漏洞。
      • 5.1.3.2　API安全
        • 5.1.3.2.1　身份验证与授权
          • 软件产品应具备身份验证与授权功能，包括：
          • a)应使用标准的身份验证机制，以确保只有经过授权的用户能够访问API；
          • b)应实施适当的授权机制，基于用户的角色和权限，限制其对API的访问和操作。
        • 5.1.3.2.2　API访问控制
          • 软件产品应具备API访问控制功能，包括：
          • a)应在 API 层面实施访问控制，确保只有具有必要权限的用户或系统能够调用特定的 API；
          • b)应使用 API 密钥、令牌或其他凭证机制来验证和授权 API 请求。
    • 5.1.4　安全开发要求
      • 5.1.4.1　安全需求分析
        • a)应对软件产品的安全威胁模型进行评估，识别潜在的安全风险和漏洞；
        • b)软件产品应在设计阶段明确定义安全需求，并将其纳入产品需求规格文档或者单独的安全需求设计文档。
      • 5.1.4.2　安全编码规范
        • 软件产品应制定安全编码规范，并确保开发团队严格遵守；
      • 5.1.4.3　源代码安全管理
        • 软件产品对源代码进行安全管理，包括：
        • a)建立严格的访问控制策略，限制对源代码仓库和开发环境的访问。只有授权人员才能够访问、修改和复制源代码；
        • b)确保只有经过身份验证的用户才能够访问源代码，同时实施细粒度的授权策略，确保每个用户仅能够访问其需要的代码部分；
        • c)在源代码传输过程中使用加密技术，例如SSL/TLS，以确保数据在传输过程中的保密性；
        • d)采用严格的版本控制系统，记录源代码的每一次修改，并保留历史版本，以便在需要时进行追溯和恢复；
        • e)定期对源代码进行备份，并存储在安全的位置，以防止数据丢失或意外删除。
      • 5.1.4.4　安全测试和验证
        • a)软件产品应在上线前进行安全测试和验证，包括但不限于黑盒测试、白盒测试以及灰盒测试等，并输出安全测试报告；
        • b)软件产品应在开发生命周期的多个环节进行安全测试和验证，至少包括第三方组件和源代码的安全风险测试，并输出安全测试报告（增强级）。
      • 5.1.4.5　漏洞运营管理
        • a)软件产品应根据漏洞的严重程度和影响范围，对漏洞进行分类和优先级排序，设立对应的漏洞修复SLA。
        • b)软件产品应及时修复软件产品中已确认的漏洞，并进行验证测试以确保修复的有效性。
  • 5.2　供应阶段安全要求
    • 5.2.1　配置安全要求
      • 保护软件产品软件配置文件及其内容配置安全，包括：
      • a)基本配置信息，包括网络拓扑结构、各个设备安装的软件组件、软件版本和补丁信息、各个设备或软件组件的配置参数等。
      • b)配置文件中应不包含敏感信息，如密码、密钥等；
      • c)应对配置文件的访问权限进行限制，只允许授权的用户或进程进行访问和修改；
      • d)应保护软件产品IaC文件的安全性，包括但不限于网络配置、访问控制等配置项是否有错误配置及风险项配置。（增强级）
    • 5.2.2　制品安全要求
      • 5.2.2.1　制品完整性
        • 应用软件应能够保护制品完整性，包括：
        • a)应支持文件完整性校验，防止运行篡改后的制品；
        • b)应支持避免通过制品还原源代码，避免源代码泄漏。（增强级）
      • 5.2.2.2　制品安全漏洞
        • 应用软件制品中应不存在SQL注入、命令注入、缓冲区溢出、密码硬编码、敏感信息泄漏、dll劫持等安全漏洞。
      • 5.2.2.3　安全保护机制
        • 应用软件制品中应设置安全保护机制，包括但不限于ASLR地址随机、栈溢出保护、FORTIFY缓冲区溢出检查、RELRO只读等编译安全选项，降低应用软件启动和运行过程中的缓冲区溢出和恶意代码执行等安全风险。（增强级）
    • 5.2.3　安全交付要求
      • 5.2.3.1　安全配置和部署
        • a)软件产品应在软件产品部署前应进行安全配置，包括密钥管理、身份验证设置等；
        • b)软件产品应对软件产品实施安全补丁和更新，确保系统处于最新和安全的状态。
      • 5.2.3.2　安全审查和验收
        • 软件产品应在软件产品交付前进行安全审查，确保软件产品符合组织内部安全标准和合规要求，输出安全评审及验收报告。
  • 5.3　运维阶段安全要求
    • 5.3.1　数据安全要求
      • 5.3.1.1　数据加密要求
        • a)应根据所属行业要求，选择适合的加密技术，至少使用通道加密和内容加密结合的加密技术，一般的数据压缩技术不得代替安全手段；
      • 5.3.1.2　数据访问控制
        • a)软件产品应在网络边界或区域之间根据访问控制策略设置访问控制规则，默认情况下除允许通信外受控接口拒绝所有通信；
        • b)软件产品应删除多余或无效的访问控制规则，优化访问控制列表，并保证访问控制规则数量最小化；
        • c)软件产品应能根据会话状态信息为进出数据流提供明确的允许/拒绝访问的能力；
        • d)应使用TLS/SSL协议对API通信进行加密，以防止数据在传输过程中被窃听或篡改；
        • e)对于敏感数据的传输，例如身份信息或支付信息，要求在传输前进行端到端的加密。
      • 5.3.1.3　数据备份与恢复
        • a)软件产品应具有必要的备份恢复功能，对存储的信息数据进行备份和必要时的恢复处理，同时保证备份、恢复信息的完整性、可靠性和准确性；（增强级）
        • b)软件产品应具有策略设置功能，在服务器和虚拟服务器上存储信息时，可以根据对信息进行处理的方式，制定相应的保护策略，包括：权限分配、访问控制、密钥管理、存储期限、覆盖方式、备份恢复等。（增强级）
    • 5.3.2　安全运维要求
      • 5.3.2.1　漏洞响应流程
        • a)软件产品应通过应用安全测试工具对组件、接口等进行持续定期扫描；
        • b)软件产品应具备风险自动化或人工审核机制，确保对已知漏洞和新发现的漏洞进行及时监测和跟踪；
        • c)软件产品应具备漏洞更新策略，确保及时获取厂商和第三方供应商发布的漏洞修复补丁；
        • d)软件产品应具备漏洞修复方案，包括漏洞验证、部署和测试，以最小化漏洞修复带来的生产环境中的中断。
• 6　测试评价方法
  • 6.1　开发阶段安全要求
    • 6.1.1　代码安全要求
      • 6.1.1.1　代码安全
        • a)测试方法：
          • 1)准备被测软件源代码；
          • 2)使用静态应用安全检测工具、代码审计等技术手段对源代码进行安全编码检测；
          • 3)参考最佳实践检查是否存在常见编码规范问题和中高风险安全漏洞；
          • 4)查看漏洞补救防范措施是否合理；
          • 5)使用恶意代码检测工具等技术手段检查软件是否存在广告投放、后门、病毒、蠕虫、木马、隐蔽信道等等恶意操作行为。
        • b)预期结果：
          • 1)被测软件源代码未检测发现密码硬编码、资源未释放、野指针、线程死锁、参数未校验等常见编码规范风险；
          • 2)被测软件原代码未检测发现SQL注入、XPath注入、跨站脚本、缓冲区错误、密码硬编码、路径遍历、系统信息泄露等常见代码安全漏洞风险。
          • 3)被测软件未检测发现广告投放、后门、病毒、蠕虫、木马、隐蔽信道等恶意操作代码。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.1.2　代码质量
        • a)测试方法：
          • 1)准备被测软件源代码；
          • 2)查看软件高层设计报告，使用代码审计等方式对源代码模块化程度进行分析；
          • 3)查看软件高层设计报告，使用代码审计、安装包分析、安装过程观察、捆绑软件检测工具等方式对软件系统进行功能走查，查看是否包含冗余代码、无关功能，或捆绑无关软件；
          • 4)使用流量分析、插桩检测等技术对软件进行接口检测分析，查看是否存在冗余接口；
          • 5)使用静态代码检测工具对源代码注释率进行分析。（增强级）
        • b)预期结果：
          • 1)软件各模块功能独立、接口清晰、高内聚、低耦合，容易被其他项目重用；
          • 2)软件不存在冗余代码、未使用接口、无关功能等，未捆绑下载无关软件；
          • 3)软件注释简洁明了，解释关键部分的输入输出，注释率不低于30%。（增强级）
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.1.2　软件成分安全要求
      • 6.1.2.1　第三方组件漏洞
        • a)测试方法：
          • 1)使用应用软件代码或制品作为测试对象；
          • 2)利用软件成分分析系统对源代码或制品进行检测；
          • 3)检查三方组件是否包含已知公开安全漏洞；
          • 4)分析是否存在漏洞组件未被代码引用或函数调用、组件漏洞不满足触发条件等漏洞不可利用场景。
        • b)预期结果：
          • 1)软件组件不存在可利用的已知公开安全漏洞；
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.2.2　开源合规风险
        • a)测试方法：
          • 1)使用应用软件代码或制品作为测试对象；
          • 2)利用软件成分分析系统测试；
          • 3)检查结果中是否采用开源许可互相兼容的开源组件；
          • 4)检查结果中是否满足开源许可中要求的使用和发布方式；
          • 5)若应用软件中存在以源码形式引入开源组件的情况，检查结果中是否更改或删除了原开源许可声明。
        • b)预期结果：
          • 1)应用软件采用开源许可互相兼容的开源组件；
          • 2)应用软件满足开源许可中要求的使用和发布方式；
          • 3)以源码方式引入开源组件时，应保留原开源许可声明。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.2.3　供应连续性风险
        • a)测试方法：
          • 1)准备被测软件源代码；
          • 2)对三方组件进行更新维护情况分析；
          • 3)对源代码自研率进行分析。
        • b)预期结果：
          • 1)不存在停止维护或超过2年未更新且存在漏洞风险的三方组件；
          • 2)源代码自研率不低于30%。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.2.4　组件投毒风险
        • a)测试方法：
          • 1)使用应用软件代码或制品作为测试对象；
          • 2)利用软件成分分析系统测试；
          • 3)检查结果中是否存在开源组件被篡改或仿冒的风险信息；
          • 4)检查结果中是否存在开源代码或组件包含恶意代码的风险信息。（增强级）
        • b)预期结果：
          • 1)不存在开源组件被篡改或仿冒的风险；
          • 2)不存在开源代码或组件包含恶意代码的风险。（增强级）
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.1.3　功能安全要求
      • 6.1.3.1　业务安全
        • 6.1.3.1.1　身份鉴别
          • a)测试方法：
            • 1)测试软件产品是否满足GB/T 22239-2019网络安全等级保护基本要求中对身份鉴别的相关要求；
            • 2)测试软件产品使用口令鉴别方式时，是否支持支持首次管理产品时强制修改默认口令或设置口令，或支持随机的初始口令，是否支持设置口令生存周期，是否支持口令复杂度检查功能，用户输入口令时，不应明文回显口令；（增强级）
            • 3)测试软件产品是否支持口令复杂度检查功能，口令复杂度检查包括口令长度检查、口令字符类型检查、口令与账号无关性检查中的至少一项；（增强级）
            • 4)测试软件产品是否支持启用安全策略或具备安全功能，以防范用户鉴别信息猜解攻击；（增强级）
            • 5)测试软件产品是否支持启用安全策略或具备安全功能，以防止用户登录后会话空闲时间过长；（增强级）
          • b)预期结果：
            • 1)V软件产品具有登录失败处理功能,配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施;
            • 2)软件产品在进行远程管理时,能够防止鉴别信息在网络传输过程中被窃听;
            • 3)软件产品采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别,且其中一种鉴别技术至少应使用密码技术来实现。
            • 4)软件产品使用口令鉴别方式时，支持支持首次管理产品时强制修改默认口令或设置口令，或支持随机的初始口令，支持设置口令生存周期，支持口令复杂度检查功能，用户输入口令时，不应明文回显口令；（增强级）
            • 5)软件产品支持口令复杂度检查功能，口令复杂度检查包括口令长度检查、口令字符类型检查、口令与账号无关性检查中的至少一项；（增强级）
            • 6)软件产品支持启用安全策略或具备安全功能，以防范用户鉴别信息猜解攻击；（增强级）
            • 7)软件产品支持启用安全策略或具备安全功能，以防止用户登录后会话空闲时间过长；（增强级）。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.1.3.1.2　访问控制
          • a)测试方法：
            • 1)测试软件产品是否遵循GB/T 22239-2019网络安全等级保护基本要求中对访问控制的相关要求
          • b)预期结果：
            • 1)软件产品对登录的用户分配账户和权限;
            • 2)软件产品要求重命名或删除默认账户,修改默认账户的默认口令;
            • 3)软件产品授予管理用户所需的最小权限,实现管理用户的权限分离;
            • 4)软件产品由授权主体配置访问控制策略,访问控制策略规定主体对客体的访问规则;
            • 5)软件产品访问控制的粒度达到主体为用户级或进程级,客体为文件、数据库表级;
            • 6)软件产品对重要主体和客体设置安全标记,并控制主体对有安全标记信息资源的访问。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.1.3.1.3　安全审计
          • a)测试方法：
            • 1)测试软件产品是否遵循GB/T 22239-2019网络安全等级保护基本要求中对安全审计的相关要求。
            • 2)测试软件产品是否提供日志信息本地存储功能，支持日志信息输出；（增强级）
            • 3)测试软件产品是否具备对日志在存储和输出过程进行保护的安全功能，防止日志内容被未经授权的查看、输出或删除。（增强级）
          • b)预期结果：
            • 1)软件产品启用安全审计功能,审计覆盖到每个用户,对重要的用户行为和重要安全事件进行审计;
            • 2)软件产品审计记录包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息;
            • 3)软件产品对审计记录进行保护,定期备份,避免受到未预期的删除、修改或覆盖等;
            • 4)软件产品对审计进程进行保护,防止未经授权的中断。
            • 5)软件产品提供日志信息本地存储功能，支持日志信息输出；（增强级）
            • 6)软件产品具备对日志在存储和输出过程进行保护的安全功能，防止日志内容被未经授权的查看、输出或删除。（增强级）
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.1.3.1.4　个人隐私保护
          • a)测试方法：
            • 1)测试软件产品是否遵循遵循GB/T 35273-2020和GB/T 34978-2017中对个人信息保护的相关要求；
          • b)预期结果：
            • 1)软件产品在搜集、存储、使用、共享、转让、公开披露、删除等个人信息处理活动遵循个人信息保护的相关原则和安全要求。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.1.3.1.5　安全退出
          • a)测试方法：
            • 1)测试软件产品是否具备安全的退出功能；
            • 2)测试软件产品是否能够在一段时间内没有操作时自动登出用户；
            • 3)测试软件产品是否清除在用户会话期间生成的临时数据和缓存。
          • b)预期结果：
            • 1)软件产品具备安全的退出功能，确保用户在离开系统时能够有效地终止会话；
            • 2)软件产品能够自动登出用户，在一段时间内没有操作时，以防止未经授权的访问；
            • 3)软件产品能够清除在用户会话期间生成的临时数据和缓存，避免信息泄露和安全漏洞。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.3.2　API安全
        • 6.1.3.2.1　身份验证与授权
          • a)测试方法：
            • 1)测试软件产品是否使用标准的身份验证机制；
            • 2)测试软件产品是否实施适当的授权机制。
          • b)预期结果：
            • 1)软件产品使用标准的身份验证机制，以确保只有经过授权的用户能够访问API；
            • 2)软件产品实施适当的授权机制，基于用户的角色和权限，限制其对API的访问和操作。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.1.3.2.2　API访问控制
          • a)测试方法：
            • 1)测试软件产品是否在 API 层面实施访问控制；
            • 2)测试软件产品是否使用 API 密钥、令牌或其他凭证机制来验证和授权 API 请求。
          • b)预期结果：
            • 1)软件产品在 API 层面实施访问控制，确保只有具有必要权限的用户或系统能够调用特定的 API；
            • 2)软件产品使用 API 密钥、令牌或其他凭证机制来验证和授权 API 请求。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.1.4　安全开发要求
      • 6.1.4.1　安全需求分析
        • a)测试方法：
          • 1)根据软件产品的产品需求规格文档或者安全需求文档，测试是否对软件产品的安全威胁模型进行评估，明确定义安全需求；
        • b)预期结果：
          • 1)软件产品对安全威胁模型进行评估，在设计阶段明确定义安全需求，并将其纳入产品需求规格文档或者单独的安全需求设计文档；
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.4.2　安全编码规范
        • a)测试方法：
          • 1)测试软件产品是否有可遵循安全编码规范；
        • b)预期结果：
          • 1)软件产品有可遵循的安全编码规范；
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.4.3　源代码安全管理
        • a)测试方法：
          • 1)通过访谈的形式对软件产品供应商的源代码管理机制进行测试；
        • b)预期结果：
          • 1)针对源代码建立严格的访问控制策略，限制对源代码仓库和开发环境的访问。只有授权人员才能够访问、修改和复制源代码；
          • 2)只有经过身份验证的用户才能够访问源代码，同时实施细粒度的授权策略，确保每个用户仅能够访问其需要的代码部分；
          • 3)在源代码传输过程中使用加密技术，例如SSL/TLS，以确保数据在传输过程中的保密性；
          • 4)采用严格的版本控制系统，记录源代码的每一次修改，并保留历史版本，以便在需要时进行追溯和恢复；
          • 5)定期对源代码进行备份，并存储在安全的位置，以防止数据丢失或意外删除。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.4.4　安全测试和验证
        • a)测试方法：
          • 1)根据提供的安全测试报告，测试软件产品在开发生命周期中进行了哪些安全测试；
        • b)预期结果：
          • 1)软件产品在上线前进行了安全测试和验证，包括但不限于黑盒测试、白盒测试以及灰盒测试等；
          • 2)软件产品在开发生命周期的多个环节进行安全测试和验证，至少包括第三方组件和源代码的安全风险测试。（增强级）
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.1.4.5　漏洞运营管理
        • a)测试方法：
          • 1)根据提供的漏洞运营管理文档，测试软件产品是否根据漏洞的严重程度和影响范围，对漏洞进行分类和优先级排序，设立对应的漏洞修复SLA；
          • 2)根据提供的漏洞修复报告，测试软件产品是否及时修复软件产品中已确认的漏洞，并进行验证测试以确保修复的有效性；
        • b)预期结果：
          • 1)软件产品根据漏洞的严重程度和影响范围，对漏洞进行分类和优先级排序，设立对应的漏洞修复SLA。
          • 2)软件产品及时修复软件产品中已确认的漏洞，并进行验证测试以确保修复的有效性；
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
  • 6.2　供应阶段安全要求
    • 6.2.1　配置安全要求
      • a)测试方法：
        • 1)供方应提供记录和保存系统的基本配置信息文件,包括网络拓扑结构、各个设备安装的软件组件、软件版本和补丁信息、各个设备或软件组件的配置参数等。
        • 2)测试软件产品的配置文件中是否包含敏感信息，如密码、密钥等；
        • 3)测试软件产品是否对配置文件的访问权限进行限制；
        • 4)提供对试软件产品的IaC文件扫描报告，包括但不限于对Dockerfile、Terraform、manifest、Helm Charts等进行安全检测，检测内容中包括但不限于网络配置、访问控制等配置项是否有错误配置及风险项配置。（增强级）
      • b)预期结果：
        • 1)应用软件的基础配置信息文件匹配，且网络拓扑结构无安全风险，各个设备安装的软件组件、软件版本和补丁信息无漏洞风险及许可证风险，各个设备或软件组件的配置参数无错误配置及风险项配置。
        • 2)软件产品的配置文件中不包含敏感信息，如密码、密钥等；
        • 3)软件产品对配置文件的访问权限进行限制，只允许授权的用户或进程进行访问和修改；
        • 4)软件产品IaC文件中的网络配置、访问控制等配置项无错误配置及风险项配置。（增强级）
      • c)结果判定：
        • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.2.2　制品安全要求
      • 6.2.2.1　制品完整性
        • a)测试方法：
          • 1)使用应用软件制品作为测试对象；
          • 2)根据制品格式重新打包（如使用apktool对apk文件重新打包），检查其是否能够正常运行；
          • 3)反编译制品（如使用ilspy反编译.net制品），检查是否能够获得产品源代码。（增强级）
        • b)预期结果：
          • 1)重新打包后的制品无法正常运行；
          • 2)制品通过反编译无法获得源代码。（增强级）
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.2.2.2　制品安全漏洞
        • a)测试方法：
          • 1)使用应用软件制品作为测试对象；
          • 2)根据制品格式进行提取、反编译（如需要），检测其是否包含安全漏洞；
          • 3)分析是否存在由于输入数据不可控等原因导致漏洞逻辑在程序中不会被触发的不可利用场景。
        • b)预期结果：
          • 1)不存在可利用安全漏洞。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.2.2.3　安全保护机制（增强级）
        • a)测试方法：
          • 1)使用应用软件制品作为测试对象；
          • 2)利用制品安全风险检测工具对制品进行检测；
          • 3)分析结果中是否存在ASLR地址随机、栈溢出保护、FORTIFY缓冲区溢出检查、RELRO只读配置不当等风险。
        • b)预期结果：
          • 1)不存在安全保护机制缺失或配置不当的结果。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.2.3　安全交付要求
      • 6.2.3.1　安全配置和部署
        • a)测试方法：
          • 1)根据软件产品的配置部署文档，测试软件产品是否提供了部署前的安全配置，包括密钥管理、身份验证设置等；
          • 2)根据软件产品的产品升级报告或者安全测试报告，测试软件产品是否实施安全补丁和更新，系统处于最新和安全的状态。
        • b)预期结果：
          • 1)软件产品提供了配置部署文档，在部署前进行安全配置，包括密钥管理、身份验证设置等；
          • 2)软件产品实施了安全补丁和更新，确保系统处于最新和安全的状态。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.2.3.2　安全审查和验收
        • a)测试方法：
          • 1)测试软件产品是否在交付前进行了全面的安全审查，是否有符合内部安全要求的安全评审及验收报告；
        • b)预期结果：
          • 1)软件产品交付前进行了安全审查，确保软件产品符合安全标准和合规要求，并输出安全评审及验收报告；
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
  • 6.3　运维阶段安全要求
    • 6.3.1　数据安全要求
      • 6.3.1.1　数据加密要求
        • a)测试方法：
          • 1)判断产品所属行业，查找对应行业规范，若无行业规范，应对产品数据传输过程中，进行数据采集提取；
        • b)预期结果：
          • 1)数据传输通道加密，被抓包的数据包及数据内容处于加密状态；
        • c)结果判定：
          • 实际测试结果与相关预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.3.1.2　数据访问控制
        • a)测试方法：
          • 1)应对登录的用户分配账户和权限；
          • 2)应重命名或删除默认账户，修改默认账户的默认密码；
          • 3)应及时删除或停用多余的、过期的账户，避免共享账户的存在；
          • 4)应授予管理用户所需的最小权限，实现管理用户权限分离。
          • 5)测试软件产品是否使用TLS/SSL协议对API通信进行加密；
          • 6)测试软件产品对敏感数据的传输是否在传输前进行端到端的加密。
        • b)预期结果：
          • 1)软件产品对登录用户分配对应账户与权限，不存在默认的、多余的、过期的账户，存在用户权限分离。
          • 2)软件产品使用TLS/SSL协议对API通信进行加密，以防止数据在传输过程中被窃听或篡改；
          • 3)软件产品对于敏感数据的传输，例如身份信息或支付信息，在传输前进行端到端的加密。
        • c)结果判定：
          • 实际测试结果与相关预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.3.1.3　数据备份与恢复
        • 6.3.1.3.1　数据备份（增强级）
          • a)测试方法：
            • 1)按软件产品提供的指导性文档配置备份对象、备份内容及测试环境；
            • 2)分别设置完全备份、增量备份和差量备份等备份方式；
            • 3)对每种备份方式分别进行验证，是否能按预期的备份方式进行备份；
            • 4)对每种备份方式的备份数据分别进行恢复，恢复后的数据是否与备份对象一致且可用。
          • b)预期结果：
            • 1)软件产品支持完全备份、增量备份、差量备份等备份方式。
          • c)结果判定：
            • 实际测试结果与相关预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.3.1.3.2　数据恢复（增强级）
          • 测试方法
            • 1)按软件产品提供的指导性文档，执行恢复任务；
            • 2)选择全部或部分备份数据进行恢复；
            • 3)验证恢复后的数据应与原数据一致。
          • b)预期结果：
            • 1)软件产品能选择全部或部分备份数据进行恢复，恢复后的数据应与原数据一致。
          • c)结果判定：
            • 实际测试结果与相关预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.3.2　安全运维要求
      • 6.3.2.1　漏洞响应流程
        • a)测试方法：
          • 1)测试软件产品是否通过应用安全测试工具对组件、接口等进行持续定期扫描；
          • 2)测试软件产品是否具备风险自动化或人工审核机制，确保对已知漏洞和新发现的漏洞进行及时监测和跟踪；
          • 3)测试软件产品是否具备漏洞更新策略，确保及时获取厂商和第三方供应商发布的漏洞修复补丁；
          • 4)测试软件产品是否具备漏洞修复方案，包括漏洞验证、部署和测试，以最小化漏洞修复带来的生产环境中的中断。
        • b)预期结果：
          • 1)软件产品通过应用安全测试工具对组件、接口等进行持续定期扫描；
          • 2)软件产品具备风险自动化或人工审核机制，确保对已知漏洞和新发现的漏洞进行及时监测和跟踪；
          • 3)软件产品具备漏洞更新策略，确保及时获取厂商和第三方供应商发布的漏洞修复补丁；
          • 4)软件产品具备漏洞修复方案，包括漏洞验证、部署和测试，以最小化漏洞修复带来的生产环境中的中断。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
• 参考文献