Crowdstrike Incident Root Cause Analysis
赛博崩溃 #
2024年7月19日，由于CrowdStrike部署了有bug的代码到其客户的主机上，导致了大量Windows电脑蓝屏，很多系统崩溃（美国航空尤其受影响）。
原因其实很简单，在新部署的CrowdStrike Falcon传感器中，Content Interpreter在实际只提供了20个值的情况下，试图访问一个不存在的第21个输入值，导致系统崩溃。
程序员写bug不可避免，但是这次CrowdStrike事件Blast Radius太大了，几乎是同一时间全球影响。看了一下Crowdstrike发布的分析，感觉里面的6个"FINDINGS AND MITIGATIONS" 比较有意思所以想简单聊聊这6点。
FINDINGS AND MITIGATIONS #
1. The number of fields in the IPC Template Type was not validated at sensor compile time
“Validate at compile time” 我的理解就是unit tests。这是所有测试的第一步，如果一个接口需要21个值，那么就应该有一个unit test如果提供了不是 21个值的输入，要报错。这样每次编译的时候如果有这个bug就会直接编译失败。感觉程序员都不太喜欢写unit tests（包括我自己），我有时候会很气愤，有人会单纯为了coverage写一些完全没有用的unit tests，而不是去检查是不是真的有逻辑错误。
2. A runtime array bounds check was missing for Content Interpreter input fields on Channel File 291
刷leetcode面试题大概都知道要考虑corner case，而访问没有allocate的内存区域是大忌，array bounds check算一个很常见的要考虑的东西。
3. Template Type testing should cover a wider variety of matching criteria
文章说之前的测试都是用的正则表达式，所以没有发现bug。而解决方法提出来的是提高测试coverage。😂如果让我猜，用正则表达应该就是为了偷懒，虽然后文还有提到用正则表达是因为第21个数值可能性有很多种， 但至少还是应该要有一个完整的输入做为测试例子。 提高测试coverage应该指要真正cover更多实际运用中的corner cases。
4. The Content Validator contained a logic error
简单来说就是Validator本身逻辑有问题，有bug。
5. Template Instance validation should expand to include testing within the Content Interpreter
文章说Validator没有发现input数值不一样会导致系统崩溃，但没有提供细节为啥没有发现。我猜测是不管Integration Test还是Canary都没有做到end to end。整个测试并没有完全模仿客户的整个操作流程。
6. Template Instances should have staged deployment
这个是我太惊讶的地方了，整个rollout是全球一次性的。正常来说我们release新版本的时候都应该一个阶段一个阶段来发布。如果只有一个Stage，一旦有重大bug， Blast Radius太大了。
感觉CrowdStrike本身也很难做，毕竟他的服务是防止系统被攻击，如果有新病毒或者新漏洞，客户肯定希望CrowdStrike能尽快发布新的补丁保护系统。
速度与风险的权衡，至少我认为2-3个阶段是必须的，不然风险太大。
CrowdStrike针对这点提了一个有点新颖的观点，把Staged Deployment的责任交给客户，如果客户有一组机器用他们的服务，让客户决定什么时候，以多快的速度进行deployment。
很好奇你觉得哪点最不可思议或者最严重呢？😯