信息安全技术静态应用安全测试产品安全技术要求与测试评价方法

SAST（静态应用程序安全测试）是一种安全工具，用于在应用程序不运行时分析源代码、字节码或二进制代码。它的目的是在软件开发的早期阶段发现潜在的安全漏洞，如SQL注入、跨站脚本（XSS）和其他常见的安全威胁。SAST工具能够快速扫描大量代码，为开发人员提供即时的反馈，帮助他们识别和修正安全缺陷。这种工具通常在编码和测试阶段使用，确保代码在发布前满足安全标准。通过使用SAST，组织可以提高其应用程序的安全性，减少后期修复成本，并提高合规性。它是现代安全开发建设中不可或缺的一部分，有助于构建更安全的软件产品。

信息安全技术 静态应用安全测试产品安全技术要求与测试评价方法

• 前言
  • 参考：
    • 标准化工作导则 第1部分：标准化文件的结构和起草规则
  • 起草单位：
    • 公安部网络安全等级保护评估中心
    • 墨菲未来科技(北京)有限公司
    • 悬镜安全（北京安普诺信息技术有限公司）
    • 杭州默安科技有限公司
    • 上海数字安全科技有限公司
    • 软安科技
    • 杭州孝道科技有限公司
  • 主要起草人：
    • 韩清华、王勇、欧阳强斌、焦洋、孟瑾、魏东、熊奎、陈俊杰
• 1　范围
  • 本文件规定了静态应用安全测试系统的安全技术要求和测试评价方法。
  • 本文件适用于静态应用安全测试系统的设计、开发和测试。
• 2　规范性引用文件
  • GB/T 25069—2022 信息安全技术 术语
  • GB/T 11457—2006 信息技术 软件工程术语
  • GB/T 20220164-T-469 信息安全技术 软件供应链安全要求
• 3　术语、定义和缩略语
  • 访问控制 access control
    • 一种保证数据处理系统的资源只能由被授权主体按授权方式进行访问的手段。 [GB/T 25069-2010，定义2.2.1.42]
  • 堆 heap
    • 用于动态内存分配的内存空间。
  • 口令 password
    • 用于身份鉴别的秘密的字、短语、数字或字符序列，通常是被默记的弱秘密。
  • 脚本 script
    • 使用一种特定的描述性语言，依据一定的格式编写的纯文本程序。
  • 下列缩略语适用于本文件。
    • IDE:集成开发环境（Integrated Development Environment）
    • CI:持续集成（Continuous Integration）
    • CD:持续部署（Continuous Deployment）
    • SQL:结构化查询语言（Structred Query Language）
• 4　产品概述
  • SAST（静态应用程序安全测试）是一种安全工具，用于在应用程序不运行时分析源代码、字节码或二进制代码。它的目的是在软件开发的早期阶段发现潜在的安全漏洞，如SQL注入、跨站脚本（XSS）和其他常见的安全威胁。SAST工具能够快速扫描大量代码，为开发人员提供即时的反馈，帮助他们识别和修正安全缺陷。这种工具通常在编码和测试阶段使用，确保代码在发布前满足安全标准。通过使用SAST，组织可以提高其应用程序的安全性，减少后期修复成本，并提高合规性。它是现代安全开发建设中不可或缺的一部分，有助于构建更安全的软件产品。
  • 该类产品的部署方式如图 1所示：
• 5　安全技术要求
  • 5.1　安全功能要求
    • 5.1.1　识别分析
      • 5.1.1.1　软件识别
        • 5.1.1.1.1　开发语言
          • 产品应能够支持多种开发语言，包括：
          • a)应支持C/C++、Java/Jsp、JavaScript、Python等主流开发语言；
          • b)应支持Go、PHP、C#、Objective-C、Swift、Kotlin等常见开发语言。
        • 5.1.1.1.2　扫描格式
          • 产品应能够支持多种文件格式，包括：
          • a)应支持直接对目标软件的源代码文件进行分析；
          • b)应支持对目标软件的源代码编译后的二进制或字节码文件进行分析。
        • 5.1.1.1.3　导入方式
          • 产品应能够支持多种源码导入方式，包括：
          • a)应支持本地上传源码包（包括 RAR、Zip 、GZ等压缩文件格式）；
          • b)应支持代码仓库（包括但不限于 GIT、SVN 等）拉取源码；
          • c)应支持通过共享文件、FTP传输等方式导入源码。
        • 5.1.1.1.4　扫描配置
          • 产品能够适应和匹配不同的分析场景，提供灵活的扫描配置信息，包括：
          • a)应支持设定源代码增量扫描配置；
          • b)应支持设定定时扫描配置；
          • c)应支持设定扫描规则模板配置。
      • 5.1.1.2　软件基本信息分析
        • 产品应支持分析目标软件代码包含的基本信息，包括代码语言、代码文件数量、文件大小、代码行数、注释行数、空白行数等信息。
    • 5.1.2　缺陷检测
      • 5.1.2.1　缺陷类型支持
        • 产品应支持常见代码缺陷检测，类型覆盖国内外主流安全标准和质量规范，包括：
        • a)应支持CWE TOP 25和OWASP TOP 10标准；
        • b)应支持GB/T 38674-2020 信息安全技术 应用软件安全编程指南;
        • c)应支持 GB/T 34944-2017 Java语言源代码缺陷测试规范；
        • d)应支持 GB/T 34943-2017 C/C++语言源代码缺陷测试规范。
      • 5.1.2.2　误报率和漏报率
        • 产品应支持较低的误报率和漏报率，包括
        • a)产品误报率是指使用产品扫描分析同一测试项，出现安全缺陷误报率比例宜不超过50%；
        • b)产品漏报率是使用产品扫描分析同一测试项，出现安全缺陷漏报率比例宜不超过50%。
    • 5.1.3　分析结果处理
      • 5.1.3.1　统计分析
        • 5.1.3.1.1　结果查看
          • 产品应提供缺陷结果浏览和检索功能。
        • 5.1.3.1.2　统计数据展示
          • 产品应支持缺陷统计展示，包括：
          • a)应提供数据统计分析功能，包括但不限于缺陷类型统计、缺陷数量统计、源代码信息统计、缺陷风险等级统计；
          • b)应支持对分析结果进行图形化展示，包括但不限于自定义时间段的缺陷统计图展示；
          • c)应支持图形化展示多次扫描的对比结果。
      • 5.1.3.2　结果审计
        • 5.1.3.2.1　缺陷说明
          • 产品应提供缺陷相关的说明信息，包括：
          • a)应提供缺陷的描述或常见的攻击方式；
          • b)应提供缺陷的修复建议和示例代码。
        • 5.1.3.2.2　缺陷审计
          • 产品应支持对分析结果进行审计，包括：
          • a)应支持对缺陷进行审计操作，可标记状态包括但不限于已忽略、已确认和已修复；
          • b)应支持展示污点数据流的传递过程；
          • c)应支持查看缺陷代码行及上下文；
          • d)应提供缺陷验证信息，包括但不限于污点参数、缺陷路径等。
        • 5.1.3.2.3　审计日志
          • 应支持生成详细的审计日志，包含扫描参数、审计结果、审计人员的操作等关键信息。
      • 5.1.3.3　报告生成与导出
        • 5.1.3.3.1　报告生成
          • 产品应支持根据分析结果生成相应的报告，报告要求展示各项风险检测的汇总结果，生成各类风险的摘要信息，包括风险描述、风险严重程度分级、处置建议等。
        • 5.1.3.3.2　报告管理
          • 产品应支持报告管理，包括报告导出内容自定义和报告删除。
        • 5.1.3.3.3　报告导出
          • 产品应支持通用格式报告导出，包括但不限于PDF、DOC、HTML、EXCEL等。
    • 5.1.4　策略及配置管理
      • 5.1.4.1　集成配置
        • 产品应能够进行集成配置，包括：
        • a)应支持与主流的代码仓库集成，包括但不限于：Git（GitLab、GitHub 等）、SVN 等；
        • b)应支持与主流的缺陷管理系统集成，包括但不限于：Atlassian Jira、禅道等；
        • c)应支持与主流 IDE 开发工具进行集成，包括但不限于：Jetbrains IDEA、Visual Studio Code、Eclipse 等；
        • d)应支持与主流 CI/CD 工具集成，包括但不限于：Jenkins、GitLab-CI等；
        • e)应支持与主流的对接登录集成，如LDAP等；
        • f)应支持与主流的消息通知工具集成，如邮箱等；
        • g)应支持提供二次开发接口，可提供接口规范文档。
      • 5.1.4.2　策略管理
        • 产品应支持对检测策略进行管理，包括但不限于：
        • a)应支持增量检测策略配置。针对代码来源为代码仓库的检测任务，在选择增量检测后，可以只检测较上一批次检测后新增或修改的代码；
        • b)应支持定时检测策略配置。支持选择指定的时间或周期进行检测；
        • c)应支持检测超时配置。若检测任务超过设置的检测执行时间，则不再继续检测；
        • d)应支持配置源代码等敏感数据的清理策略；
        • e)应支持携带审计策略配置。在同一代码源下，支持选择是否将历史审计内容携带应用于后续的检测任务中；
        • f)应支持检测并发配置，设置同时执行检测任务的个数；
        • g)应支持查看和编辑任务队列，如删除任务、调整任务顺序等；
        • h)应支持缺陷检测策略自定义。
      • 5.1.4.3　规则管理
        • 产品应包含相关规则并能够进行管理，包括：
        • a)应支持检测规则模板的维护。包括：新建、编辑、删除、查询、导入和导出规则模板功能；
        • b)应支持函数白名单的配置。如维护函数白名单涉及的语言、函数等；
        • c)应支持配置文件路径过滤。如可选择配置路径的关键字、过滤类型、匹配方式、大小写是否敏感等；
        • d)应支持自定义规则的维护。
      • 5.1.4.4　知识库管理
        • 产品应包含知识库并能够进行管理：
        • a)应具备知识库在线或离线更新能力；
        • b)应支持对知识库中内容的检索和分类浏览。应支持浏览知识库的具体内容，如：缺陷描述、常见的攻击方式、修复建议、示例代码等；
        • c)应支持的对知识库中内容进行编辑。
  • 5.2　自身安全要求
    • 5.2.1　身份鉴别
      • 5.2.1.1　管理员鉴别
        • 产品应在管理员执行任何与安全功能相关的操作之前对管理员身份进行鉴别。
      • 5.2.1.2　鉴别信息要求
        • 产品应提供以下鉴别功能：
        • a）在采用基于口令的鉴别信息时，产品应对管理员设置的口令进行复杂度检查，确保管理员口令满足规定的复杂度要求；
        • b）当存在默认口令时，系统应提示管理员对默认口令进行修改，以减少用户身份被冒用的风险；
        • c）产品应提供鉴别信息定期更换功能，当鉴别信息使用时间达到使用期限阈值前，应提示管理员进行修改。
      • 5.2.1.3　鉴别失败处理
        • 当管理员鉴别尝试失败连续达到指定次数后，产品应阻止管理员进一步的鉴别请求，并将有关信息生成审计事件。最多失败次数仅由授权管理员设定。
      • 5.2.1.4　鉴别数据保护
        • 产品应保护鉴别数据不被未授权查阅和修改。
      • 5.2.1.5　超时设置
        • 产品应具有管理员登录超时重新鉴别功能，在设定的时间段内没有任何操作的情况下，锁定或终止会话，需要再次进行身份鉴别才能够重新使用产品，最大超时时间仅由授权管理员设定。
      • 5.2.1.6　管理地址限制
        • 产品应对管理员登录的地址进行限制。
      • 5.2.1.7　会话锁定
        • 产品应允许管理员锁定当前的交互会话，锁定后需要再次进行身份鉴别才能够重新管理产品。
    • 5.2.2　管理员管理
      • 5.2.2.1　标识唯一性
        • 产品应保证所设置的管理员标识全局唯一。
      • 5.2.2.2　管理员属性定义
        • 产品应为每一个管理员保存安全属性表，属性应包括:管理员标识、鉴别数据、授权信息或管理组信息、其他安全属性等。
      • 5.2.2.3　安全行为管理
        • 产品应仅允许授权管理员对产品进行功能设置、参数修改、安全策略变更，以及启用/停用等操作。
      • 5.2.2.4　管理员角色
        • 产品应能设置多个不同权限的角色，并应保证每一个角色标识是全局唯一的。
    • 5.2.3　安全审计
      • 5.2.3.1　审计日志生成
        • 产品应生成以下事件的审计日志：
        • a）管理员的登录成功和失败；
        • b）对扫描策略进行设置、修改、启用/停用等操作；
        • c）对管理员或者角色进行增加、删除和属性修改的操作；
        • d）产品应在每一个审计日志记录中记录事件发生的日期、时间、用户标识、事件描述和结果。若采用远程登录方式还应记录管理主机的IP地址。
      • 5.2.3.2　审计日志查阅
        • 产品应为授权管理员提供审计日志查阅功能，方便管理员查看审计结果。
      • 5.2.3.3　受限的审计日志查阅
        • 除了具有明确的访问权限的授权管理员之外，产品应禁止所有其他用户对审计日志的访问。
      • 5.2.3.4　可选审计查阅
        • 产品应支持按照一定条件对审计日志进行检索或排序。
    • 5.2.4　数据安全
      • 5.2.4.1　安全管理
        • 产品应能够对分析数据进行安全管理，包括：
        • a)应在分析完成后删除缓存的目标软件数据；
        • b)应采取措施保障存储数据的安全性。
      • 5.2.4.2　数据存储告警
        • 产品应在数据存储空间将耗尽等情况时,自动产生告警,产生告警的剩余存储空间大小应由管理员自主设定。
    • 5.2.5　通信安全
      • 若产品组件间通过网络进行通信,应采取措施保障传输数据的安全性。
    • 5.2.6　支撑系统安全
      • 产品的支撑系统应:
      • a) 进行必要的裁剪,不提供多余的组件或网络服务;
      • b) 重启过程中,分析任务配置和日志信息不丢失;
      • c) 不含已知中、高、超危安全漏洞。
  • 5.3　环境适应性要求
    • 5.3.1　支持多种部署架构
      • 产品应支持多种部署架构，包括:
      • a)产品应支持 C/S 架构使用，支持通过客户端发起检测任务、生成检测报告；
      • b)产品应支持 B/S 架构使用，支持通过主流浏览器访问，实现对产品的操作和管理。
    • 5.3.2　支持多种操作系统部署
      • 产品应支持基于主流操作系统部署，包括但不限于Windows、CentOS、统信、麒麟等。
    • 5.3.3　支持容器化部署
      • 产品应支持主流容器化部署，包括但不限于Docker、Kubernetes等。
    • 5.3.4　支持多种中间件兼容
      • 产品应支持多种中间件兼容，包括但不限于Tomcat、Nginx、东方通、宝兰德等。
  • 5.4　安全保障要求
    • 5.4.1　开发
      • 5.4.1.1　安全架构
        • 开发者应提供产品安全功能和自身安全保护的安全架构描述，安全架构描述应满足以下要求：
        • a)与产品设计文档中对安全功能实施抽象描述的级别一致；
        • b)描述与安全功能要求一致的静态应用安全测试系统安全功能的安全域；
        • c)描述静态应用安全测试系统安全功能初始化过程为何是安全的；
        • d)证实静态应用安全测试系统安全功能能够防止被破坏；
        • e)证实静态应用安全测试系统安全功能能够防止安全特性被旁路。
      • 5.4.1.2　功能规范
        • 开发者应提供完备的功能规范说明，功能规范说明应满足以下要求：
        • a)完全描述产品的安全功能；
        • b)描述所有安全功能接口的目的与使用方法；
        • c)标识和描述每个安全功能接口相关的所有参数；
        • d)描述安全功能接口相关的安全功能实施行为；
        • e)描述由安全功能实施行为处理而引起的直接错误消息；
        • f)证实安全功能要求到安全功能接口的追溯。
      • 5.4.1.3　产品设计
        • 开发者应提供产品设计文档，产品设计文档应满足以下要求：
        • a)根据子系统描述静态应用安全测试系统结构；
        • b)标识和描述静态应用安全测试系统安全功能的所有子系统；
        • c)描述安全功能所有子系统间的相互作用；
        • d)提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口。
    • 5.4.2　指导性文档
      • 5.4.2.1　操作用户指南
        • 开发者应提供明确和合理的操作用户指南，操作用户指南与为评估而提供的其他所有文档保持一致，对每一种用户角色的描述应满足以下要求：
        • a)描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；
        • b)描述如何以安全的方式使用静态应用安全测试系统提供的可用接口；
        • c)描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；
        • d)明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；
        • e)标识静态应用安全测试系统运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；
        • f)充分实现安全目的所必须执行的安全策略。
      • 5.4.2.2　准备程序
        • 开发者应提供产品及其准备程序，准备程序描述应满足以下要求：
        • a)描述与开发者交付程序相一致的安全接收所交付静态应用安全测试系统必需的所有步骤；
        • b)描述安全安装静态应用安全测试系统及其运行环境必需的所有步骤。 5.4.3　生命周期支持
      • 5.4.3.1　配置管理能力
        • 开发者的配置管理能力应满足以下要求：
        • a)为静态应用安全测试系统的不同版本提供唯一的标识；
        • b)使用配置管理系统对组成静态应用安全测试系统的所有配置项进行维护，并唯一标识配置项；
        • c)提供配置管理文档，配置管理文档描述用于唯一标识配置项的方法。
      • 5.4.3.2　配置管理范围
        • 开发者应提供静态应用安全测试系统配置项列表，并说明配置项的开发者。配置项列表至少包含产品、安全保障要求的评估证据和产品的组成部分。
      • 5.4.3.3　交付程序
        • 开发者应使用一定的交付程序交付静态应用安全测试系统，并将交付过程文档化。在给用户方交付静态应用安全测试系统的各版本时，交付文档应描述为维护安全所必需的所有程序。
    • 5.4.4　测试
      • 5.4.4.1　覆盖
        • 开发者应提供测试覆盖文档，测试覆盖描述应表明测试文档中所标识的测试与功能规范中所描述的静态应用安全测试系统的安全功能间的对应性。
      • 5.4.4.2　功能测试
        • 开发者应测试产品安全功能，将结果文档化并提供测试文档。测试文档应包括以下内容：
        • a)测试计划，标识要执行的测试，并描述执行每个测试的方案，这些方案包括对于其它测试结果的任何顺序依赖性；
        • b)预期的测试结果，表明测试成功后的预期输出；
        • c)实际测试结果和预期的测试结果一致。
      • 5.4.4.3　独立测试
        • 开发者应提供一组与其自测安全功能时使用的同等资源，以用于安全功能的抽样测试。
    • 5.4.5　脆弱性评定
      • 基于已标识的潜在脆弱性，产品能够抵抗具有基本攻击潜力攻击者的攻击。
• 6　测试评价方法
  • 6.1　测试环境
    • 静态应用安全测试系统功能测试评价的典型网络拓扑结构如图 2 所示：
    • 测试设备包括所需的交换机/路由器、代码仓库、缺陷管理系统、私服仓库、CI/CD 平台，以及静态应用安全测试系统的管理客户端和服务端。其中，产品管理客户端应安装有主流浏览器、IDE插件、以及客户端分析工具；产品服务端应准备不同CPU架构、操作系统的多套环境；代码仓库、私服仓库应准备好待测源代码、制品等。
  • 6.2　安全功能要求
    • 6.2.1　识别分析
      • 6.2.1.1　软件识别
        • 6.2.1.1.1　开发语言
          • a)测试方法：
            • 1)按照5.1.1.1.1中要求准备各开发语言的软件代码测识样本；
            • 2)根据产品说明书设置分析策略，使用产品对目标软件进行缺陷分析；
            • 3)检查是否支持从目标软件的开发语言中识别代码缺陷。
          • b)预期结果：
            • 1)应支持从C/C++、Java/Jsp、JavaScript、Python等开发语言中识别代码风险缺陷；
            • 2)应支持从Go、PHP、C#、Objective-C、Swift、Kotlin等开发语言中识别代码风险缺陷。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.2.1.1.2　扫描格式
          • a)测试方法：
            • 1)准备软件代码样本，包括源代码和代码编译后的文件（如字节码文件）；
            • 2)根据产品说明书设置分析策略，使用产品对目标软件代码进行缺陷分析；
            • 3)检查是否支持从目标软件的不同格式中识别代码缺陷。
          • b)预期结果：
            • 1)应支持直接对目标软件的源代码文件进行分析；
            • 2)支持对目标软件的源代码编译后的二进制或字节码文件进行分析。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.2.1.1.3　导入方式
          • a)测试方法：
            • 1)准备软件代码样本，并按照5.1.1.1.3中的要求提供测试代码源，包括RAR、Zip、GZ等压缩格式测试代码包文件，存有测试代码样本的代码仓库信息、共享文件地址、ftp服务地址等；
            • 2)根据产品说明书设置代码导入方式，使用产品对目标软件代码进行缺陷分析。
          • b)检查是否支持从预期结果：
            • 1)应支持本地上传源码包（包括 RAR、Zip、GZ等压缩文件格式）；
            • 2)应支持代码仓库（包括但不限于 GIT、SVN 等）拉取源码；
            • 3)应支持通过共享文件、FTP传输等方式导入源码。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.2.1.1.4　扫描配置
          • a)测试方法：
            • 1)准备软件代码样本；
            • 2)根据产品说明书设置5.1.1.1.4要求的扫描配置信息，使用产品对目标软件代码进行缺陷分析。
          • b)检查是否支持从预期结果：
            • 1)应支持设定源代码增量扫描配置；
            • 2)应支持设定定时扫描配置；
            • 3)应支持设定扫描规则模板配置。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.2.1.2　软件基本信息分析
        • a)测试方法：
          • 1)准备软件代码样本；
          • 2)根据产品说明书设置分析策略，使用产品对目标软件进行缺陷分析。
        • b)检查是否支持从预期结果：
          • 产品应支持分析目标软件代码包含的基本信息，包括代码语言、代码文件数量、文件大小、代码行数、注释行数、空白行数等信息内容。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.2.2　缺陷检测
      • 6.2.2.1　缺陷类型支持
        • 缺陷类型支持的测试评价方法如下所示。
        • a)测试方法：
          • 1)准备包含5.1.2.1中描述的各类代码缺陷的软件代码样本；
          • 2)根据产品说明书使用产品对软件代码样本进行检测；
          • 3)检查是否支持检测5.1.2.1中的各类安全缺陷。
        • b)预期结果：
          • 产品能够检出所有样本中存在的代码缺陷。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.2.2.2　误报率和漏报率
        • 误报率和漏报率的测试评价标准如下所示。
          • a)测试方法：
            • 1)准备已知缺陷总数的软件代码样本；
            • 2)根据产品说明书设置分析策略，使用产品对目标软件进行成分识别；
            • 3)依据检测结果计算产品针对当前代码样本的误报率和漏报率，其中误报率计算方式是指扫描结果中误报的缺陷占到所有检出缺陷数量的比率：(误报的缺陷数量 / 所有扫描结果中的缺陷总数) * 100%；漏报率计算方式是指扫描结果未包含的真实缺陷占到所有缺陷数量的比率： (未发现的缺陷数量 / 所有真实的缺陷总数) * 100%。
          • b)检查是否支持从预期结果：
            • 1)产品误报率是指使用产品扫描分析同一测试项，出现安全缺陷误报率比例宜不超过50%；
            • 2)产品漏报率是使用产品扫描分析同一测试项，出现安全缺陷漏报率比例宜不超过50%。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.2.3　分析结果处理
      • 6.2.3.1　统计分析
        • 6.2.3.1.1　结果查看
          • 结果查看的测试评价方法如下所示。
          • a)测试方法：
            • 1）上传包含缺陷的软件代码样本；
            • 2）根据产品说明书设置检测策略，使用产品对目标进行检测分析；
            • 3）检测完成后，检查产品是否提供对检测结果的浏览功能；
            • 4）使用模糊搜索或组合搜索等方式，检查产品是否能根据搜索条件查询检测结果。
          • b)预期结果：
            • 产品提供检测结果浏览和查询功能。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
        • 6.2.3.1.2　统计数据展示
          • 统计数据展示的测试评价方法如下所示。
          • a)测试方法：
            • 1）根据产品说明书，查看统计分析结果；
            • 2）检查统计分析结果是否可以展示自定义时间段的缺陷统计图；
            • 3）检查统计分析结果是否包含缺陷类型统计、缺陷数量统计、源代码信息统计、缺陷风险等级统计信息；
            • 4）检查统计分析结果是否可以展示多次扫描的对比结果。
          • b)预期结果：
            • 1）产品提供统计分析功能；
            • 2）统计分析结果可以展示自定义时间段的缺陷统计图；
            • 3）统计分析结果中包含缺陷类型统计、缺陷数量统计、源代码信息统计、缺陷风险等级统计信息；
            • 4）统计分析结果可以展示多次扫描的对比结果。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.2.3.2　结果审计
        • 6.2.3.2.1　缺陷说明
          • 缺陷说明的测试评价方法如下所示。
          • a)测试方法：
            • 1）上传包含缺陷的软件代码样本，进行检测分析；
            • 2）根据产品说明书，检查检测结果中的缺陷内容；
            • 3）检查结果中是否包含缺陷的描述或常见的攻击方式；
            • 4）检查结果中是否包含缺陷的修复建议和示例代码。
          • b)预期结果：
            • 1）检测结果中包含缺陷的描述或常见的攻击方式；
            • 2）检测结果中包含缺陷的修复建议和示例代码。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
        • 6.2.3.2.2　缺陷审计
          • 缺陷审计的测试评价方法如下所示。
          • a)测试方法：
            • 1）上传包含缺陷的软件代码样本，进行检测分析；
            • 2）根据产品说明书，对检测结果执行审计操作；
            • 3）检查是否支持对检测结果进行已忽略、已确认和已修复等状态进行标记；
            • 4）检查是否支持展示污点数据流的传递过程；
            • 5）检查是否支持查看缺陷代码行及上下文；
            • 6）检查是否提供缺陷验证信息。
          • b)预期结果：
            • 1）产品提供结果审计功能；
            • 2）产品支持对检测结果进行已忽略、已确认和已修复等状态标记；
            • 3）产品支持展示检测结果中污点数据流的传递过程；
            • 4）产品支持查看缺陷代码行及上下文；
            • 5）提供缺陷验证信息。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
        • 6.2.3.2.3　审计日志
          • 审计日志的测试评价方法如下所示。
          • a)测试方法：
            • 1）上传包含缺陷的软件代码样本，进行检测分析；
            • 2）检查是否提供详细的审计日志，包括扫描参数、审计结果、审计人员的操作等。
          • b)预期结果：
            • 产品提供详细的审计日志，包括扫描参数、审计结果、审计人员的操作等。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.2.3.3　报告生成与导出
        • 6.2.3.3.1　报告生成
          • 报告生成的测试评价方法如下所示。
          • a)测试方法：
            • 1）根据产品说明书，检查产品是否能够生成检测结果报告；
            • 2）检查报告是否展示各项风险检测的汇总结果；
            • 3）检查报告是否生成各类风险的摘要信息，包括风险描述、风险严重程度分级、处置建议。
          • b)预期结果：
            • 能根据检测结果生成相应报告，报告包括：
            • 1）各项风险检测的汇总结果；
            • 2）生成各类风险的摘要信息；
            • 3）摘要信息内容包括风险描述、风险严重程度分级、处置建议。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
        • 6.2.3.3.2　报告管理
          • 报告管理的测试评价方法如下所示。
          • a)测试方法：
            • 1）根据产品说明书，对产品进行报告导出和删除操作；
            • 2）检查报告导出时是否能自定义报告内容；
            • 3）检查报告删除后是否还能查看到该份报告。
          • b)预期结果：
            • 1）报告导出时能够自定义选择报告内容；
            • 2）下载的报告内容与自定义内容一致；
            • 3）能够成功删除报告。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
        • 6.2.3.3.3　报告导出
          • 报告导出的测试评价方法如下所示。
          • a)测试方法：
            • 1）检查产品的报告导出方式；
            • 2）检查产品是否能够按照PDF、DOC、HTML、EXCEL等多种通用文档格式中的一种或者多种导出；
          • b)预期结果：
            • 报告能够按照PDF、DOC、HTML、EXCEL等多种通用文档格式中的一种或者多种导出。
          • c)结果判定：
            • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.2.4　策略及配置管理
      • 6.2.4.1　集成配置
        • 集成配置的测试评价方法如下所示。
        • a)测试方法：
          • 1）根据产品说明书，检查产品支持的集成配置方式；
          • 2）检查产品是否支持与主流的代码仓库集成，包括但不限于：Git（GitLab、GitHub 等）、SVN 等；
          • 3）检查产品是否支持与主流的缺陷管理系统集成，包括但不限于：Atlassian Jira、禅道等；
          • 4）检查产品是否支持与主流 IDE 开发工具进行集成，包括但不限于：Jetbrains IDEA、Visual Studio Code、Eclipse 等；
          • 5）检查产品是否支持与主流 CI/CD 工具集成，包括但不限于：Jenkins、GitLab-CI等；
          • 6）检查产品是否支持与主流的对接登录集成，如LDAP等；
          • 7）检查产品是否支持与主流的消息通知工具集成，如邮箱等；
          • 8）检查产品是否支持提供二次开发接口，提供接口规范文档。
        • b)预期结果：
          • 1)产品支持与主流的代码仓库集成，包括但不限于：Git（GitLab、GitHub 等）；
          • 2)产品支持与主流的缺陷管理系统集成，包括但不限于：Atlassian Jira、禅道等；
          • 3)产品支持与主流 IDE 开发工具进行集成，包括但不限于：Jetbrains IDEA、Visual Studio Code、Eclipse 等；
          • 4)产品支持与主流 CI/CD 工具集成，包括但不限于：Jenkins、GitLab-CI等；
          • 5)产品支持与主流的对接登录集成，如LDAP等；
          • 6)产品支持与主流的消息通知工具集成，如邮箱等；
          • 7)产品支持提供二次开发接口，提供接口规范文档。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.2.4.2　策略管理
        • 策略管理的测试评价方法如下所示。
        • a)测试方法：
          • 1）根据产品说明书，检查产品支持的策略管理方式；
          • 2）检查是否支持增量检测策略配置，针对代码来源为代码仓库的检测任务，在选择增量检测后，可以只检测较上一批次检测后新增或修改的的代码；
          • 3）检查是否支持定时检测策略配置。支持选择指定的时间或周期进行检测；
          • 4）检查是否支持检测超时配置。若检测任务超过设置的检测执行时间，则不再继续检测；
          • 5）检查是否支持配置源代码等敏感数据的清理策略；
          • 6）检查是否支持携带审计策略配置。在同一代码源下，支持选择是否将历史审计内容携带应用于后续的检测任务中；
          • 7）检查是否支持检测并发配置，设置同时执行检测任务的个数；
          • 8）检查是否支持查看和编辑任务队列，如删除任务、调整任务顺序等；
          • 9）检查产品是否支持缺陷检测策略自定义。
        • b)预期结果：
          • 1)产品支持增量检测策略配置；
          • 2)产品支持定时检测策略配置。支持选择指定的时间或周期进行检测；
          • 3)产品支持检测超时配置。若检测任务超过设置的检测执行时间，则不再继续检测；
          • 4)产品支持配置源代码等敏感数据的清理策略；
          • 5)产品支持携带审计策略配置。在同一代码源下，支持选择是否将历史审计内容携带应用于后续的检测任务中；
          • 6)产品支持检测并发配置，设置同时执行检测任务的个数；
          • 7)产品支持查看和编辑任务队列，如删除任务、调整任务顺序等；
          • 8)产品支持缺陷检测策略自定义。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.2.4.3　规则管理
        • 规则管理的测试评价方法如下所示。
        • a)测试方法
          • 1）根据产品说明书，检查产品支持的规则管理方式；
          • 2）检查产品是否支持检测规则模板的维护。包括：新建、编辑、删除、查询、导入和导出规则模板功能；
          • 3）检查产品是否支持函数白名单的配置。如维护函数白名单涉及的语言、函数等；
          • 4）检查产品是否支持配置文件路径过滤。如可选择配置路径的关键字、过滤类型、匹配方式、大小写是否敏感等；
          • 5）检查产品是否支持自定义规则的维护。
        • b)预期结果
          • 1)产品支持检测规则模板的维护。包括：新建、编辑、删除、查询、导入和导出规则模板功能；
          • 2)产品支持函数白名单的配置。如维护函数白名单涉及的语言、函数等；
          • 3)产品支持配置文件路径过滤。如可选择配置路径的关键字、过滤类型、匹配方式、大小写是否敏感等；
          • 4)产品支持自定义规则的维护。
        • c)结果判定
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.2.4.4　知识库管理
        • 知识库管理的测试评价方法如下所示。
        • a)测试方法
          • 1）根据产品说明书，检查产品支持的知识库管理方式；
          • 2）检查产品是否具备知识库在线或离线更新能力；
          • 3）检查产品是否支持对知识库中内容的检索和分类浏览。支持浏览知识库的具体内容，如：缺陷描述、常见的攻击方式、修复建议、示例代码等；
          • 4）检查产品是否支持的对知识库中内容进行编辑。
        • b)预期结果
          • 1)产品具备知识库在线或离线更新能力；
          • 2)产品支持对知识库中内容的检索和分类浏览。支持浏览知识库的具体内容，如：缺陷描述、常见的攻击方式、修复建议、示例代码等；
          • 3)产品支持的对知识库中内容进行编辑。
        • c)结果判定
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
  • 6.3　自身安全要求
    • 6.3.1　身份鉴别
      • 6.3.1.1　管理员鉴别
        • 管理员鉴别的测试评价方法如下所示。
        • a)测试方法：
          • 登录产品管理界面，检查是否在执行所有功能之前都要求首先进行身份认证。
        • b)预期结果：
          • 1）在管理员执行任何与安全功能相关的操作之前都应对管理员进行鉴别；
          • 2）登录之前允许做的操作，应仅限于输入登录信息、查看登录帮助等操作；
          • 3）允许管理员在登录后执行与其安全功能相关的各类操作时，不再重复认证。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.1.2　鉴别信息要求
        • 鉴别信息要求的测试评价方法如下所示。
        • a)测试方法：
          • 1）对采用基于口令作为鉴别信息的产品，在设置或修改管理员口令时，检查产品是否对管理员设置的口令进行复杂度检查，是否满足口令复杂度要求；
          • 2）当产品初始化存在默认口令时，检查产品是否会提示管理员对默认口令进行修改；
          • 3）检查产品是否提供鉴别信息定期更换功能，当鉴别信息使用时间达到使用期限阈值前，是否提示管理员进行修改。
        • b)预期结果：
          • 1）对采用基于口令作为鉴别信息的产品，产品支持对管理员设置的口令进行复杂度检查，确保管理员口令满足一定的复杂度要求；
          • 2）当存在默认口令时，产品应提示管理员对默认口令进行修改；
          • 3）提供鉴别信息定期更换功能，当鉴别信息使用时间达到使用期限阈值前，提示管理员进行修改。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.1.3　鉴别失败处理
        • 鉴别失败处理的测试评价方法如下所示。
        • a)测试方法：
          • 1）检查产品的安全功能是否可定义管理员鉴别尝试的最大允许失败次数；
          • 2）检查产品的安全功能是否可定义当管理员鉴别尝试失败连续达到指定次数后，采取相应的措施、阻止管理员进一步的鉴别请求；
          • 3）尝试多次失败的管理员鉴别行为，检查到达指定的鉴别失败次数后，产品是否采取了相应的措施，并生成了审计事件。
        • b)预期结果：
          • 1）产品具备定义管理员鉴别尝试的最大允许失败次数的功能；
          • 2）产品可定义当管理员鉴别尝试失败连续达到指定次数后，采取相应的措施(如锁定该账号)；
          • 3）当管理员鉴别尝试失败连续达到指定次数后，系统应锁定该账号，并将有关信息生成审计事件；
          • 4）最多失败次数仅由授权管理员设定。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.1.4　鉴别数据保护
        • 鉴别数据保护的测试评价方法如下所示。
        • a)测试方法：
          • 1）检查产品是否仅允许指定权限的管理员可查阅或修改身份鉴别数据；
          • 2）以非授权管理员的身份尝试查阅或修改身份鉴别数据。
        • b)预期结果：
          • 1）产品仅允许指定权限的管理员查阅或修改身份鉴别数据；
          • 2）非授权管理员无法查阅或修改身份鉴别数据。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.1.5　超时设置
        • 超时设置的测试评价方法如下所示。
        • a)测试方法：
          • 1）检查产品是否具有管理员登录超时重新鉴别功能；
          • 2）设定管理员登录超时重新鉴别的时间段，登录管理员后在设定的时间段内没有任何操作，检查产品是否锁定或终止了会话，管理员是否需要再次进行身份鉴别才能够重新管理和使用产品；
          • 3）检查最大超时时间是否仅由授权管理员设定。
        • b)预期结果：
          • 1）产品具有登录超时重新鉴别功能；
          • 2）任何登录管理员在设定的时间段内没有任何操作的情况下，都被锁定或终止了会话，管理员需要再次进行身份鉴别才能够重新管理和使用产品；
          • 3）最大超时时间仅由授权管理员设定。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.1.6　管理地址限制
        • 管理地址限制的测试评价方法如下所示。
        • a)测试方法：
          • 1）检查产品是否支持对管理地址进行限制，尝试以非授权范围内的地址主机登录产品管理界面；
          • 2）尝试以授权范围内地址的主机登录产品管理界面。
        • b)预期结果：
          • 1）产品应对管理员登录的地址进行限制，不能够以非授权范围内的地址登录产品管理界面；
          • 2）支持以授权范围内地址的主机登录产品管理界面。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.3.2　管理员管理
      • 6.3.2.1　标识唯一性
        • 标识唯一性的测试评价方法如下所示。
        • a)测试方法：
          • 1）尝试定义多个管理员；
          • 2）尝试添加一个已有标识的管理员；
          • 3）检查产品是否提示该标识管理员已存在，拒绝具有相同标识管理员的添加。
        • b)预期结果：
          • 1）产品应允许定义多个管理员；
          • 2）应保证每一个管理员标识是全局唯一的，不允许一个管理员标识用于多个管理员。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.2.2　管理员属性定义
        • 管理员属性定义的测试评价方法如下所示。
        • a)测试方法：
          • 定义分属于不同角色的多个管理员，检查输入的管理员信息是否都能被保存。
        • b)预期结果：
          • 产品应为每一个管理员保存其安全属性，包括：管理员标识、鉴别数据(如密码)、授权信息或管理员组信息、其他安全属性等，输入的管理员信息无丢失现象发生。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.2.3　安全行为管理
        • 安全行为管理的测试评价方法如下所示。
        • a)测试方法：
          • 1）检查产品的安全功能是否明确规定仅限于指定的授权管理员能对产品的功能进行设置修改、启用/停用等操作；
          • 2）检查指定的授权管理员对产品进行功能设置、参数修改、安全策略变更，以及启用/停用等操作前，是否应先登录才能操作。
        • b)预期结果：
          • 1）产品仅限于指定授权管理员才能对产品进行功能设置、参数修改、安全策略变更，以及启用/停用等操作；
          • 2）指定的授权管理员对产品进行功能设置、参数修改、安全策略变更，以及启用/停用等操作前，都应先通过身份鉴别。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.2.4　管理员角色
        • 管理员角色的测试评价方法如下所示。
        • a)测试方法：
          • 检查产品的安全功能是否允许定义多个不同权限的角色。
        • b)预期结果：
          • 1）产品允许定义多个不同权限的角色；
          • 2）每个角色可以具有多个管理员，每个管理员只能属于一个角色；
          • 3）保证每一个角色标识是全局唯一的，不允许一个角色标识用于多个角色。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.3.3　安全审计
      • 6.3.3.1　审计日志生成
        • 审计日志生成的测试评价方法如下所示。
        • a)测试方法：
          • 1）尝试进行 5.2.1.3.1 要求的各项操作，触发审计事件；
          • 2）查看审计日志是否包括事件发生的日期、时间、用户标识、事件描述和结果；
          • 3）若产品支持远程管理，查看审计日志是否记录管理主机的 IP 地址。
        • b)预期结果：
          • 1）产品能够针对上述事件生成审计日志，日志内容包括事件发生的日期、时间、用户标识、事件描述和结果；
          • 2）当产品支持远程管理时，审计日志能够记录管理主机的 IP 地址。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.3.2　审计日志查阅
        • 审计日志查阅的测试评价方法如下所示。
        • a)测试方法：
          • 1）以授权管理员身份尝试从审计日志中读取全部审计信息；
          • 2）检查产品是否为授权管理员提供从审计日志中读取全部审计信息的功能。
        • b)预期结果：
          • 产品为授权管理员提供从审计日志中读取全部审计信息的功能。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.3.3　受限的审计日志查阅
        • 受限的审计日志查阅的测试评价方法如下所示。
        • a)测试方法：
          • 分别模拟授权与非授权管理员访问审计日志，检查产品安全功能是否仅允许授权管理员访问。
        • b)预期结果：
          • 产品限制审计日志的访问。除了具有明确访问权限的授权管理员之外，禁止所有其他用户对审计日志的访问。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
      • 6.3.3.4　可选审计查阅
        • 可选审计查阅的测试评价方法如下所示。
        • a)测试方法：
          • 检查产品是否能够支持按照一定条件，包括但不限于时间、主体、客体等对审计日志进行检索或排序。
        • b)预期结果：
          • 产品支持按照一定条件对审计日志进行检索或排序。
        • c)结果判定：
          • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.3.4　数据安全
      • 6.3.4.1　安全管理
        • 安全管理的测试评价方法如下所示。
        • a)测试方法：
          • 1)根据产品说明手册，检查产品的数据安全管理措施；
          • 2)检查产品是否在分析完成后删除缓存的目标软件数据；
          • 3)检查产品是否采取措施保障存储数据的安全性。
        • b)预期结果:
          • 1)产品在分析完成后删除缓存的目标软件数据；
          • 2)产品采取了措施保障存储数据的安全性。
        • c)结果判定:
          • 上述预期结果均满足判定为符合,其他情况判定为不符合。
      • 6.3.4.2　数据存储告警
        • 数据存储告警的测试评价方法如下所示。
        • a)测试方法：
          • 1)检查产品安全功能是否具有存储剩余空间将耗尽的告警功能；
          • 2)检查产品安全功能是否允许管理员设定产生告警的的剩余存储空间的大小；
          • 3)人为地将产品存储器空间耗至设定的告警值以下,检查产品是否告警。
        • b)预期结果：
          • 1)产品在发生数据存器空间将耗尽的情况时,自动产生告警;
          • 2)允许管理员设定产生告警的剩余存储空间的大小。
        • c)结果判定：
          • 上述预期结果均满足判定为符合,其他情况判定为不符合。
    • 6.3.5　通信安全
      • 通信安全的测评方法如下所示。
      • a)测试方法：
        • 1)检查开发者文档中对保证产品各组件之间通信保密性的描述；
        • 2)使用网络协议分析工具抓取产品各组件中传输的配置和控制信息,检查是否具备保密措施。
      • b)预期结果：
        • 1)开发者文档中提供了为保证产品各组件之间通信保密性所采取措施的详细描述,列举系统为保证通信保密性所采取的措施;
        • 2)分析抓包结果,系统在各组件之间传输数据时采取了一定的保密措施。
      • c)结果判定：
        • 上述预期结果均满足判定为符合,其他情况判定为不符合。
    • 6.3.6　支撑系统安全
      • 对支撑系统安全的测评方法如下所示。
      • a)测试方法：
        • 1)查看开发者文档,并验证产品的支撑系统是否进行了必要的裁剪,是否不提供多余的组件或网络服务;
        • 2)重启系统,验证扫描任务的配置和日志信息是否不丢失;
        • 3)对系统进行安全性测试,验证是否不含已知的中、高、超危安全漏洞。
      • b)测试方法：
        • 1)产品支撑系统进行了必要的裁剪,不提供多余的组件或限网络服务;
        • 2)重启过程中,安全扫描任务的配置和日志信息不丢失;
        • 3)系统不含已知中、高、超危安全漏洞。
      • c)测试方法：
        • 上述预期结果均满足判定为符合,其他情况判定为不符合。
  • 6.4　环境适应性要求
    • 6.4.1　支持多种部署架构
      • 支持多种部署架构测试评价方法如下所示。
      • a)测试方法：
        • 1）根据产品说明书，检查产品支持的部署架构；
        • 2）检查产品是否支持以 C/S 架构部署使用；
        • 3）检查产品客户端是否支持发起检测任务并生成相关报告；
        • 4）检查产品是否支持以 B/S 架构部署使用；
        • 5）检查产品是否支持通过 Google Chrome、Firefox、Microsoft Edge 等主流浏览器访问、操作和管理。
      • b)预期结果
        • 1）产品支持以 C/S 架构部署和使用；
        • 2）产品客户端支持发起检测任务并生成相关报告；
        • 3）产品支持以 B/S 架构部署使用；
        • 4）产品支持通过上述浏览器访问、操作和管理。
      • c)结果
        • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.4.2　支持多种操作系统部署
      • 支持多种操作系统部署测试评价方法如下所示。
      • a)测试方法：
        • 1）根据产品说明书，检查产品支持部署的操作系统；
        • 2）检查产品是否支持基于主流操作系统部署。
      • b)预期结果
        • 1）产品支持基于主流操作系统部署，包括但不限于Windows、CentOS、统信、麒麟等；
      • c)结果
        • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.4.3　支持容器化部署
      • 支持容器化部署测试评价方法如下所示。
      • a)测试方法：
        • 1）根据产品说明书，检查产品是否支持容器化部署；
        • 2）检查产品是否支持主流容器化部署。
      • b)预期结果
        • 1）产品支持主流容器化部署，包括但不限于Docker、Kubernetes等；
      • c)结果
        • 上述预期结果均满足判定为符合，其他情况判定为不符合。
    • 6.4.4　支持多种中间件兼容
      • 支持容器化部署测试评价方法如下所示。
      • a)测试方法：
        • 1）根据产品说明书，检查产品是否支持中间件兼容；
        • 2）检查产品是否支持多种中间件的兼容。
      • b)预期结果
        • 产品支持多种中间件的兼容，包括但不限于Tomcat、Nginx、东方通、宝兰德等；
      • c)结果
        • 上述预期结果均满足判定为符合，其他情况判定为不符合。
  • 6.5　安全保障要求
    • 6.5.1　开发
      • 6.5.1.1　安全架构
        • 安全架构的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下安全架构的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）与产品设计文档中对安全功能实施抽象描述的级别一致；
          • 2）描述与安全功能要求一致的静态应用安全测试系统安全功能的安全域；
          • 3）描述静态应用安全测试系统安全功能初始化过程为何是安全的；
          • 4）证实静态应用安全测试系统安全功能能够防止被破坏；
          • 5）证实静态应用安全测试系统安全功能能够防止安全特性被旁路。
        • b)预期结果：
          • 开发者提供的文档内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
        • 6.5.1.2　功能规范
          • 功能规范的测试评价方法如下所示。
          • a)测试方法：
            • 检查开发者是否提供以下功能规范的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
            • 1）完全描述静态应用安全测试系统的安全功能；
            • 2）描述所有安全功能接口的目的与使用方法；
            • 3）标识和描述每个安全功能接口相关的所有参数；
            • 4）描述安全功能接口相关的安全功能实施行为；
            • 5）描述由安全功能实施行为处理而引起的直接错误消息；
            • 6）证实安全功能要求到安全功能接口的追溯。
          • b)预期结果：
            • 开发者提供的文档内容应满足上述要求。
          • c)结果判定：
            • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.5.1.3　产品设计
        • 产品设计的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下产品设计的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）根据子系统描述静态应用安全测试系统结构；
          • 2）标识和描述静态应用安全测试系统安全功能的所有子系统；
          • 3）描述安全功能所有子系统间的相互作用；
          • 4）提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口。
        • b)预期结果：
          • 开发者提供的文档内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.5.2　指导性文档
      • 6.5.2.1　操作用户指南
        • 操作用户指南的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下操作用户指南的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；
          • 2）描述如何以安全的方式使用静态应用安全测试系统提供的可用接口；
          • 3）描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；
          • 4）明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；
          • 5）标识静态应用安全测试系统运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；
          • 6）充分实现安全目的所必须执行的安全策略。
        • b)预期结果：
          • 开发者提供的文档内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.5.2.2　准备程序
        • 准备程序的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下准备程序的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）描述与开发者交付程序相一致的安全接收所交付静态应用安全测试系统必需的所有步骤；
          • 2）描述安全安装静态应用安全测试系统及其运行环境必需的所有步骤。
        • b)预期结果：
          • 开发者提供的文档内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.5.3　生命周期支持
      • 6.5.3.1　配置管理能力
        • 配置管理能力的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下配置管理能力的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）审查开发者是否为不同版本的静态应用安全测试系统提供唯一的标识；
          • 2）现场检查配置管理系统是否对所有的配置项做出唯一的标识，且配置管理系统是否对配置项进行了维护；
          • 3）审查开发者提供的配置管理文档，是否描述了对配置项进行唯一标识的方法。
        • b)预期结果：
          • 开发者提供的文档和现场活动证据内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.5.3.2　配置管理范围
        • 配置管理范围的测试评级方法如下所示。
        • a)评估方法：
          • 检查开发者是否提供以下配置管理范围的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）审查开发者提供的配置项列表；
          • 2）配置项列表是否描述了组成静态应用安全测试系统的全部配置项及相应的开发者。
        • b)预期结果：
          • 开发者提供的文档和现场活动证据内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.5.3.3　交付程序
        • 交付程序的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下交付程序的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）现场检查开发者是否使用一定的交付程序交付静态应用安全测试系统；
          • 2）审查开发者是否使用文档描述交付过程，文档中是否包含以下内容：在给用户方交付系统的各版本时，为维护安全所必需的所有程序。
        • b)预期结果：
          • 开发者提供的文档和现场活动证据内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.5.4　测试
      • 6.5.4.1　覆盖
        • 测试覆盖的测试评价方法如下所示。
        • a)测试方法：
          • 审查开发者提供的测试覆盖文档，在测试覆盖证据中，是否表明测试文档中所标识的测试与功能规范中所描述的静态应用安全测试系统的安全功能是对应的。
        • b)预期结果：
          • 开发者提供的文档内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.5.4.2　功能测试
        • 功能测试的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下功能测试的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）审查开发者提供的测试文档，是否包括测试计划、预期的测试结果和实际测试结果；
          • 2）审查测试计划是否标识了要测试的安全功能，是否描述了每个安全功能的测试方案（包括对其它测试结果的顺序依赖性）；
          • 3）审查期望的测试结果是否表明测试成功后的预期输出；
          • 4）审查实际测试结果是否表明每个被测试的安全功能能按照规定进行运作。
        • b)预期结果：
          • 开发者提供的文档内容应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
      • 6.5.4.3　独立测试
        • 独立测试的测试评价方法如下所示。
        • a)测试方法：
          • 检查开发者是否提供以下独立测试的证据,并检查开发者提供的信息是否满足证据的内容和形式的所有要求：
          • 1）开发者提供的测试资源；
          • 2）开发者提供的测试集合是否与其自测系统功能时使用的测试集合相一致。
        • b)预期结果：
          • 开发者提供的资源应满足上述要求。
        • c)结果判定：
          • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
    • 6.5.5　脆弱性评定
      • 脆弱性评定的测试评价方法如下所示。
      • a)测试方法：
        • 从用户可能破坏安全策略的明显途径出发，按照安全机制定义的安全强度级别，对静态应用安全测试系统进行脆弱性分析。
      • b)预期结果：
        • 渗透性测试结果应表明静态应用安全测试系统能够抵抗具有基本攻击潜力攻击者的攻击。
      • c)结果判定：
        • 实际测试结果与预期结果一致则判定为符合，其他情况判定为不符合。
• 附录A
• 附录B
  • 表 B2质量缺陷检测类别和名称
  • 表 B2安全缺陷检测类别和名称
• 参考文献
  • [1]GB/T 20220164-T-469 信息安全技术 软件供应链安全要求.
  • [2]GB/T 25069—2022 信息安全技术 术语
  • [3]GB/T 34943—2017 C/C++语言代码漏洞测试规范
  • [4]GB/T 39494—2017 Java语言源代码漏洞测试规范