在许多关于安全设计倡议的文章中，常使用“编码错误类别”、“漏洞类别”或“缺陷类别”等短语。你可能想知道为什么如此强调将缺陷归类，而不是专注于单个缺陷。事实上，很多人问我们，为什么我们敦促软件制造商消除整个缺陷类别，如跨站点脚本 (XSS)、SQL 注入 (SQLi)、目录遍历和内存不安全，正如我们在安全设计承诺中所呼吁的那样。为了说明如何通过关注质量和消除错误组来提高安全性，我们提供了当前的想法。 从模式到进步
复制成功的行业。虽然让软件更安全似乎是一个新概念，但根本原因分析和减少重复出现的缺陷是质量和安全水平明显更高的行业的常态。在航空业，专家们会分析与安全相关的事件，以了解问题的直接原因，以及多种促成因素，从而让他们能够提出建议，改变飞行员、机组人员和空中交通管制员的培训、飞机维护、驾驶舱和飞机设计等。
识别模式。为了大规模提高产品质量和安全性，我们需要发现重复出现的缺陷模式，这样我们才能从一次解决一个缺陷转变为从一开始就消除它们。开发人员在任何一个软件制造商或整个行业中反复犯下哪些类型的编码错误？当我们将负面结果分为几类时，我们就可以开始进行系统思考，以了解真正的根本原因和潜在的补救措施。此外，这有助于我们更好地预测这些产品缺陷将如何被恶意行为者利用，从而让防御者在利用有限资源时占据优势。分析随时间变化的趋势。模式检测只是第一步。我们还需要了解这些模式如何随时间变化。对于任何给定的软件产品或整个行业，缺陷类别是随时间增加还是减少？通过查看趋势，我们可以开始了解哪些软件公司正在取得进展，哪些软件公司需要启动质量改进计划。 概括补救措施。通过思考缺陷的类别，我们可以超越问题的症状，开始更多地思考概括补救措施的方法。这种思路还可以将安全责任从能力最差的人转移到能力最强的人。软件开发人员不必问“我如何修复这个缺陷？”，他们可以问“我如何防止所有类似的缺陷？”与其修复一个 SQL 注入 (SQLi) 缺陷，为什么不完全消除它们呢？一些公司似乎已经这样做了。 补救措施规模。有些类型的编码错误可以用相对较少的努力消除，而有些则可能需要付出巨大努力。在我们了解各种缺陷的普遍程度之前，我们将无法区分公司应自行消除的缺陷类型和需要更大的软件生态系统协调努力的缺陷类型。安全左移。在软件开发中，人们使用短语“左移”来表示在软件开发生命周期 (SDLC) 的早期阶段开展某些活动。部分原因是，预防编码错误比在时间线后期发现和修复错误更便宜。短语“左移”和“消除漏洞类别”是同一枚硬币的不同面。如果您真正调整产品安全程序以尽可能在开发周期的早期阶段预防缺陷，这意味着您正在时间线上将安全性左移，那么您必须考虑消除整个编码错误类别的方法。开发者生态系统。谷歌 2024 年 3 月的白皮书《谷歌的安全设计》包含了这一重要观察：“软件产品和服务的安全态势是开发者生态系统的新兴属性 ，它们就是在开发者生态系统中设计、实施和部署的”。他们进一步写道：“精心设计开发者生态系统可以大幅降低某些缺陷的发生率，在某些情况下甚至可以消除它们”。这个想法是，重复出现的软件缺陷类型不是单个软件开发人员的错。这意味着“开发人员培训”可能不是最好的补救措施。相反，他们认为，这些重复出现的缺陷是公司为程序员提供的工具和实践的新兴属性。有些工具让开发人员几乎不可能避免编码错误。举个例子，看看 C/C++ 等语言与 Swift、C#、Java、Rust、Python、JavaScript、Go 和 Ruby 等其他语言相比，内存安全缺陷的普遍性。 成本
降低软件制造商的成本。软件缺陷可能会在任意时间报告。让软件开发人员放弃其他任务来解决软件缺陷可能会花费高昂且打乱项目进度。由于任何企业都希望尽可能节省开支，因此检查不安全因素给公司带来的成本是有用的。为了实现规模经济，公司应该投资于必要的工具和资源，以防止引入所有类型的缺陷，并实现安全的结果，例如安全的开发人员生态系统。降低客户成本。无论企业规模大小，应用软件更新都不是一件小事，更不用说入侵的成本了。我们现在知道，安全不会仅仅通过“更努力地修补”来实现。因此，减少关键安全修复的数量可以减轻 IT 专业人员的负担，并提高客户安全性。增加威胁行为者的成本。当我们消除所有缺陷类别时，威胁行为者就更难利用简单的漏洞。这增加了他们进行恶意网络活动的成本。如果产品团队消除了足够多的典型缺陷，他们可能会将一些威胁行为者挤出市场。 我们不是已经这么做了么？
一些软件公司已经开始努力消除编码错误。有些公司甚至已经实现了消除最常见错误的目标。但有证据表明，整个行业并没有取得足够的进展。事实上，许多顶级软件产品未能保护其客户免受最常见缺陷的攻击。我们在新闻中看到这些常见缺陷给公司和政府机构造成了重大损失。让我们比较一下两份文件，MITRE 2007年的论文《不可原谅的漏洞》和 2023 年的分析《顽固的弱点》。我们有理由相信 2007年的缺陷类别已经消除，而2023年的报告将包含所有新的缺陷类别，这些缺陷的利用成本更高。我们希望软件行业每隔几年就能消除最高级别的缺陷，因为这样做会增加威胁行为者的成本。可悲的是，事实是，自2007年iPhone 推出以来，软件行业一直没有取得足够的进展。在 13 个“不可原谅的漏洞”中，大多数仍然以某种形式出现在 2023 年的报告中。我们仍然受到诸如内存不安全、XSS、SQL 注入、目录遍历和输入清理不当等缺陷的困扰。特别值得注意的是，对于大多数此类缺陷，我们已经知道如何在数年甚至数十年内大规模预防它们。一些破坏性强且代价高昂的网络入侵可能是可以预防的。在过去的 17 年里，许多软件公司优先修复客户部署中发现的软件缺陷，而不是修复产品设计中的缺陷，从而使客户面临风险并导致严重的现实危害。CWE/CPE 挑战
上述两份报告依赖于通用漏洞和暴露 (CVE)划，特别是 CVE 编号机构 (CNA) 承诺提供及时、完整和正确的 CVE 记录。通用弱点枚举 (CWE)通用平台枚举 (CPE)段对于根本原因分析尤为重要。CWE 解释了造成缺陷的编码错误类型。CPE 提供有关产品和平台命名的信息。 如今，一些CNA确保他们创建的所有CVE记录都包含CWE和 CPE字段，但许多人并不那么勤奋。除非所有CNA和软件制造商都完全致力于确保他们的CVE记录（以及CWE/CPE字段）及时、完整和正确，否则我们将很难成为一个数据驱动的行业。不完整或不准确的数据将使我们对网络入侵的根本原因一无所知，并阻碍我们大规模预防网络入侵的能力。 但我们看到了一些进步的迹象。最近，微软宣布们将“使用通用弱点枚举 (CWE) 行业标准发布 Microsoft CVE的根本原因数据”。他们的博客文章值得一读，以了解他们的观点。这一发展——以及68家软件制造商的承诺——是我们承诺这样做的一部分——令人兴奋，我们希望所有CNA和软件制造商都能效仿。 结论
下次看到软件产品的安全敏感更新时，不要关注威胁者如何滥用该特定编码错误。问问自己它属于哪一类编码错误。如果它属于 2007 年论文中提到的“不可原谅的漏洞”之一，或反复出现的“顽固漏洞”之一，请问问自己，在系统性预防措施众所周知的情况下，软件制造商为何会发布有缺陷的产品。更重要的是，问问那些软件公司他们正在采取什么措施来消除整个缺陷类别。作为客户，我们应该要求公司停止发布有缺陷的软件的做法，然后只修复现场发现的问题，通常是在客户受伤之后。 底线是，安全设计软件开发程序需要在产品发货前采取正式措施消除所有类型的缺陷，而不是在生产过程中对客户系统上出现的缺陷进行打地鼠游戏。对于软件制造商而言，安全设计程序可以消除所有类型的缺陷，从长远来看，成本可能更低，并且能够生产出质量更高、需要的紧急修复更少的产品。这样的程序应该成为公司业务战略的一部分。对于客户而言，它将减轻必须应用许多紧急软件更新的负担。对于我们国家而言，它将带来更高的安全性。在其他行业中，进行根本原因分析并努力消除各种类型的缺陷是常态，而这早就应该成为软件行业的常态了。 
还没有评论，来说两句吧...