我听到的最好的建议是列出所有可能因您的安全债务而发生的不同类型的事件。接下来，尝试估算每个事件的成本。接下来，计算这些事件每年发生的可能性。你的最终公式应该看起来像

Probability(event type 1) * Cost(event type 1) + 
Probability(event type 2) * Cost(event type 2) + 
... +
Probability(event type N) * Cost(event type N)

例如，假设您确定您的安全借记卡可以利用两个问题：SQL 注入 + CSRF。（我编了数字以使数学更容易）：

• 我们预计每年会发生 5 次成功的 SQL 注入攻击，每次攻击的恢复成本为 100,000 美元
• 我们预计 10 次成功的 CSRF 攻击，每次的恢复成本为 25,000 美元

您在相关年度的估计证券债务成本为：

(5 * 100,000 美元) + (10 * 25,000 美元) = 750,000 美元

在这一点上，没有标准化的方法来计算技术债务的规模（库存）。我一直在与一个由格拉斯哥大学和麻省理工学院的博士研究人员组成的研究团队合作，以开始创建一个框架来解决这个问题。我们正在结合麻省理工学院的安全系统理论过程分析 ( STPA-Sec ) 和来自海军舰船架构的概念，即漏洞设计。虽然这些技术旨在分析组织和任何子流程，但它也适用于作为分析目标的单个应用程序。

以下内容正在开发和测试中。尽管如此，这些概念还是有用的。

系统理论漏洞工程

对我的团队来说，计算“应用程序安全债务”只是“系统理论漏洞工程”的另一种形式。这与可以通过自动扫描程序、补丁和配置解决的典型漏洞管理不同。相反，当它连接到其他系统时，它会在人员、流程和技术的完整上下文中查看有问题的“系统”（在这种情况下是您的应用程序）。从这个系统理论的角度，您可以确定漏洞和弱点（近期漏洞）在哪里。

这些漏洞可能涵盖以下范围：

• 隐藏在缓解措施后面的 SQLi（裸露和暴露的 SQLi 漏洞是一个问题，而不是债务）
• 未打补丁的子系统
• 需要人工干预才能触发和完成的手动修补过程
• 缺乏审计

所有这些都代表了“安全债务”或“系统漏洞”。

请注意，尽管可以通过对威胁的理解来定义漏洞，但这种方法并不关心威胁。这不是威胁建模过程（请参阅最后一节）。

第 1 步：漏洞分析（超浓缩形式）

1. 定义安全问题（您担心什么？）
2. 识别不安全控制的类型（例如程序逻辑、系统维护、保证）
3. 识别不安全控制类型的原因（例如流程、技术、资源、知识、文化等）
4. 确定当前是否存在这些原因（恒定状态或间歇性）

您最终会对系统当前的漏洞进行系统分析。

但是现在您仍然需要确定是否需要对此采取措施。

第 2 步：响应控制分析（超浓缩形式）

1. 确定围绕每个已识别漏洞的响应/恢复控制（我们可以检测和响应不安全事件吗？）
2. 确定哪些响应/恢复控制不能充分包含任何利用漏洞或由漏洞引起的事件
3. 确定足够的响应/恢复控制是否存在可能导致控制不足的当前漏洞。

您最终会得到一个安全漏洞列表，但缓解措施不足。这是你的债务。

请注意，并非此过程产生的所有项目都是技术性的（事实上，从我们最初的案例研究来看，很少有项目是技术性的）。您可能会发现您的 SQLi 问题实际上是代码审查过程中的一个弱点，这是以功能为重点而非代码质量重点的开发文化的结果。在这种情况下，债务是文化的。

第 3 步：风险调整

这是您开始设计权衡取舍的地方：1) 以各种方式（人员、流程或技术）减少漏洞和 2) 改进响应控制，以便支持系统的目标。

就像任何风险缓解过程一样，您需要将缓解成本保持在低于预期损失的水平，并且必须完成所有这些以支持系统的目标。

漏洞建模与威胁建模

通过采用系统理论和以漏洞为中心的方法，我们发现这一过程促进了具有成本效益的补救措施，并针对问题的根本原因，而不是问题的影响。它还将确定需要删除的区域以减少漏洞（减法过程）。

以威胁为中心的方法往往是被动的、昂贵的、技术性的和附加的（有一个新的威胁，我们需要更多的东西！）。这会产生更多的债务，而不是减少债务。

估计应用程序安全债务 在软件开发过程中，需要进行严格的编程程序、代码分析和应用程序测试。这些程序特别旨在确保开发的应用程序具有最高质量，并且所有安全漏洞都被密封。然而，尽管严格遵守设定的开发程序，开发的应用程序有时会变得容易受到攻击。这些漏洞在应用程序中的累积最终成为应用程序安全债务。在他的文章中，Chris 将应用程序债务描述为“*

安全债务类似于技术债务。这两种债务都是设计和实现结构，它们具有随着时间的推移而累积的负面方面，并且必须重新编写代码才能摆脱债务。安全债务基于应用程序中的潜在漏洞。应用程序利率是软件开发团队无法控制的现实世界因素，导致漏洞具有实际成本。这些因素包括安全漏洞的成本和攻击者发现和利用潜在漏洞的动机

*。” 应用安全债务财务模型 目前，有几个应用安全债务指标试图估计安全债务的价值。在本文中，我将讨论Russell的一篇文章，我认为这有助于解决证券债务的概念。

罗素在他的帖子中指出 *

“应用程序安全债务是一种本金可变的‘贷款’，本金可能为原始项目成本的 0% 到 100%。“本金”是您最终必须为修复安全漏洞或重写代码而支付的费用。它还具有不同且不确定的“利息成本”，即由于这些漏洞导致的安全漏洞成本。这包括所有气球支付的可能性（即巨大的损失事件）。”

* 这为我们提供了债务公式
债务 = 预期本金 + 利息成本
主要任务涉及估计预期本金和利息成本的值。

预期本金 我们应该注意的一件事是，预期本金的价值将始终是初始项目成本的百分比。这意味着预期本金的值可以在初始成本的 0%-100% 之间。这意味着预期的本金价值可以随着离散值 F 的增加而增加。管理层面临着几种情况，即，他们可以：不重写 (0%)、轻微重写 (10%)、主要重写 (25%)、进行大量重写 (50%) 或为 100% 的重写付费。因此，预期本金将是初始项目成本 F 乘以管理层选择该选项的概率的比例。

EP=∑_(i=1)^5▒〖p(F¬¬i).c(Fi)〗

其中 F¬i=代码修复场景 (i=0..n=5) P(Fi)=选择特定场景的概率 C(Fi)=修复所选场景的成本。但是，预期本金将根据行业、公司规模和公司资源等因素而有所不同。管理层将决定在不同情况下投资的资源数量。

利息成本 利息成本包括支付违约成本所涉及的成本。它们是在应用程序的漏洞被利用后发生的。估计可能性的类型和发生应用程序泄露的可能性是困难的。这是因为没有直接关系决定特定应用程序会发生哪种类型的违规行为。

目前，入侵者的目标是处理敏感客户数据的应用程序是基本知识，但同时，这些处理敏感数据的应用程序的安全级别非常高。由于安全漏洞的动态特性，一个应用程序中的漏洞可能会影响另一个应用程序的安全性。例如，许多组织更喜欢将第三方应用程序与内部应用程序集成。这些应用程序的集成可能会影响另一个应用程序的安全性。因此，将难以估计可能性。

使用数据来估计利息成本可能有助于估计利息成本的价值。来自同一行业的不同公司的数据可用于确定公司为应对数据泄露而承担的费用。