当像 CrowdStrike 失败这样的事件确实让世界陷入崩溃时，有很多东西需要解开。为什么会发生这样的事？它是怎么发生的？它可以被阻止吗？
在我们每周播客的最新一集 What the Dev? 中，我们采访了测试公司 Parasoft 的首席布道师 Arthur Hicken，讨论了所有这些以及我们是否会从该事件中吸取教训。
以下是该对话的编辑和删节版本：
AH：我认为这是现在的关键主题：没有吸取的教训——并不是说我们已经足够长的时间来证明我们没有学到任何东西。但有时我会想，“哦，这将会是一个问题，或者我们会变得更好，我们会把事情做得更好。”而其他时候，我会回顾 Dijkstra 在 70 年代的言论，走吧，也许我们现在不会学习。我最喜欢的 Dijkstra 名言是“如果调试是从软件中删除错误的行为，那么编程就是将错误放入其中的行为。”这是一个很好、有趣的说法，但我认为这也是 CrowdStrike 出现的重要问题之一的关键。
我们现在有这种心态，它有很多不同的名称——快速失败、快速运行、快速突破——这在原型时代或者在失败发生时一切都无关紧要的地方当然有意义。显然，这很重要。即使玩电子游戏，你也可能会损失很多钱，对吗？但当电子游戏因为更新不当而损坏时，你通常不会杀人。
《SD Times》主编大卫·鲁宾斯坦 (David Rubinstein)：您谈到我们如何不断遭遇这些灾难性的失败，而我们却始终没有从中吸取教训。但它们在某些方面是不是都有些不同，就像您认为 Log4j 会是人们现在肯定会更加关注的东西一样。然后我们得到了 CrowdStrike，但它们并不是同一类型的问题？
AH：是的，确实如此，我想说，Log4j 有点阴险，部分原因是我们没有意识到有多少人使用这个东西。日志记录是不太令人担心的主题之一。我认为 Log4j 和 CrowdStrike 有一个相似之处，那就是我们在构建软件时变得自满，而不了解质量的严格性，对吗？对于 Log4j，我们不知道是谁构建的、出于什么目的以及它适合什么。对于 CrowdStrike，也许他们并没有真正考虑过如果您的防病毒软件让您的计算机崩溃怎么办？如果该计算机正在为医院或 911 服务或类似的事情进行调度怎么办？
因此，我们看到的是，安全关键系统正在受到从未考虑过的软件的影响。需要考虑的事情之一是，我们能否从如何构建安全关键软件或我喜欢称之为好的软件中学到一些东西？软件应该可靠、健壮、能够在恶劣条件下运行。
我认为这是一个非常有趣的观点。按照更好的标准构建软件会对 CrowdStrike 造成伤害吗？答案是不会。我认为，如果他们构建更好的软件，速度就不会受到负面影响，而且他们会花更少的时间测试和查找东西。
DR：您谈论的是安全关键，您知道，在过去，这似乎是他们所说的真正不会失败的嵌入式系统的范围。他们驾驶着飞机、医疗设备以及那些真正关乎生死的事情。那么，其中一些原则是否有可能被延续到今天的软件开发中呢？或者您是否需要拥有那些特定的 RTOS 来确保这种事情？
AH：对于适当的硬件和软件堆栈来说，确实有一些话要说。但即使没有这个，您拥有没有可供选择的操作系统的标准笔记本电脑，您仍然可以构建强大的软件。我的另一台显示器上有一个几年前与 CERT 联合举办的网络研讨会的幻灯片，我们在那里使用的一项研究表明，NIST 中 64% 的漏洞都是编程错误。其中 51% 是他们所谓的经典错误。我将我们刚刚在 CrowdStrike 中看到的视为一个典型错误。缓冲区溢出、读取已初始化事物上的空指针、整数溢出，这些就是他们所说的经典错误。
他们显然产生了效果。我们无法完全了解出了什么问题，对吗？我们得到他们告诉我们的内容。但似乎存在由读取配置文件引起的缓冲区溢出，并且人们可以争论防止缓冲区溢出的工作量和性能影响，例如关注每一条数据。另一方面，缓冲区溢出在该代码中存在了多长时间？对我来说，您必须检查一段响应任意配置文件的代码。你只需要检查一下。
这个让我彻夜难眠的问题，就像我是 CrowdStrike 团队的一员一样，没关系，我们找到它，我们修复它，然后就像，这个确切的问题还有哪里？我们是否要去寻找仅因外部输入而暴露的代码中的 6 个其他或 60 个其他或 600 个其他潜在错误？
DR：其中有多少归结为技术债务，这些东西一直存在于代码中，永远不会被清理，而这些东西只是建立在它们之上？现在我们所处的环境是，如果开发人员实际上希望消除这种情况而不是编写新代码，他们就会被视为生产力低下。其中有多少是导致我们遇到的这些问题的原因？
AH：这是我们目前关于什么是技术债务的普遍看法的问题，对吧？我的意思是，最初的比喻是可靠的，即你正在做的愚蠢的事情或你现在没有做的事情将会在未来困扰你。但简单地运行某种静态分析器并调用每个未处理的问题技术债务是没有帮助的。并不是每个工具都能找到尚不存在的缓冲区溢出。当然有静态分析器可以寻找允许或强制不允许缓冲区溢出的设计模式。换句话说，寻找是否存在尺寸检查。当人们处理技术债务时，这些事情往往被称为误报。好的设计模式几乎总是被开发人员视为误报。
再说一遍，我们必须改变我们的思维方式，我们必须构建更好的软件。道奇曾说过，我认为那是 20 年代，你无法测试产品的质量。软件行业的心态是，如果我们多测试一点，我们就能以某种方式找到错误。有些事情是很难防范的。缓冲区溢出、整数溢出、未初始化内存、空指针取消引用，这些都不是火箭科学。
您可能还喜欢……
从 CrowdStrike 发布软件更新中断中汲取的经验教训
软件测试的混乱难题：解决速度、质量和成本的三体问题
问答：解决过时功能标志的问题
