2019年最危险的软件错误：历史重演的更多证据
这篇文章最初出现在 信息安全评论并被其他几家媒体采用。它已被更新，以便在此进行联合传播。
在去年年底，MITRE的神奇社区发布了他们的CWE 25大最危险软件错误名单，这些错误在2019年影响了世界。这份名单不是由意见驱动的，它是利用NIST等组织的工作以及公开的通用漏洞和暴露（CVE）数据进行多方面分析的结果。为了确定 "顶级 "缺陷，根据其严重性、可利用性和在当前软件中的普遍性进行评分。可以肯定的是，这不是那种会赢得任何积极赞誉的名单。
然而，与大多数年度总结不同的是，这份名单上的许多入选者以前就出现过......一次又一次。如果这是Billboard Hot 100排行榜，那就像Britney Spears的Baby One More Time和Backstreet Boys的I Want It That Way一样，从最初发行以来每年都出现。而我为什么要选择这些歌曲呢？好吧，它们大约有20年的历史了（感觉古老了吗？），就像一些危险的软件错误一样，尽管它们在几十年前就被发现了，但到2020年仍然困扰着我们。
为什么老的错误仍然如此危险？难道我们不知道如何修复它们吗？
目前MITRE名单上的第六位是CWE-89，也就是众所周知的SQL注入（SQLi）。SQLi漏洞首次被发现于1998年，当时我们中的许多人还在向Jeeves询问我们的迫切问题，而不是谷歌。不久之后就有了修复方案，然而，这仍然是2019年最常用的黑客技术之一。Akamai的 互联网的现状报告显示，SQLi是所有网络应用程序攻击中三分之二的罪魁祸首。
就复杂性而言，SQL注入远不是一个天才级的漏洞。对于网络开发者来说，这是一个简单的修复方法，而且我们确实毫不犹豫地知道，如何防止这个漏洞将宝贵的数据暴露给攻击者......问题是，即使在今天，对于许多开发者来说，安全并不是一个优先事项。这在二十年前可能比较容易，但随着今天和未来软件数量的增加，这不能再成为常态了。
开发人员在一个破碎的系统中运作（大部分时间）。
我们很容易坐视不管，指责开发人员提供了 "坏 "代码。事实是，他们的工作重点与安全团队的工作重点大不相同。你的普通开发团队被告知要尽可能快地做出漂亮的、功能性的软件。社会对软件永不满足的需求确保了开发团队已经捉襟见肘，而安全并不是首要考虑的因素；毕竟，这不就是AppSec专家存在的原因吗？软件工程师们已经习惯了与安全的冷淡关系--他们只有在问题出现时才会听到他们的声音，而这些问题会阻碍他们辛勤工作的成果。
在栅栏的另一边，应用安全专家已经厌倦了修复那些在每次扫描和手动代码审查中不断出现的几十年前的错误。这些专家既昂贵又稀缺，他们的时间最好用在复杂的安全缺陷上，而不是一遍又一遍地压制众所周知的错误。
这些团队之间存在着一种心照不宣的指责文化，但他们有（或应该有）共同的目标：安全的软件。开发人员所处的环境很少能让他们在安全编码方面获得最佳的成功机会；安全的最佳实践很少作为他们高等教育的一部分被教授，而在职培训往往太不频繁，或者完全无效。对安全意识和深入的相关教育明显缺乏重视，其结果是修复已提交的代码中的旧错误的天文数字成本，加上即将发生的破坏声誉的数据泄露的威胁。
人为因素，也就是 "为什么所有这些工具都不能使我们的数据更安全？"
另一个经常出现的问题是，代替培训的是大量的安全工具，在软件被发布到野外之前就被投入到发现问题的任务中。阵列式应用扫描和保护工具（SAST/DAST/RASP/IAST）当然可以协助安全的软件生产，但它们也有自己的问题。完全依赖它们并不能保证安全，因为。
- 没有一个工具可以在每个框架和每个用例中扫描每个漏洞。
- 它们可能很慢，尤其是在串联运行以提供静态和动态代码分析时。
- 误报仍然是一个问题；这些误报往往会停止生产，并需要进行不必要的手工代码审查以了解警报。
- 他们创造了一种虚假的安全感，安全编码被置于优先地位，期望这些工具能发现任何问题。
这些工具当然会发现可以修补的安全缺陷，但它们能找到所有的东西吗？100%的命中率是不可能保证的，攻击者只需要打开一扇门就可以进入并真正毁掉你的日子。
值得庆幸的是，许多组织都意识到了在软件漏洞中起作用的人为因素。大多数开发人员没有接受过充分的安全编码培训，他们的整体安全意识也很低。然而，他们处于软件开发生命周期的最开始，处于阻止漏洞进入已提交代码的首要位置。如果他们从一开始就进行安全编码，他们就会成为防御破坏性网络攻击的前线，这些攻击每年给我们带来数十亿美元的损失。
开发人员需要有机会茁壮成长，接受与他们的语言相通、与他们的工作相关的培训，并让他们对安全感到兴奋。无缺陷的代码应该是一个值得骄傲的点，就像在功能上建立起的东西会让你赢得同行的尊重。
一个现代的安全计划应该是一个企业的优先事项。
开发团队不可能自力更生，在整个公司内颁布积极的安全意识。他们需要正确的工具、知识和支持，以便从一开始就将安全纳入软件开发过程。
如果MITRE的名单上还在展示这么多旧的安全漏洞，那么旧的培训方法显然是不行的，所以要尝试新的东西。寻找以下的培训方案。
- 实践；开发人员喜欢 "在实践中学习"，而不是看视频中的说话人。
- 相关的；如果他们每天都在使用Java，就不要让他们用C#来训练。
- 吸引人；一点一滴的学习很容易消化，并允许开发人员继续巩固以前的知识
- 可衡量的；不要只是打勾，然后继续前进。确保培训是有效的，并为改进创造途径
- 乐趣；看看除了支持积极的安全文化之外，你还可以建立安全意识，以及这如何创造一个有凝聚力的团队环境。
安全应该是企业中每个人的首要任务，CISO对每个层面的努力都是可见和透明的，以保持我们的数据更加安全。我的意思是，谁愿意重复听同样的老歌？现在是时候认真对待彻底粉碎旧的错误了。
皮特-丹休
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
2019年最危险的软件错误：历史重演的更多证据
这篇文章最初出现在 信息安全评论并被其他几家媒体采用。它已被更新，以便在此进行联合传播。
在去年年底，MITRE的神奇社区发布了他们的CWE 25大最危险软件错误名单，这些错误在2019年影响了世界。这份名单不是由意见驱动的，它是利用NIST等组织的工作以及公开的通用漏洞和暴露（CVE）数据进行多方面分析的结果。为了确定 "顶级 "缺陷，根据其严重性、可利用性和在当前软件中的普遍性进行评分。可以肯定的是，这不是那种会赢得任何积极赞誉的名单。
然而，与大多数年度总结不同的是，这份名单上的许多入选者以前就出现过......一次又一次。如果这是Billboard Hot 100排行榜，那就像Britney Spears的Baby One More Time和Backstreet Boys的I Want It That Way一样，从最初发行以来每年都出现。而我为什么要选择这些歌曲呢？好吧，它们大约有20年的历史了（感觉古老了吗？），就像一些危险的软件错误一样，尽管它们在几十年前就被发现了，但到2020年仍然困扰着我们。
为什么老的错误仍然如此危险？难道我们不知道如何修复它们吗？
目前MITRE名单上的第六位是CWE-89，也就是众所周知的SQL注入（SQLi）。SQLi漏洞首次被发现于1998年，当时我们中的许多人还在向Jeeves询问我们的迫切问题，而不是谷歌。不久之后就有了修复方案，然而，这仍然是2019年最常用的黑客技术之一。Akamai的 互联网的现状报告显示，SQLi是所有网络应用程序攻击中三分之二的罪魁祸首。
就复杂性而言，SQL注入远不是一个天才级的漏洞。对于网络开发者来说，这是一个简单的修复方法，而且我们确实毫不犹豫地知道，如何防止这个漏洞将宝贵的数据暴露给攻击者......问题是，即使在今天，对于许多开发者来说，安全并不是一个优先事项。这在二十年前可能比较容易，但随着今天和未来软件数量的增加，这不能再成为常态了。
开发人员在一个破碎的系统中运作（大部分时间）。
我们很容易坐视不管，指责开发人员提供了 "坏 "代码。事实是，他们的工作重点与安全团队的工作重点大不相同。你的普通开发团队被告知要尽可能快地做出漂亮的、功能性的软件。社会对软件永不满足的需求确保了开发团队已经捉襟见肘，而安全并不是首要考虑的因素；毕竟，这不就是AppSec专家存在的原因吗？软件工程师们已经习惯了与安全的冷淡关系--他们只有在问题出现时才会听到他们的声音，而这些问题会阻碍他们辛勤工作的成果。
在栅栏的另一边，应用安全专家已经厌倦了修复那些在每次扫描和手动代码审查中不断出现的几十年前的错误。这些专家既昂贵又稀缺，他们的时间最好用在复杂的安全缺陷上，而不是一遍又一遍地压制众所周知的错误。
这些团队之间存在着一种心照不宣的指责文化，但他们有（或应该有）共同的目标：安全的软件。开发人员所处的环境很少能让他们在安全编码方面获得最佳的成功机会；安全的最佳实践很少作为他们高等教育的一部分被教授，而在职培训往往太不频繁，或者完全无效。对安全意识和深入的相关教育明显缺乏重视，其结果是修复已提交的代码中的旧错误的天文数字成本，加上即将发生的破坏声誉的数据泄露的威胁。
人为因素，也就是 "为什么所有这些工具都不能使我们的数据更安全？"
另一个经常出现的问题是，代替培训的是大量的安全工具，在软件被发布到野外之前就被投入到发现问题的任务中。阵列式应用扫描和保护工具（SAST/DAST/RASP/IAST）当然可以协助安全的软件生产，但它们也有自己的问题。完全依赖它们并不能保证安全，因为。
- 没有一个工具可以在每个框架和每个用例中扫描每个漏洞。
- 它们可能很慢，尤其是在串联运行以提供静态和动态代码分析时。
- 误报仍然是一个问题；这些误报往往会停止生产，并需要进行不必要的手工代码审查以了解警报。
- 他们创造了一种虚假的安全感，安全编码被置于优先地位，期望这些工具能发现任何问题。
这些工具当然会发现可以修补的安全缺陷，但它们能找到所有的东西吗？100%的命中率是不可能保证的，攻击者只需要打开一扇门就可以进入并真正毁掉你的日子。
值得庆幸的是，许多组织都意识到了在软件漏洞中起作用的人为因素。大多数开发人员没有接受过充分的安全编码培训，他们的整体安全意识也很低。然而，他们处于软件开发生命周期的最开始，处于阻止漏洞进入已提交代码的首要位置。如果他们从一开始就进行安全编码，他们就会成为防御破坏性网络攻击的前线，这些攻击每年给我们带来数十亿美元的损失。
开发人员需要有机会茁壮成长，接受与他们的语言相通、与他们的工作相关的培训，并让他们对安全感到兴奋。无缺陷的代码应该是一个值得骄傲的点，就像在功能上建立起的东西会让你赢得同行的尊重。
一个现代的安全计划应该是一个企业的优先事项。
开发团队不可能自力更生，在整个公司内颁布积极的安全意识。他们需要正确的工具、知识和支持，以便从一开始就将安全纳入软件开发过程。
如果MITRE的名单上还在展示这么多旧的安全漏洞，那么旧的培训方法显然是不行的，所以要尝试新的东西。寻找以下的培训方案。
- 实践；开发人员喜欢 "在实践中学习"，而不是看视频中的说话人。
- 相关的；如果他们每天都在使用Java，就不要让他们用C#来训练。
- 吸引人；一点一滴的学习很容易消化，并允许开发人员继续巩固以前的知识
- 可衡量的；不要只是打勾，然后继续前进。确保培训是有效的，并为改进创造途径
- 乐趣；看看除了支持积极的安全文化之外，你还可以建立安全意识，以及这如何创造一个有凝聚力的团队环境。
安全应该是企业中每个人的首要任务，CISO对每个层面的努力都是可见和透明的，以保持我们的数据更加安全。我的意思是，谁愿意重复听同样的老歌？现在是时候认真对待彻底粉碎旧的错误了。
