一個你方無人審查過的檔案，讓 850 萬台電腦當機
2024 年 7 月 19 日早餐時，一位在一家中型航空公司負責安全的朋友傳了一張照片給我。那是一塊航班資訊看板，只不過每一格都是同一種藍色，同樣的白色錯誤文字在整個航廈的一格又一格上重複出現。他沒有附上任何文字。他不需要。
等我喝完咖啡時，這個數字已經是 850 萬台 Windows 電腦，在不到九十分鐘內全部當機。不是惡意軟體，不是零時差漏洞，而是 CrowdStrike 的一次例行內容更新——那些公司正是花錢請這家廠商來保護自己安全的。本該保護端點的東西，反倒把它們變成了磚頭。
從那之後，我一直在建構本該存在於這些廠商與這些機器之間的那一層——我們現在稱之為軟體更新部署完整性，也就是在廠商的更新管線與你的生產環境機群之間設立的一道獨立檢查關卡。這篇文章要談的是：為什麼這一層當時並不存在、為什麼看似顯而易見的建構方式其實是錯的，以及當那塊藍色看板亮起的那一刻，每一家運行核心層級代理程式的企業腳下究竟有什麼改變了。
第 21 個欄位
這份 CrowdStrike 外部根本原因分析在 2024 年 8 月發佈的那晚我就讀了，而其成因之小，幾乎到了侮辱人的地步。
Falcon 是 CrowdStrike 的感測器，它透過一套稱為「快速回應內容」（Rapid Response Content）的機制來派送偵測邏輯——這是一些小型設定更新，讓它無需推送整個新二進位檔就能因應新威脅。7 月 19 日，它派送了兩個新的範本實例（Template Instance），用於行程間通訊（IPC）偵測。這些實例引用了第 21 個輸入參數。CrowdStrike 雲端的內容驗證器依照新的 21 欄位結構描述檢查了這次更新，判定有效，於是予以核可。
問題出在運行於 Windows 核心內、位於 Ring 0（作業系統中權限最高的一層）的內容解譯器。它仍然預期只有 20 個欄位。當它去存取第 21 個欄位時，讀到了根本不存在的記憶體，機器隨即立刻出現藍色當機畫面。
一個雲端驗證器依照新規則核可了一次更新。收到更新的核心卻仍然依循舊規則在運作。沒有人在檢查這兩者是否一致。
身為工程師，最讓我耿耿於懷的是接下來這一部分。當機發生在開機序列非常早的階段，以致 Falcon 自己的管理代理程式根本還沒啟動。所以那些端點無法接收 CrowdStrike 推送出去的回滾指令，因為本該接收那道指令的軟體，正是那個讓機器當機的東西。業界對此有個陰森的名字——「死代理迴圈」（dead-agent loop）。復原不是按個按鈕就好。而是要有真人守在每一台機器旁，開機進入安全模式、導覽至C:\Windows\System32\drivers\CrowdStrike\，然後手動刪除那個有問題的C-00000291-*.sys檔案。達美航空（Delta）在 40,000 台伺服器上都這樣做了一遍。復原花了五天。
這件事從來就不只關乎某一家廠商
簡單的說法是 CrowdStrike 太粗心。這也是個錯誤的教訓，而追逐這個教訓會讓我打造出錯誤的產品。
因為這個模式並不是 CrowdStrike 獨有的。調出任何一家大型企業的端點清單，你都會發現有八到十二個代理程式運行在核心層級或擁有提升的權限——EDR 代理、資料外洩防護代理、加密代理、修補代理、VPN 用戶端、裝置管理代理。試算表上八列，就是八條各自獨立的更新通道，每一條依自己的排程推送，每一條都被放行通過。
那年夏天我不斷問資安長（CISO）同一個問題：在這些廠商更新進入生產環境之前，是誰在審查？每一次得到的答案，都是某種版本的我們有一個變更諮詢委員會。然後，過了一拍之後，才是誠實的部分：變更諮詢委員會會逐行審查內部部署，但廠商更新卻略過工單佇列、略過預備環境，直接送到每一個端點——因為「我們信任這家廠商」。這句話撐起了整個產業的重量，背後卻沒有任何機制。
還有第二種失效模式幾乎沒有人談，而它更難診斷。當兩家廠商在同一天更新核心介面時，它們的驅動程式可能相互衝突，產生與單一廠商漏洞一模一樣的藍色當機畫面。只不過現在的根本原因分析要花上數週而非數小時，因為你得在兩家廠商支援團隊之間三角定位，而他們各自——也合情合理地——把責任推給對方。
我們最先打造的那個版本，以及它為何失敗
剛開始時，我很確定答案就是「偵測」。監看端點、學會正常長什麼樣子，然後在更新一開始出狀況的瞬間就大聲示警。這是整個可觀測性市場訓練我們養成的直覺——Datadog、Dynatrace、Splunk，全都極其擅長告訴你剛剛發生了什麼。
我們打造了那樣的一個版本。我們拿它去對照一次更新導致的失效重播來測試。它確實有效，只是以最沒用的方式有效：它把問題捕捉得漂漂亮亮，卻是在頭幾台機器已經倒下之後。
我記得結論成形的那通電話。一位試點的資安長看著我們的儀表板在模擬的錯誤推送發生幾秒後亮成一片，大致上說：他不需要一個更快知道自己已經著火的方法。他需要的是這次更新一開始就永遠不會同時抵達他所有的端點。對於一個九十分鐘就能擊垮 850 萬台機器的失效來說，部署之後才偵測，就像是等房子燒沒了才響一次的煙霧警報器。
可觀測性告訴你大樓正在燒。到那時候，剩下的唯一問題就只是重建要花幾天。
那個月我暗暗把整項工作押在了錯誤的一層上，而看著那個儀表板證明了這一點，是我們遇上過最有用的事。問題從來就不在於偵測的速度。而在於在更新抵達之前，根本沒有一道檢查關卡。
那麼，為什麼現有的工具抓不到這種情況？
人們以為軟體供應鏈安全早就涵蓋了這一點。並沒有，而原因很精確。
SBOM 與軟體組成分析工具——Snyk、Sonatype——稽核的是你的開源相依關係樹。它們的用途是告訴你某個往下三層的 npm 套件有已知漏洞。但廠商的快速回應內容、一個通道檔、一團由 CrowdStrike 或任何同儕廠商簽署並推送的專有設定檔——對它們而言是看不見的。它並不在你的相依關係樹裡。它是繞過它，直接推進核心的。那些本該保護你軟體供應鏈的工具，稽核的完全是錯誤的一層。
ITIL 和你的變更諮詢委員會呢？那是程序性的。它們是為你自己發起的變更所設計的檢查清單與核可流程，從來就不曾與廠商的發佈節奏接通。
至於 CrowdStrike 自己的補救措施——自我復原模式、內容釘選、分階段的「客戶部署控制」、以及一套借鑑自 CISA 的「以韌性為設計核心」（Resilient-by-Design）框架——確實是實在的工作，我並不輕視。但看清它實際上是什麼：這些控制措施每一項都是廠商自我監管。當初派送第 21 個欄位的，正是如今出面認證它現在很安全的那同一家公司。在廠商的推送與你的端點之間，仍然沒有任何獨立的第三方站在那裡。事件過後那一季，CrowdStrike 的總留存率仍在 97% 以上，這告訴你市場並沒有懲罰它們——但對於底層那道缺口是否已經彌合，卻什麼也沒說明。它並沒有。
那道缺口就是整個產品所在。正確的立足點既不在端點上盯著火苗，也不在廠商內部聽信他們的一面之詞。而是在兩者之間：一道廠商中立的檢查關卡，在更新抵達生產環境之前先把它攔下，讓它跑過一個鏡像你真實機群的沙箱、比對其內容是否符合你的核心實際預期的內容、並在它有錯時對其波及範圍進行建模。這就是我們最終打造出來的那一層，你可以在我們的解決方案頁面上看到它的樣貌。像 21 對 20 欄位這種結構描述不符的漏洞，正是一個部署前沙箱會在金絲雀環境（canary ring）中就浮現出來的那類問題，而不是一次同時擴散到 850 萬台機器上。
法律的基礎已經移動，而大多數合約還沒跟上
有一陣子我把法規這一面當成背景雜訊。我錯了，而買家們讓我明白了原因：他們抽屜裡的那些合約，已經不再像他們以為的那樣保護著他們。
先從達美航空訴 CrowdStrike 一案（Delta v. CrowdStrike）說起。2025 年 5 月，在富爾頓郡高等法院，艾勒比法官（Judge Ellerbe）裁定重大過失、電腦侵入與不作為詐欺等訴求可以繼續進行——越過了CrowdStrike 的合約責任上限。其中電腦侵入這一項，是應該讓每一位資安長都坐直起來的：達美航空已經選擇退出自動更新，那個通道檔卻仍然抵達了核心。如果一家廠商能夠透過一條你的設定管不到的通道推送 Ring 0 內容，那麼你合約中的更新偏好設定就可能形同無法執行。大多數企業的主服務協議（MSA）甚至根本不區分一次完整的感測器更新和快速回應內容。它們理應區分。
接著歐盟出手了，而這正是我如今在每一場合約重談中都會提出的部分。修訂後的《產品責任指令》現在明確將軟體歸類為嚴格責任下的「產品」，並規定各公司不得以合約排除軟體與網路安全瑕疵的責任。你的廠商在合約裡圈起來的那個個位數百萬的責任上限，在歐盟司法管轄區內可能根本站不住腳。與此並行的是，歐盟《網路韌性法案》（Cyber Resilience Act）將於 2026 年 9 月 11 日起強制要求通報漏洞——一個 24 小時的計時器，而關鍵在於，它是從你知情時開始計時，而不是從廠商通知你時開始。一家廠商的服務中斷，可能很快就變成你的通報義務。
而在美國，美國證券交易委員會（SEC）現在要求上市公司在四個工作日內揭露重大的網路安全事件，並在其 10-K 申報文件中描述軟體供應鏈風險。拿成本數據來算一算：New Relic 於 2025 年 9 月發佈的研究，把重大 IT 停機的中位數成本定在每小時 200 萬美元，而 41% 的中大型企業，把自家的數字定在每小時 100 萬至 500 萬美元之間。一次源自你的變更委員會從未見過的廠商更新、長達四小時的服務中斷，光憑自身就足以跨過重大性門檻。你的投資人關係團隊需要的是一套廠商停機的應變劇本，而不只是一套資料外洩的應變劇本。
一次源自你方無人審查過的更新、長達四小時的服務中斷，以中位數計約達 800 萬美元——這種數字落到的是財務長（CFO）的桌上，而不是資安長的。
「這會發生在我們身上嗎？」
2024 年 7 月之後，全世界每一個董事會都拿這幾個字問了自家的資安長。而我談過的那些資安長，大多拿不出一個有條理的答案——這並不是在苛責他們。IANS Research 在 2026 年初的數據發現，只有 29% 的董事認為自家資安長的安全報告「非常有效」，而更新部署風險正是那種既真實、又昂貴、又幾乎不可能用大多數團隊手上的工具量化出一個數字來的東西。
那是我們所打造之物中較安靜的一半。不只是那道技術上的檢查關卡，更是那個能把「這會不會發生在我們身上」轉化為一個董事會可用答案的東西：一份列出每一個特權代理程式及其更新通道的清冊、一個按廠商區分的量化波及範圍模型、一份記錄了哪些更新經過沙箱測試、以及它們在其中做了什麼的紀錄。它把一張過去寫著「我們信任我們的廠商」的簡報，轉換成一張把工作實績攤開來看的簡報。
有人問我，既然微軟正在把安全廠商推出核心之外——也就是《Windows 韌性計畫》（Windows Resiliency Initiative），搭配快速機器復原（Quick Machine Recovery），以及端點安全從核心模式逐步移轉到使用者模式——這件事現在是否還真有必要。這確實是一次貨真價實的良性結構性轉變，隨著時間它也會縮小最糟情況下的波及範圍。但這個時程要橫跨 2026 與 2027 年，在移轉期間你會有一整段時間都在運行一個混合機群，而「災難性降低」並不等於「已獲驗證」。一個使用者模式的代理程式若派送了一個錯誤的設定，仍然可以把它所負責的東西弄垮。獨立檢查的必要性，並不會因為核心退場而消失；它只是往上移了一層。
人們另外會說的一點是，加上一道檢查關卡會拖慢一切——快速回應內容的全部重點就在於面對即時威脅時的速度。有道理。但這個抉擇從來就不是速度對安全。CrowdStrike 的雲端驗證器跑得很快，卻仍然核可了那個損壞的更新，因為它只依照新的結構描述檢查了那個檔案，而從未檢查核心是否也認同。速度並不是失敗之處。缺少一道獨立檢查才是。一個在 30 台機器上就抓出結構描述不符的金絲雀環境，只花你幾分鐘。另一個選項卻讓達美航空付出了五天與 5.5 億美元。
那塊藍色看板究竟意味著什麼？
我一再回想起朋友拍的那塊航班資訊看板的照片。有那麼一個早晨，每一家企業所身處其中的那個抽象概念——我們信任的廠商保護我們的安全——被以字面上的藍色呈現了出來，一格接著一格，就在一棟擠滿了進退不得的旅客的建築裡。
那些廠商並不是因為魯莽而失敗。它們之所以失敗，是因為我們集體打造出了一個產業——在這個產業裡，一家供應商的一個設定檔就能同時抵達每一個端點，而沒有任何獨立的第三方在核對那筆帳。CrowdStrike 只是那個號碼剛好被抽中的。而讓這一切得以發生的那套結構，此時此刻，就坐落在你叫得出名字的幾乎每一家公司的端點清單裡——八到十二個特權代理程式、八到十二條通道，中間沒有任何人。
你可以在這裡讀到我們所打造之檢查關卡的完整架構。但我想讓一位資安長帶走的那一部分，比任何產品都更簡單。下一次這種等級的服務中斷，不會以安全事件的姿態自報家門。它會帶著簽章、帶著信任、帶著核可抵達——就跟上一次一模一樣。唯一能改寫結局的，是有人站在推送與生產環境機群之間，趕在全部 850 萬台機器同時發現之前，核對那次更新與那台機器是否仍然一致。
