一、安全测试指标与测量目标
在风险分析和管理流程中，有效运用安全测试数据的前提是准确定义安全测试指标和测量目标。例如，通过统计安全测试中发现的漏洞总数，能够量化应用程序的安全状态，还可据此设定软件安全测试的目标，如在应用程序投入生产环境前，将漏洞数量降低至可接受的最低限度。
另一个具有管理价值的目标是将应用程序的安全状态与安全基线进行对比，以此评估应用安全流程的改进情况。假设安全指标基线对应的是仅完成渗透测试的应用程序，那么经过编码期间安全测试的应用程序所呈现的安全数据，应体现出优于该基线的改进，比如漏洞数量更少。在传统软件测试中，软件缺陷数量（如应用程序中的 Bug 数量）可衡量软件质量。同理，安全测试能够提供软件安全性的量化指标。从缺陷管理和报告的角度来看，软件质量测试和安全测试可采用类似的分类方法，以确定问题的根本原因以及修复缺陷所需的投入。根本原因方面，安全缺陷可能源于设计缺陷或编码错误；从修复工作的衡量维度来看，安全和质量缺陷均可依据开发人员修复所需的时间、使用的工具和资源以及成本来评估。
与质量数据不同，安全测试数据的独特之处在于依据威胁、漏洞暴露程度以及漏洞被利用后可能产生的影响来进行风险分类。应用程序的安全性测试属于技术风险管理的范畴，旨在确保应用程序所采取的安全对策达到可接受水平。因此，安全测试数据需支撑软件开发生命周期（SDLC）关键检查点的安全风险策略。举例来说，通过源代码分析发现的漏洞是风险的初步度量，可进一步结合漏洞的暴露程度、可能性因子，并借助渗透测试验证来计算风险值（如高、中、低）。与安全测试漏洞相关的风险指标，能为管理层的风险管理决策提供支持，如决定对组织内不同级别（业务和技术风险）的风险采取接受、缓解或转移措施。
评估应用程序安全状态时，应用程序规模是一个重要考量因素。统计表明，应用程序规模与测试期间发现的问题数量相关，规模较大的应用程序更应频繁进行测试，以减少问题的出现。当在 SDLC 的多个阶段开展安全测试时，测试数据能够体现安全测试在漏洞引入后及时检测的能力，以及在不同检查点实施对策消除漏洞的有效性。这种测量被定义为 "遏制指标"，它有助于在开发的每个阶段进行安全评估，维持各阶段的安全性，同时也是降低漏洞修复成本的关键因素，因为在同一阶段修复漏洞的成本通常低于在后续阶段修复。
将安全测试指标与具体、有时限的目标相关联，可支持安全风险、成本和缺陷管理分析，例如将漏洞总量降低 30％，或在截止日期（如 Beta 版本发布前）前修复安全问题。安全测试数据既可以是绝对数值，如手动代码审查期间检测到的漏洞数量；也可以是相对数据，如代码审查与渗透测试检测到的漏洞数量对比。为评估安全流程质量，确定合理的可接受基线和良好基线至关重要。安全测试数据还能服务于特定的安全分析目标，包括遵守安全法规和信息安全标准、管理安全流程、识别安全问题的根本原因并推动流程改进，以及进行安全成本效益分析。
若要报告安全测试数据，必须提供相关指标以支持分析。分析的目的在于解读测试数据，挖掘所开发软件的安全性以及流程有效性的线索，例如：漏洞数量是否已降低至新版发布可接受的水平？
该产品的安全质量与同类软件产品相比表现如何？
所有安全测试要求是否均已满足？
安全问题的主要根本原因是什么？
安全缺陷与安全 Bug 的数量对比情况如何？
哪种安全活动在发现漏洞方面最为有效？
哪个团队在修复安全缺陷和漏洞方面效率更高？
高风险漏洞在所有漏洞中的占比是多少？
哪些工具在检测安全漏洞方面效果最佳？
哪种安全测试（如白盒测试与黑盒测试）对发现漏洞最有效？
代码安全审查过程中发现了多少安全问题？
安全设计审查过程中发现了多少安全问题？
为依据测试数据做出合理判断，深入了解测试过程和测试工具至关重要。需根据工具特点进行分类，选择合适的安全工具，因为不同工具擅长检测不同制品中的常见已知漏洞。需注意，安全测试无法检测未知的安全问题，测试未发现问题也不能证明软件或应用程序绝对安全。自动化工具虽强大，但无法替代经验丰富的安全测试人员。单纯依赖自动化工具的测试结果可能导致安全从业者产生错误的安全感。一般而言，安全测试人员对测试方法和工具的经验越丰富，安全测试和分析的结果就越可靠。因此，管理者不仅要投资安全测试工具，还应重视招聘熟练的专业人员并开展安全测试培训。二、报告要求
应用程序的安全状态可从多个角度进行表征，从效果层面看，可通过漏洞数量和风险评级体现；从原因角度分析，则可归因于编码错误、架构缺陷和配置问题等。漏洞分类可依据多种标准，其中通用漏洞评分系统 (CVSS) 是最常用的漏洞严重性指标，由事件响应和安全团队论坛 (FIRST) 维护。报告安全测试数据的最佳实践是包含以下信息：按漏洞类型分类的详细信息；
每个安全问题所面临的安全威胁；
每个安全问题的根本原因，如 Bug 或缺陷；
用于发现安全问题的测试技术；
每个漏洞的修复方法或应对策略；
每个漏洞的严重性等级（如高、中、低或 CVSS 得分）。
通过描述安全威胁，可评估安全控制措施对威胁的缓解效果。报告问题的根本原因有助于确定需要修复的具体内容，例如白盒测试中发现的漏洞，其根本原因通常是存在问题的源代码。
报告问题后，为软件开发人员提供重新测试和查找漏洞的指导也很关键，这可能涉及使用白盒测试技术（如静态代码分析器进行代码安全审查）来检查代码是否存在安全隐患。若漏洞可通过黑盒渗透测试发现，测试报告还应提供验证漏洞向客户端等前端暴露情况的信息。修复漏洞的信息应足够详细，为开发人员提供安全编码示例、配置更改说明以及充足的参考资料。严重性评级对于计算风险评级和确定修复工作优先级具有重要意义，通常，漏洞的风险评级需基于影响和暴露等因素进行外部风险分析。三、业务用例
安全测试指标要发挥实际作用，需为组织内的安全测试数据利益相关者提供价值。利益相关者包括项目经理、开发人员、信息安全办公室、审计员和首席信息官等。软件开发人员可通过安全测试数据验证软件编码的安全性和有效性，从而有动力使用源代码分析工具、遵循安全编码标准并参加软件安全培训。项目经理期望获得的数据能够帮助他们依据项目计划，成功管理和调配安全测试活动与资源。安全测试数据可显示项目是否按计划推进、是否朝着交付目标前进，以及测试过程中项目状态是否持续改善。对于信息安全官员 (ISO) 而言，安全测试数据可支持其推动安全测试业务用例，例如证明 SDLC 期间的安全测试不仅不会影响项目交付，还能减少后期生产阶段修复漏洞的总体工作量。合规性审核员可借助安全测试指标，获得一定程度的软件安全保证，确认组织通过安全评审流程满足了安全标准的合规性要求。首席信息官 (CIO) 和首席信息安全官 (CISO) 负责分配安全资源预算，他们可从安全测试数据中进行成本效益分析，以便就投资哪些安全活动和工具做出明智决策。安全投资回报率 (ROI) 是支持此类分析的重要指标之一，要得出该指标，需量化漏洞暴露风险与安全测试缓解风险的有效性之间的差距，并结合安全测试活动或工具的成本进行考量。四、总结
1.安全测试指标与测量：定义安全测试指标和测量目标是利用安全测试数据的基础。如漏洞总数可量化安全状态、设定安全目标，还可与安全基线对比评估安全流程改进。安全测试与质量测试在缺陷管理上有相似性，但安全测试数据按威胁、漏洞暴露程度等分类确定风险。评估安全状态要考虑应用规模，SDLC 多阶段测试的 "遏制指标" 可体现测试能力和漏洞消除有效性，关联具体目标可支持管理分析，测试数据分绝对和相对两种，确定基线对评估安全流程质量很重要，测试还服务于多种安全分析目标。
2.报告要求：应用程序安全状态可从效果和原因表征，漏洞常用 CVSS 分类。报告安全测试数据应包含漏洞类型、威胁、根本原因、测试技术、修复方式、严重性等级等信息，描述威胁可评估安全控制效果，报告根本原因和提供重测指导有助于修复，修复信息要详细，严重性评级影响风险评级和修复优先级。
3.业务用例：安全测试指标要为利益相关者（项目经理、开发人员、ISO、审核员、CIO 和 CISO 等）提供价值。开发人员用数据验证编码安全，项目经理用数据管理资源和推进项目，ISO 用数据证明测试对项目的积极影响，审核员用指标确认合规性，CIO 和 CISO 用数据做成本效益分析和投资决策。