2019年最危险的软件错误：更多历史重演的证据
这篇文章最初出现在 信息安全热点，并被其他几家媒体收购。它已更新以供在此处进行联合发布。
去年年底，MITRE的神奇社区发布了他们的清单 CWE 前 25 个最危险的软件错误 这在2019年影响了世界。这份清单不是以观点为导向的，它是利用诸如此类组织的工作进行多方面分析的结果 NIST，以及公布的常见漏洞和暴露 (CVE) 数据。为了确定 “最大” 缺陷，根据其严重性、可利用性和当前软件中的流行程度来给出分数。当然，这不是那种能赢得任何积极赞誉的名单。
但是，与大多数年度总结不同，这份名单上的许多参赛者以前... 一遍又一遍地出现过。如果这是 Billboard Hot 100 排行榜，那就像 Britney Spears 的宝贝再来一次 还有 Backstreet Boys 的我想要那样 自首次发布以来，每年都会出现。那我为什么要选那些歌？好吧，他们大约二十岁了（感觉很古老了吗？），就像其中一些危险的软件错误一样，尽管在几十年前发现了这些错误，但这些错误仍然困扰着我们，直到2020年。
为什么旧错误仍然如此危险？我们不知道如何修复它们吗？
当前 MITRE 清单上的第六名是 CWE-89，俗称 SQL 注入 (SQLi)。SQLi 漏洞最早在 1998 年被发现，当时我们中的许多人仍在向 Jeeves 询问我们的迫切问题，而不是向谷歌提问。不久之后就公布了修复程序，但是，这仍然是2019年最常用的黑客技术之一。Akamai 的 互联网现状 报告显示，SQLi是三分之二的罪魁祸首 所有 Web 应用程序攻击。
就复杂性而言，SQL 注入远非天才级的漏洞。对于网络开发人员来说，这是一个简单的解决方案，而我们 做 毫不犹豫地知道如何防止此漏洞将宝贵的数据暴露给攻击者... 问题是，即使在今天，对于许多开发人员来说，安全性也不是当务之急。二十年前，这可能更容易，但是随着当今和将来开发的软件数量庞大，这再也不能成为常态了。
开发人员在损坏的系统中运行（大多数时候）。
坐视不管，责怪开发人员提供了 “不好” 的代码，实在是太容易了。事实是，他们的优先事项与安全团队的优先事项大不相同。你的普通开发团队被告知要尽可能快地制作漂亮、实用的软件。社会对软件的无限需求确保了开发团队已经捉襟见肘，安全性不是首要考虑因素；毕竟，这不是 AppSec 专家存在的原因吗？软件工程师习惯于与安全性保持冷淡的关系——他们只有在出现问题时才听到他们的意见，而这些问题可能会阻碍他们辛勤工作的产生。
另一方面，AppSec专家厌倦了修复数十年来的错误，这些错误在每次扫描和手动代码审查中不断出现。这些专家既昂贵又稀缺，与其一遍又一遍地纠正众所周知的错误，不如将时间花在复杂的安全漏洞上。
这些团队之间存在一种不言而喻的相互指责的文化，但他们有（或应该）相同的目标：安全软件。就安全编码而言，开发人员所处的环境很少为他们提供最佳的成功机会；安全最佳实践很少作为高等教育的一部分进行教学，而且在职培训通常非常少或完全无效。人们明显缺乏对安全意识和深入的相关教育的重视，结果是修复已提交代码中的旧错误所花费的天文数字，再加上危及声誉的数据泄露的迫在眉睫的威胁。
人为因素，又名 “为什么所有这些工具都不能使我们的数据更安全？”
另一个经常出现的问题是，大量的安全工具取代了培训，其任务是在软件发布到野外之前发现问题。阵列应用程序扫描和保护工具 (SAST/DAST/RASP/IAST）当然可以帮助安全地生产软件，但它们也有自己的问题。完全依赖它们并不能保证安全性，因为：
- 没有 “一个” 工具可以扫描每个框架、每个用例中的所有漏洞
- 它们可能很慢，尤其是在串联运行以提供静态和动态代码分析时
- 误报仍然是一个问题；这些错误通常会停止生产，并且需要不必要的人工代码审查才能理解警报
- 它们造成了一种虚假的安全感，由于期望这些工具能够解决任何问题，因此取消了安全编码的优先顺序。
这些工具肯定会发现可以修补的安全漏洞，但是它们能找到所有东西吗？无法保证 100% 的命中率，攻击者只需要打开一扇门就能进入并真正毁掉你的一天。
值得庆幸的是，许多组织都意识到人为因素在起作用 软件漏洞。大多数开发人员没有接受过足够的安全编码培训，他们的整体安全意识也很低。但是，它们正处于软件开发生命周期的起点，并且处于阻止漏洞进入已提交代码的首要位置。如果他们从一开始就进行安全的编码，他们将成为抵御每年使我们损失数十亿美元的毁灭性网络攻击的前线。
开发人员需要有机会茁壮成长，培训要讲他们的语言，与他们的工作息息相关，让他们对安全产生积极的兴趣。没有错误的代码应该是一个值得骄傲的地方，就像构建一些功能强大的东西会赢得同行尊重一样。
现代安全计划应该是企业的优先事项。
开发团队无法自力更生，也无法在整个公司范围内树立积极的安全意识。他们将需要正确的工具、知识和支持，以便从一开始就将安全性纳入软件开发过程。
如果 MITRE 的清单中还显示了这么多旧的安全漏洞，那么旧的训练方法显然不起作用，所以尝试一些新的方法吧。寻找符合以下条件的培训解决方案：
- 动手实践；开发人员喜欢 “边干边学”，而不是看视频上的会说话的人
- 相关；如果他们每天都在使用 Java，不要让他们用 C# 进行训练
- 引人入胜；小规模的学习易于消化，使开发人员能够在先前的知识基础上继续发展
- 可测量；不要只勾选方框然后继续前进。确保培训有效并开辟改进途径
- 有趣；看看除了支持积极的安全文化外，如何建立安全意识，以及这如何创造一个有凝聚力的团队环境。
安全应该是组织中每个人的头等大事，首席信息安全官在各个层面都努力确保我们的数据安全。我的意思是，谁想重复听同样的老歌？现在是认真解决旧错误的时候了。
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior可以帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全放在首位的文化。无论您是 AppSec 经理、开发人员、首席信息安全官还是任何与安全相关的人，我们都可以帮助您的组织降低与不安全代码相关的风险。
预订演示
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
这篇文章最初出现在 信息安全热点，并被其他几家媒体收购。它已更新以供在此处进行联合发布。
去年年底，MITRE的神奇社区发布了他们的清单 CWE 前 25 个最危险的软件错误 这在2019年影响了世界。这份清单不是以观点为导向的，它是利用诸如此类组织的工作进行多方面分析的结果 NIST，以及公布的常见漏洞和暴露 (CVE) 数据。为了确定 “最大” 缺陷，根据其严重性、可利用性和当前软件中的流行程度来给出分数。当然，这不是那种能赢得任何积极赞誉的名单。
但是，与大多数年度总结不同，这份名单上的许多参赛者以前... 一遍又一遍地出现过。如果这是 Billboard Hot 100 排行榜，那就像 Britney Spears 的宝贝再来一次 还有 Backstreet Boys 的我想要那样 自首次发布以来，每年都会出现。那我为什么要选那些歌？好吧，他们大约二十岁了（感觉很古老了吗？），就像其中一些危险的软件错误一样，尽管在几十年前发现了这些错误，但这些错误仍然困扰着我们，直到2020年。
为什么旧错误仍然如此危险？我们不知道如何修复它们吗？
当前 MITRE 清单上的第六名是 CWE-89，俗称 SQL 注入 (SQLi)。SQLi 漏洞最早在 1998 年被发现，当时我们中的许多人仍在向 Jeeves 询问我们的迫切问题，而不是向谷歌提问。不久之后就公布了修复程序，但是，这仍然是2019年最常用的黑客技术之一。Akamai 的 互联网现状 报告显示，SQLi是三分之二的罪魁祸首 所有 Web 应用程序攻击。
就复杂性而言，SQL 注入远非天才级的漏洞。对于网络开发人员来说，这是一个简单的解决方案，而我们 做 毫不犹豫地知道如何防止此漏洞将宝贵的数据暴露给攻击者... 问题是，即使在今天，对于许多开发人员来说，安全性也不是当务之急。二十年前，这可能更容易，但是随着当今和将来开发的软件数量庞大，这再也不能成为常态了。
开发人员在损坏的系统中运行（大多数时候）。
坐视不管，责怪开发人员提供了 “不好” 的代码，实在是太容易了。事实是，他们的优先事项与安全团队的优先事项大不相同。你的普通开发团队被告知要尽可能快地制作漂亮、实用的软件。社会对软件的无限需求确保了开发团队已经捉襟见肘，安全性不是首要考虑因素；毕竟，这不是 AppSec 专家存在的原因吗？软件工程师习惯于与安全性保持冷淡的关系——他们只有在出现问题时才听到他们的意见，而这些问题可能会阻碍他们辛勤工作的产生。
另一方面，AppSec专家厌倦了修复数十年来的错误，这些错误在每次扫描和手动代码审查中不断出现。这些专家既昂贵又稀缺，与其一遍又一遍地纠正众所周知的错误，不如将时间花在复杂的安全漏洞上。
这些团队之间存在一种不言而喻的相互指责的文化，但他们有（或应该）相同的目标：安全软件。就安全编码而言，开发人员所处的环境很少为他们提供最佳的成功机会；安全最佳实践很少作为高等教育的一部分进行教学，而且在职培训通常非常少或完全无效。人们明显缺乏对安全意识和深入的相关教育的重视，结果是修复已提交代码中的旧错误所花费的天文数字，再加上危及声誉的数据泄露的迫在眉睫的威胁。
人为因素，又名 “为什么所有这些工具都不能使我们的数据更安全？”
另一个经常出现的问题是，大量的安全工具取代了培训，其任务是在软件发布到野外之前发现问题。阵列应用程序扫描和保护工具 (SAST/DAST/RASP/IAST）当然可以帮助安全地生产软件，但它们也有自己的问题。完全依赖它们并不能保证安全性，因为：
- 没有 “一个” 工具可以扫描每个框架、每个用例中的所有漏洞
- 它们可能很慢，尤其是在串联运行以提供静态和动态代码分析时
- 误报仍然是一个问题；这些错误通常会停止生产，并且需要不必要的人工代码审查才能理解警报
- 它们造成了一种虚假的安全感，由于期望这些工具能够解决任何问题，因此取消了安全编码的优先顺序。
这些工具肯定会发现可以修补的安全漏洞，但是它们能找到所有东西吗？无法保证 100% 的命中率，攻击者只需要打开一扇门就能进入并真正毁掉你的一天。
值得庆幸的是，许多组织都意识到人为因素在起作用 软件漏洞。大多数开发人员没有接受过足够的安全编码培训，他们的整体安全意识也很低。但是，它们正处于软件开发生命周期的起点，并且处于阻止漏洞进入已提交代码的首要位置。如果他们从一开始就进行安全的编码，他们将成为抵御每年使我们损失数十亿美元的毁灭性网络攻击的前线。
开发人员需要有机会茁壮成长，培训要讲他们的语言，与他们的工作息息相关，让他们对安全产生积极的兴趣。没有错误的代码应该是一个值得骄傲的地方，就像构建一些功能强大的东西会赢得同行尊重一样。
现代安全计划应该是企业的优先事项。
开发团队无法自力更生，也无法在整个公司范围内树立积极的安全意识。他们将需要正确的工具、知识和支持，以便从一开始就将安全性纳入软件开发过程。
如果 MITRE 的清单中还显示了这么多旧的安全漏洞，那么旧的训练方法显然不起作用，所以尝试一些新的方法吧。寻找符合以下条件的培训解决方案：
- 动手实践；开发人员喜欢 “边干边学”，而不是看视频上的会说话的人
- 相关；如果他们每天都在使用 Java，不要让他们用 C# 进行训练
- 引人入胜；小规模的学习易于消化，使开发人员能够在先前的知识基础上继续发展
- 可测量；不要只勾选方框然后继续前进。确保培训有效并开辟改进途径
- 有趣；看看除了支持积极的安全文化外，如何建立安全意识，以及这如何创造一个有凝聚力的团队环境。
安全应该是组织中每个人的头等大事，首席信息安全官在各个层面都努力确保我们的数据安全。我的意思是，谁想重复听同样的老歌？现在是认真解决旧错误的时候了。
这篇文章最初出现在 信息安全热点，并被其他几家媒体收购。它已更新以供在此处进行联合发布。
去年年底，MITRE的神奇社区发布了他们的清单 CWE 前 25 个最危险的软件错误 这在2019年影响了世界。这份清单不是以观点为导向的，它是利用诸如此类组织的工作进行多方面分析的结果 NIST，以及公布的常见漏洞和暴露 (CVE) 数据。为了确定 “最大” 缺陷，根据其严重性、可利用性和当前软件中的流行程度来给出分数。当然，这不是那种能赢得任何积极赞誉的名单。
但是，与大多数年度总结不同，这份名单上的许多参赛者以前... 一遍又一遍地出现过。如果这是 Billboard Hot 100 排行榜，那就像 Britney Spears 的宝贝再来一次 还有 Backstreet Boys 的我想要那样 自首次发布以来，每年都会出现。那我为什么要选那些歌？好吧，他们大约二十岁了（感觉很古老了吗？），就像其中一些危险的软件错误一样，尽管在几十年前发现了这些错误，但这些错误仍然困扰着我们，直到2020年。
为什么旧错误仍然如此危险？我们不知道如何修复它们吗？
当前 MITRE 清单上的第六名是 CWE-89，俗称 SQL 注入 (SQLi)。SQLi 漏洞最早在 1998 年被发现，当时我们中的许多人仍在向 Jeeves 询问我们的迫切问题，而不是向谷歌提问。不久之后就公布了修复程序，但是，这仍然是2019年最常用的黑客技术之一。Akamai 的 互联网现状 报告显示，SQLi是三分之二的罪魁祸首 所有 Web 应用程序攻击。
就复杂性而言，SQL 注入远非天才级的漏洞。对于网络开发人员来说，这是一个简单的解决方案，而我们 做 毫不犹豫地知道如何防止此漏洞将宝贵的数据暴露给攻击者... 问题是，即使在今天，对于许多开发人员来说，安全性也不是当务之急。二十年前，这可能更容易，但是随着当今和将来开发的软件数量庞大，这再也不能成为常态了。
开发人员在损坏的系统中运行（大多数时候）。
坐视不管，责怪开发人员提供了 “不好” 的代码，实在是太容易了。事实是，他们的优先事项与安全团队的优先事项大不相同。你的普通开发团队被告知要尽可能快地制作漂亮、实用的软件。社会对软件的无限需求确保了开发团队已经捉襟见肘，安全性不是首要考虑因素；毕竟，这不是 AppSec 专家存在的原因吗？软件工程师习惯于与安全性保持冷淡的关系——他们只有在出现问题时才听到他们的意见，而这些问题可能会阻碍他们辛勤工作的产生。
另一方面，AppSec专家厌倦了修复数十年来的错误，这些错误在每次扫描和手动代码审查中不断出现。这些专家既昂贵又稀缺，与其一遍又一遍地纠正众所周知的错误，不如将时间花在复杂的安全漏洞上。
这些团队之间存在一种不言而喻的相互指责的文化，但他们有（或应该）相同的目标：安全软件。就安全编码而言，开发人员所处的环境很少为他们提供最佳的成功机会；安全最佳实践很少作为高等教育的一部分进行教学，而且在职培训通常非常少或完全无效。人们明显缺乏对安全意识和深入的相关教育的重视，结果是修复已提交代码中的旧错误所花费的天文数字，再加上危及声誉的数据泄露的迫在眉睫的威胁。
人为因素，又名 “为什么所有这些工具都不能使我们的数据更安全？”
另一个经常出现的问题是，大量的安全工具取代了培训，其任务是在软件发布到野外之前发现问题。阵列应用程序扫描和保护工具 (SAST/DAST/RASP/IAST）当然可以帮助安全地生产软件，但它们也有自己的问题。完全依赖它们并不能保证安全性，因为：
- 没有 “一个” 工具可以扫描每个框架、每个用例中的所有漏洞
- 它们可能很慢，尤其是在串联运行以提供静态和动态代码分析时
- 误报仍然是一个问题；这些错误通常会停止生产，并且需要不必要的人工代码审查才能理解警报
- 它们造成了一种虚假的安全感，由于期望这些工具能够解决任何问题，因此取消了安全编码的优先顺序。
这些工具肯定会发现可以修补的安全漏洞，但是它们能找到所有东西吗？无法保证 100% 的命中率，攻击者只需要打开一扇门就能进入并真正毁掉你的一天。
值得庆幸的是，许多组织都意识到人为因素在起作用 软件漏洞。大多数开发人员没有接受过足够的安全编码培训，他们的整体安全意识也很低。但是，它们正处于软件开发生命周期的起点，并且处于阻止漏洞进入已提交代码的首要位置。如果他们从一开始就进行安全的编码，他们将成为抵御每年使我们损失数十亿美元的毁灭性网络攻击的前线。
开发人员需要有机会茁壮成长，培训要讲他们的语言，与他们的工作息息相关，让他们对安全产生积极的兴趣。没有错误的代码应该是一个值得骄傲的地方，就像构建一些功能强大的东西会赢得同行尊重一样。
现代安全计划应该是企业的优先事项。
开发团队无法自力更生，也无法在整个公司范围内树立积极的安全意识。他们将需要正确的工具、知识和支持，以便从一开始就将安全性纳入软件开发过程。
如果 MITRE 的清单中还显示了这么多旧的安全漏洞，那么旧的训练方法显然不起作用，所以尝试一些新的方法吧。寻找符合以下条件的培训解决方案：
- 动手实践；开发人员喜欢 “边干边学”，而不是看视频上的会说话的人
- 相关；如果他们每天都在使用 Java，不要让他们用 C# 进行训练
- 引人入胜；小规模的学习易于消化，使开发人员能够在先前的知识基础上继续发展
- 可测量；不要只勾选方框然后继续前进。确保培训有效并开辟改进途径
- 有趣；看看除了支持积极的安全文化外，如何建立安全意识，以及这如何创造一个有凝聚力的团队环境。
安全应该是组织中每个人的头等大事，首席信息安全官在各个层面都努力确保我们的数据安全。我的意思是，谁想重复听同样的老歌？现在是认真解决旧错误的时候了。
点击下面的链接并下载此资源的PDF。
Secure Code Warrior可以帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全放在首位的文化。无论您是 AppSec 经理、开发人员、首席信息安全官还是任何与安全相关的人，我们都可以帮助您的组织降低与不安全代码相关的风险。
查看报告预订演示
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
这篇文章最初出现在 信息安全热点，并被其他几家媒体收购。它已更新以供在此处进行联合发布。
去年年底，MITRE的神奇社区发布了他们的清单 CWE 前 25 个最危险的软件错误 这在2019年影响了世界。这份清单不是以观点为导向的，它是利用诸如此类组织的工作进行多方面分析的结果 NIST，以及公布的常见漏洞和暴露 (CVE) 数据。为了确定 “最大” 缺陷，根据其严重性、可利用性和当前软件中的流行程度来给出分数。当然，这不是那种能赢得任何积极赞誉的名单。
但是，与大多数年度总结不同，这份名单上的许多参赛者以前... 一遍又一遍地出现过。如果这是 Billboard Hot 100 排行榜，那就像 Britney Spears 的宝贝再来一次 还有 Backstreet Boys 的我想要那样 自首次发布以来，每年都会出现。那我为什么要选那些歌？好吧，他们大约二十岁了（感觉很古老了吗？），就像其中一些危险的软件错误一样，尽管在几十年前发现了这些错误，但这些错误仍然困扰着我们，直到2020年。
为什么旧错误仍然如此危险？我们不知道如何修复它们吗？
当前 MITRE 清单上的第六名是 CWE-89，俗称 SQL 注入 (SQLi)。SQLi 漏洞最早在 1998 年被发现，当时我们中的许多人仍在向 Jeeves 询问我们的迫切问题，而不是向谷歌提问。不久之后就公布了修复程序，但是，这仍然是2019年最常用的黑客技术之一。Akamai 的 互联网现状 报告显示，SQLi是三分之二的罪魁祸首 所有 Web 应用程序攻击。
就复杂性而言，SQL 注入远非天才级的漏洞。对于网络开发人员来说，这是一个简单的解决方案，而我们 做 毫不犹豫地知道如何防止此漏洞将宝贵的数据暴露给攻击者... 问题是，即使在今天，对于许多开发人员来说，安全性也不是当务之急。二十年前，这可能更容易，但是随着当今和将来开发的软件数量庞大，这再也不能成为常态了。
开发人员在损坏的系统中运行（大多数时候）。
坐视不管，责怪开发人员提供了 “不好” 的代码，实在是太容易了。事实是，他们的优先事项与安全团队的优先事项大不相同。你的普通开发团队被告知要尽可能快地制作漂亮、实用的软件。社会对软件的无限需求确保了开发团队已经捉襟见肘，安全性不是首要考虑因素；毕竟，这不是 AppSec 专家存在的原因吗？软件工程师习惯于与安全性保持冷淡的关系——他们只有在出现问题时才听到他们的意见，而这些问题可能会阻碍他们辛勤工作的产生。
另一方面，AppSec专家厌倦了修复数十年来的错误，这些错误在每次扫描和手动代码审查中不断出现。这些专家既昂贵又稀缺，与其一遍又一遍地纠正众所周知的错误，不如将时间花在复杂的安全漏洞上。
这些团队之间存在一种不言而喻的相互指责的文化，但他们有（或应该）相同的目标：安全软件。就安全编码而言，开发人员所处的环境很少为他们提供最佳的成功机会；安全最佳实践很少作为高等教育的一部分进行教学，而且在职培训通常非常少或完全无效。人们明显缺乏对安全意识和深入的相关教育的重视，结果是修复已提交代码中的旧错误所花费的天文数字，再加上危及声誉的数据泄露的迫在眉睫的威胁。
人为因素，又名 “为什么所有这些工具都不能使我们的数据更安全？”
另一个经常出现的问题是，大量的安全工具取代了培训，其任务是在软件发布到野外之前发现问题。阵列应用程序扫描和保护工具 (SAST/DAST/RASP/IAST）当然可以帮助安全地生产软件，但它们也有自己的问题。完全依赖它们并不能保证安全性，因为：
- 没有 “一个” 工具可以扫描每个框架、每个用例中的所有漏洞
- 它们可能很慢，尤其是在串联运行以提供静态和动态代码分析时
- 误报仍然是一个问题；这些错误通常会停止生产，并且需要不必要的人工代码审查才能理解警报
- 它们造成了一种虚假的安全感，由于期望这些工具能够解决任何问题，因此取消了安全编码的优先顺序。
这些工具肯定会发现可以修补的安全漏洞，但是它们能找到所有东西吗？无法保证 100% 的命中率，攻击者只需要打开一扇门就能进入并真正毁掉你的一天。
值得庆幸的是，许多组织都意识到人为因素在起作用 软件漏洞。大多数开发人员没有接受过足够的安全编码培训，他们的整体安全意识也很低。但是，它们正处于软件开发生命周期的起点，并且处于阻止漏洞进入已提交代码的首要位置。如果他们从一开始就进行安全的编码，他们将成为抵御每年使我们损失数十亿美元的毁灭性网络攻击的前线。
开发人员需要有机会茁壮成长，培训要讲他们的语言，与他们的工作息息相关，让他们对安全产生积极的兴趣。没有错误的代码应该是一个值得骄傲的地方，就像构建一些功能强大的东西会赢得同行尊重一样。
现代安全计划应该是企业的优先事项。
开发团队无法自力更生，也无法在整个公司范围内树立积极的安全意识。他们将需要正确的工具、知识和支持，以便从一开始就将安全性纳入软件开发过程。
如果 MITRE 的清单中还显示了这么多旧的安全漏洞，那么旧的训练方法显然不起作用，所以尝试一些新的方法吧。寻找符合以下条件的培训解决方案：
- 动手实践；开发人员喜欢 “边干边学”，而不是看视频上的会说话的人
- 相关；如果他们每天都在使用 Java，不要让他们用 C# 进行训练
- 引人入胜；小规模的学习易于消化，使开发人员能够在先前的知识基础上继续发展
- 可测量；不要只勾选方框然后继续前进。确保培训有效并开辟改进途径
- 有趣；看看除了支持积极的安全文化外，如何建立安全意识，以及这如何创造一个有凝聚力的团队环境。
安全应该是组织中每个人的头等大事，首席信息安全官在各个层面都努力确保我们的数据安全。我的意思是，谁想重复听同样的老歌？现在是认真解决旧错误的时候了。
帮助您入门的资源
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
