文章总结： 英国NCSC发布指南提出将漏洞分为可原谅与不可原谅两类。修复成本低且方案成熟的漏洞若未处理即为不可原谅。建议开发者必须掌握输入验证等基础技能，企业应推行安全左移，并在新项目中优先采用内存安全语言，以系统性消除低级漏洞。
综合评分： 95
文章分类： 漏洞分析,安全建设,安全开发,漏洞预警
英国国家网络安全中心NCSC发布“不可原谅”漏洞判定指南
原创
玄月调查小组
玄月调查小组
玄月调查小组
2026年2月2日 10:57
上海
导语
英国国家网络安全中心（NCSC）近日发布了一份技术指南，提出将软件漏洞划分为“可原谅”与“不可原谅”。该研究指出，尽管软件复杂性在增加，但某些容易发现且反复出现的漏洞代表了对安全开发实践的系统性漠视。
简单说就是：那些修补成本极低、业界方案成熟却依然存在的低级漏洞，属于“不可原谅”的开发失职。看来以后再想用“技术实现太难”来甩锅，是行不通了。
20年未变的缺陷率：软件行业的“顽疾”
根据NCSC引用的研究数据（包括Coverity和McConnell的分析），过去20年间，软件中的平均缺陷数量惊人地保持恒定。每1000行代码（KLOC）中平均存在约1个缺陷。考虑到软件源代码规模平均每3.5年就会翻一番（主要由用户对功能和硬件性能的需求驱动），这意味着绝对缺陷数量正在呈指数级增长。
NCSC强调，虽然所有系统都包含漏洞，且现代漏洞往往复杂难防，但有一类漏洞是NCSC决心要大规模打击的——那就是“不可原谅的漏洞”。这一概念最早由Steve Christie在2007年的MITRE论文中提出，指那些根本不应该出现在经过安全设计、开发和测试的软件中的漏洞。
什么是“不可原谅”的漏洞？
情有可原的漏洞
这种漏洞确实难搞。要么是藏得太深很难发现，要么是修复起来太贵（比如要重构），再或者技术上确实有门槛，得依赖一堆复杂的前提条件。对此，NCSC表示理解。
不可原谅的漏洞
这类漏洞本不该存在。其对应的缓解措施文档齐全、实施成本低廉且不依赖复杂的前提条件。正如Steve Christie所言，它们是“对安全开发实践系统性漠视的灯塔”。
为了评估一个漏洞是否“可原谅”，NCSC引入了实施难度评分模型。该模型从三个维度对缓解措施进行打分（1分代表容易/低成本，3分代表困难/高成本）：
- 成本：包括直接许可费用和编程所需的额外时间。
- 知识普及度：该缓解措施是否被广泛知晓。
- 技术可行性：实施的难易程度及是否有硬件门槛。
小结：如果一个漏洞可以通过简单的缓解措施来修复，但开发商却没有做，那么该漏洞就是“不可原谅”的。
缓解措施难度大起底
小编梳理了NCSC对于常见安全缓解措施的难度评级，大家可以对着自己的项目自查一下：
-
简单：
-
输入验证：成本低，业界通识。
-
输出编码：防止注入攻击的基础手段，技术成熟到不能再成熟了。
这两项得分为3分（最低分），属于“不做就是失职”。
-
中等：
-
减少攻击面：虽然概念简单，但砍功能确实容易跟产品经理打架，算中等难度。
-
沙盒或隔离：技术可行，但可能限制应用功能。
-
使用库或框架：虽然推荐，但迁移框架成本较高。
-
困难：
-
安全架构设计：若未在项目初期规划，后期重构代价极高。
-
语言选择：这是最难的缓解措施（8分）
为何“语言选择”被判定为困难？
有趣的是，NCSC将“语言选择”（例如从C/C++转向Rust或Go等内存安全语言）列为实施难度最高的措施之一（8分）。
尽管Rust等现代语言能提供内存安全保障，但NCSC承认现实层面的阻力：
- 生态系统制约：特定平台（如嵌入式设备）的支持有限。
- 遗留代码包袱：Chrome虽然用了 Rust 工具链并使用了一些 Rust 组件，但其拥有2900 万行C++代码，迁移极其漫长且昂贵。
- 技能缺口：虽然开发者愿意学习新语言，但在现有项目中追溯性地更换语言在技术和经济上往往是不可行的。
因此，如果一个漏洞是因为使用了C++而非Rust导致的，它可能被归类为“可原谅”，因为更换语言并非易事；但如果是因为没有做基本的输入验证，那就是“不可原谅”。
举个例子：SQL注入
NCSC以一个虚构的CVE（供应商应用未授权SQL注入漏洞）为例进行了分析。
在分析该漏洞的补丁代码后，研究人员发现修复该漏洞涉及三个方面：
- 使用更安全的SQL库（难度：中等）
- 移除不必要的函数（难度：中等）
- 在使用前将变量设为NULL（输入验证的一种，难度：简单）
尽管该漏洞在利用层面可能难以发现，但其根本原因之一可以通过“简单”级别的缓解措施（输入验证）来解决。因此，NCSC判定该漏洞为“不可原谅”。这意味着开发人员在开发阶段只要具备基本的安全意识，完全可以避免此类问题。
建议
此次NCSC的报告不仅是给安全研究员看的，更是给所有软件开发商敲响的警钟：
- 对于开发者：必须掌握基本的安全开发技巧。输入验证和输出编码不仅是基本功，现在更成为了衡量代码质量的“道德标准”。如果你还在写拼接SQL语句的代码，那确实是“不可原谅”的。
- 对于企业CTO：报告明确指出，追溯性地添加安全架构或更换语言是“困难”模式。这意味着“安全左移”（在设计阶段就考虑安全）不再是口号，而是最具性价比的商业决策。
- 未来趋势：虽然更换语言很难，但NCSC强烈建议在新项目中默认使用内存安全语言（如Rust, Go等）。这是根除内存破坏类漏洞（如缓冲区溢出）的终极解法。
参考资料：A method to assess ‘forgivable’ vs ‘unforgivable’ vulnerabilities：https://www.ncsc.gov.uk/report/a-method-to-assess-forgivable-vs-unforgivable-vulnerabilities
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：玄月调查小组 玄月调查小组
玄月调查小组《英国国家网络安全中心NCSC发布“不可原谅”漏洞判定指南》