Vulnerability Debt（漏洞债）是网络安全与软件工程领域的术语，指组织或厂商已知却尚未修复的安全漏洞不断累积所形成的欠账，也常称为安全债（Security Debt）[1]。它借用技术债的比喻，把未修补的漏洞视为需要偿还的债务：漏洞留存越多、时间越长，日后修复的成本和遭受攻击的风险就越高。与一般技术债不同，漏洞债的“利息”还包括系统生命周期中不断累积的安全风险，因此被视为一种随时可能被攻击者“催收”的隐性负债。
定义
Vulnerability Debt 指一个组织已识别但未予修复的安全缺陷所构成的积压，这些漏洞因资源有限、优先级框架或工具负担等原因被有意推迟处理，从而形成长期的安全与经济风险[1]。它由技术债的隐喻衍生而来，但债务的“利息”不只是日后额外的维护工作量，而是贯穿系统整个生命周期的额外安全风险[2]。在开源软件场景中，漏洞债常表现为长期未升级的依赖组件、修复路径缺失的老旧版本、不完整的漏洞情报以及工程人力不足所导致的积压[3]。
漏洞债与单个安全漏洞并不等同：前者强调组织层面被接受的欠账状态，后者指具体的缺陷本身；有研究认为安全漏洞在不同程度上构成安全债的组成部分[4]。也有观点把漏洞债理解为信息安全主管用来描述组织内部安全问题修复成本的术语，其形成往往与资源缺乏和流程不成体系有关[5]。
原理
漏洞债的结构可以类比借贷：未修复漏洞的集合相当于本金，随时间增加的修复成本与攻击风险相当于利息，拖欠越久，偿还代价越高[1]。组织通常依据优先级框架只处理少量高危漏洞，其余漏洞被暂时搁置，随着新漏洞持续披露，积压规模不断扩大并逐渐难以收拾[1]。积压持续增长主要有三方面原因：每年新披露漏洞数量庞大、混合云等环境使资产分散且难以管理、逐一致命漏洞的追踪与修补工作量巨大。
为便于跟踪，有从业者提出把漏洞债换算为可量化的分数，即漏洞债分数等于未修复的严重与高危漏洞数量、平均未修补天数、受影响应用业务重要度权重三者之积，其中业务权重按1至5分赋值[6]。其形式化表达可写为 $VDS = N_{crit/high} \times D_{unpatched} \times W_{business}$。
漏洞债的累积与转化过程可大致表示为：新漏洞披露后经优先级筛选，少数高危项被修复，其余被搁置并不断累加，最终在新的攻击面或合规审查下集中暴露。
flowchart LR
A[新漏洞披露] --> B[按优先级筛选]
B --> C[修复少量高危漏洞]
B --> D[其余漏洞搁置]
D --> E[漏洞债累积]
E --> F[被攻击者利用或补救成本上升]
发展历程
债务隐喻来自软件开发中的技术债概念，1992年由沃德·坎宁安（Ward Cunningham）提出，用来描述为求快速交付而作出的妥协在日后需要付出的额外成本。2013年8月，USENIX的刊物《;login:》推出安全债专题，丹·吉尔（Dan Geer）与克里斯·怀索帕尔（Chris Wysopal）在文中提出，每次软件发布都相当于一次举债，而漏洞会被对手而非意外触发，因此信息安全失稳可视为技术债中极具关键性的形态[7]。上述专题还引用了怀索帕尔更早提出的应用安全债与应用利率的说法，并以微软重写IIS 6.0后已披露漏洞数量下降为例，说明偿还债务的一种做法[8]。
部分行业术语资料认为，安全债这一说法在2010年代后期随DevOps与快速交付实践的普及而流传，2017年至2018年前后开始受到较多关注[9]。此后随着披露漏洞数量上升，这一概念被更频繁地使用：有统计显示，2017年报告的通用漏洞披露（CVE）约14645个，2024年增至约4万个[1]。2021年，《福布斯》技术理事会专栏文章把漏洞债界定为已知但因赶交付而被暂时接受的非严重漏洞，并指出嵌入式系统中的临时漏洞常因功能安全测试成本高昂而转为长期负担。
2024年发表的一项案例研究访谈了多家软件企业的26名从业者，提出安全债是技术债的子集，并指出业界当时仍未形成普遍接受的定义[4]。
应用
漏洞债的概念主要用于漏洞管理与安全工作汇报。安全团队借助它说明仅靠优先级排序并不足够，被长期搁置的漏洞会形成隐性负债，并可能在日后被利用或招致监管审查[1]。也有从业者主张把抽象的风险等级换算为债务与利息等财务语言，以便管理层和董事会理解推迟修复的后果。部分团队则把未修复严重漏洞的数量趋势当作工程指标，用来观察债务是在收敛还是扩张，并评估其对变更失败率的影响[10]。
在治理层面，减少漏洞债的常见做法是改变修复的计量单元，把同一文件、同一依赖或同一基础镜像引发的多个问题合并处理，并让修复随常规补丁周期一并完成[1]。技术手段上，软件成分分析、静态应用安全测试、动态应用安全测试、交互式应用安全测试、模糊测试与渗透测试等，被用于在开发的不同阶段发现漏洞。合规要求也推动相关实践，美国网络安全和基础设施安全局（CISA）的已知被利用漏洞清单以及美国证券交易委员会的信息披露规则，都要求组织缩短响应时间[1]。
局限
漏洞债概念最明显的局限是缺乏统一公认的定义。2024年的案例研究指出，业界尚未形成被普遍接受的安全债定义，它与技术债、安全漏洞之间的边界也仍需厘清，这使不同组织的口径难以直接比较[4]。相关研究还提到，该领域缺少详细的工业经验报告与数据集，也缺少面向产品早期阶段的工具支持[2]。
另一个问题是并非所有债务都应当立即偿还。有观点认为，如同企业运用财务杠杆一样，审慎推迟非紧急修复可以换取交付速度，关键在于组织能否承受随之而来的风险利息。但在嵌入式与关键任务系统中，原本被视为临时风险的漏洞，常因系统改动需要昂贵耗时的功能安全验证而变成长期问题，功能上的补救有时只能依靠叠加缓解措施。
量化漏洞债还依赖对资产与漏洞的准确掌握，资产清单不完整会直接影响计算结果[5]。此外，若只清理既有积压而不切断新漏洞产生的路径，债务仍会持续累积，因此清欠与预防需要同时推进[11]。
参见
参考资料
- It’s Time to Understand and Manage Vulnerability Debt . nucleussec.com [引用日期2026-09-29]
- Security Debt in Practice . uio.no [引用日期2026-09-29]
- Modern Vulnerability Management in the Age of AI | Sonatype . sonatype.com [引用日期2026-09-29]
- acm.org 上的网页 . acm.org [引用日期2026-09-29]
- Which vulnerability should be remediated first? . ipvsecurity.com [引用日期2026-09-29]
- The Real Cost of Unfixed Vulnerabilities to Quantify in 2026 . derscanner.com [引用日期2026-09-29]
- For Good Measure: Security Debt . usenix.org [引用日期2026-09-29]
- For Good Measure . usenix.net [引用日期2026-09-29]
- Security Debt - What is security debt? . plurilock.com [引用日期2026-09-29]
- snyk-dora-metrics . koalr.com [引用日期2026-09-29]
- cycode.com 上的网页 . cycode.com [引用日期2026-09-29]
浏览次数：0 次
阅读量：0 次 · 阅读完成量：0 次
最近更新：2026-09-29T12:51:18Z
完成率 = 阅读完成量 ÷ 阅读量，分母是阅读量不是浏览次数 —— 关了 JS 的、秒退的都在浏览次数里、不在阅读量里。 详细口径在后台的「数据统计」页。