从使用“发现的收集数据风险”作为关键绩效指标，转向使用“补救的风险风险”作为衡量成功的真正标准
 ，这一变化改变了安全团队的到实低风激励机制
，促使他们专注于风险补救。际降为了在规模上实现这一点  ，收集数据企业必须在降低风险方面摆脱“救火”模式——这意味着他们必须停止追逐最新的风险关键问题--并变得更加积极主动。

以下是到实低风你可以采取的七个步骤，将你现有的际降漏洞和风险管理流程和工作流程从消防转变为主动管理大规模风险降低。

对你的源码库收集数据安全测试工具采用基于调查结果的方法意味着你的典型补救过程从登录到每个工具的仪表板开始。当然，风险这需要学习每个工具的到实低风不同功能，并理解每个工具的际降调查结果语言。

要过渡到基于修复的收集数据方法 ，请从创建单个待办事项开始
。风险第一步是到实低风将来自所有测试工具的所有结果收集到一个集中位置，无论是源码下载电子表格、数据库还是其他系统
。

现在你有了单一的积压 ，向前迈进一步 
，将所有调查结果标准化
，以便它们使用统一的术语 ，从而使你能够统一地执行你的补救流程
。毕竟
，如果你想衡量结果，你需要对所有发现执行相同的过程。服务器租用这一标准化的积压调查结果现在是所有后续活动的支柱
。

你将看到你现在标准化的列表有重复的发现。删除多余的内容以缩短积压工作的长度。

标准化列表还使你能够识别影响同一资源的不同调查结果
。在这一点上，你应该用所有权背景来丰富调查结果，这是你未来需要的模板下载
。例如 ，从配置管理数据库(CMDB)收集元数据 ，以在以后分析谁拥有易受攻击的计算机 。

所有调查结果标准化后 ，你现在可以选择如何通过多维优先排序方法进行补救，其中包括
：

A.内容 ：选择是要根据外部上下文(例如，已知的自然漏洞利用)还是根据内部上下文(例如 ，它所在的域-云、香港云服务器代码等)来确定发现的优先级。

B.谁 ：选择补救项目的发送对象 。要确定合适的团队 ，请分析你在步骤2中收集的资源元数据 。

C.如何：通过围绕补救行动进行汇总
，确定结果而不是问题的优先顺序。这意味着，如果你对不同的资源或不同的问题有相同的免费模板解决方案，则只会生成一个补救项目 
。

D.在哪里：选择在哪个项目下为补救团队打开工单(例如，在Jira 、ServiceNow或修复者使用的任何其他工单系统中)
。

既然你知道谁将执行修复以及要发送它们的补救操作列表
，你就可以开始发送它们了。

在这个阶段，你将意识到你能够并行地进行补救，而不是像今天通常所做的那样以顺序的方式进行。

作为一个简单的示例场景 ，假设你有两个补救团队，Engineering和DevOps，并且你有150个关键发现 。接下来，让我们假设前100个调查结果都由Engineering修复
，其余50个由DevOps修复 。按顺序完成列表将意味着工程团队的修复程序超负荷，而DevOps团队则未得到充分利用 。但是 ，一旦你基于补救操作处理列表，并且你知道将进行补救工作的团队，你就可以并行地补救部分积压。

这是使你能够真正扩展的步骤 ：通过创建程序化工作流来自动化积压管理 。实现这一点的关键是与其他企业流程同步，并在补救团队需要安全数据时使其可用，而不是在发现发现时提供。

首先 ，在补救项目和每个不同的补救团队使用的票务系统之间应该有一个工作流程 。这样，当发现问题时  ，票证将自动打开并定向到正确的团队，如步骤3中所定义。你甚至可以更进一步，为每个票务系统创建统一的模板。

你的自动化工作流程应该是双向的，以便在票务系统中关闭票证时 ，你可以使用下一次测试扫描的结果进行验证。如果发现任何差异，请通过在补救团队的工作流工具中重新打开带有相关详细信息的票据来突出显示它。

这是为补救安全问题而进行的实际修复、缓解或风险接受 。这是补救过程中的关键部分，但作为安全团队，它不在你的直接控制范围之内 。

拥有将补救操作发送给正确的补救团队的自动路由流程，使你可以立即查看整个积压及其状态 ，而不仅仅是它是否得到了补救。这使你能够跟踪和衡量你的风险降低过程。

有了这些数据 ，你可以衡量绩效，还可以比较企业内不同团队或组之间的补救绩效。例如，你可以分析和比较不同的应用程序在关键发现、总发现以及团队如何处理他们的罚单方面。

你现在还可以向利益相关者提供有关企业补救计划的报告，使每个人都能够了解该计划的节奏和性能，以及统计数据 ，如新发现与已解决发现的比率、补救的平均时间和总体积压状态 。

这种跟踪使你能够识别补救流程本身中的任何问题，并为安全团队提供数据，他们可以使用这些数据与相应的补救团队更紧密地协作 ，以增强其流程并解决任何需要改进的领域。

正是这种从产出转移到结果的方法
，应该在消除安全成为补救过程中的瓶颈并使过程能够扩展方面发挥带头作用。