重點摘要
- 過去的一次重大漏洞事件中，我們在評估後當晚完成客戶網站的修補，隔天報告時卻被問：「為什麼沒先報告就升級？」「真的有需要做到這樣嗎？」
- 這兩個問題都合理，背後是客戶對知情權與成本效益的正當關切。但重大漏洞的攻擊窗口是以小時計算，等待確認的時間就是攻擊者的時間。
- 這次對話讓我們學到：緊急處置的授權應該在事前談好，而不是事發時才討論。本文分享我們的判斷依據、若延誤可能發生什麼，以及企業該如何與維護廠商約定。
一個真實的經驗：重大漏洞修補後，客戶反而質疑
這次事件讓我們想起過去一段經歷：一個重大漏洞公告發布，影響範圍涵蓋我們維運的一個網站。那個網站屬於公眾服務性質，流量高、能見度高，一旦出事影響的不只是客戶本身。
團隊依照公司的 ISO/IEC 27001 變更管理程序評估：漏洞等級為重大、可被遠端利用、公開資訊顯示攻擊手法已在流傳、而該網站的暴露面不小。評估結果是啟動緊急變更，當晚備份、升級、驗證，隔天一早向客戶提交報告。
客戶的回應出乎我們意料。不是感謝，而是兩個問題：
「為什麼沒有先告訴我們就直接升級？」 「真的有需要做到這樣嗎？」
當下的心情是複雜的。但事後回想，這次對話是我們在客戶溝通上學到最多的一次。這篇文章不是要說明誰對誰錯，而是想把當時沒能在第一時間說清楚的事，完整地說一次。
客戶對緊急修補的質疑合理嗎？
合理，而且重要。客戶對緊急修補的兩個質疑，背後是知情權與成本效益判斷這兩個正當需求。
第一個問題關乎知情權。網站是客戶的資產，任何變更都可能影響他們的業務。客戶有權知道自己的系統發生了什麼事，更有權在重大決策前被徵詢。「先斬後奏」在多數商業關係中都不是好的做法。
第二個問題關乎成本與風險的判斷。客戶沒有資安背景，看到的是「一個深夜緊急作業」，而不是「一個 CVSS 9 分的遠端程式碼執行漏洞」。他們需要的不是結論，而是判斷依據：這個漏洞有多嚴重？不處理會怎樣？為什麼不能等到明天開會討論？
這兩個問題我們當時都有答案，但沒有在事前讓客戶知道「遇到這種等級的事件，我們會這樣處理」。這才是問題的核心。
為什麼重大漏洞的窗口期是以小時計算？
要回答「真的有必要嗎」，得先理解現代漏洞攻擊的節奏。
一個重大漏洞從公告到遭大規模利用，通常經過幾個階段：官方公告與修補發布、研究人員或攻擊者分析修補內容反推漏洞、概念驗證程式（PoC）出現、攻擊者將 PoC 自動化並對全網掃描、大規模入侵。十年前這個過程可能需要數週，現在經常壓縮在 24 到 72 小時內，有時更短。
以 2026 年 10 月的 PHP2Shell 事件為例，CVE 編號在 10 月 20 日提前外洩，官方被迫提前至 10 月 21 日發布修補，發布當天 Cloudflare 便表示觀測到針對該漏洞的攻擊流量，英國國家網路安全中心更建議無法立即修補的系統考慮暫時下線。從修補發布到攻擊出現，中間不到一天。我們在〈PHP2Shell 與 Node.js 高風險漏洞同日爆發〉一文中有完整紀錄。
更關鍵的是，攻擊者不會挑目標。自動化掃描工具會對整個網際網路上所有符合特徵的主機發動嘗試，你的網站不會因為「規模不大」或「沒有什麼值得偷的」而被跳過。一個網站是否被攻擊，取決於它有沒有漏洞，而不是它重不重要。
所以「等明天開會再決定」的代價，是把網站暴露在已知、可被自動化利用的漏洞下 12 到 24 小時。對重大等級的漏洞來說，這段時間足以讓事情發生。
若未及時處置，可能發生什麼？
遠端程式碼執行（RCE）是最嚴重的漏洞類型，因為它讓攻擊者能在你的伺服器上執行任意指令。從這一點出發，可能的後果包括：
- 植入後門：攻擊者放置 Web Shell，即使之後修補漏洞，後門仍然存在，可隨時回來。
- 資料外洩：資料庫中的會員資料、交易紀錄、內部文件被複製帶走。對持有個人資料的網站而言，這可能觸發個人資料保護法的通報義務與法律責任。
- 網站竄改：首頁被置換、植入惡意連結或釣魚頁面、被用來散布惡意程式。對公眾服務網站而言，這直接傷害的是機構的公信力。
- 成為跳板：受害主機被用來攻擊同一網段的其他系統，或對外發動攻擊，讓你的 IP 被列入黑名單。
- 服務中斷與復原成本：清除後門、重建系統、鑑識調查、法律程序、對外說明。這些成本通常是修補成本的數十倍以上，而且還不包括聲譽損失。
我們不是要製造恐慌，而是想說明：當我們評估「要不要半夜動手」時，天平另一端放的是這些東西。
我們是怎麼依 ISO/IEC 27001 決定「先修再報」的？
這個決定不是臨時起意，而是依公司 ISO/IEC 27001 資訊安全管理制度中的變更管理程序走完的。緊急變更（Emergency Change）在制度中有明確定義與流程，不是「工程師覺得該修就修」。
判斷是否啟動緊急變更，我們會看幾個條件是否同時成立：
- 漏洞等級為 Critical 或 High。
- 可被遠端利用，且不需要身分驗證。
- 公開資訊顯示概念驗證程式已流傳，或已有在野攻擊的跡象。
- 客戶系統的暴露面與影響範圍足以構成實質風險。
條件成立後，處置本身也有程序：完整備份與快照、擬定回復方案、選擇對業務影響最小的時段、升級後依固定清單驗證、全程留存紀錄。這些程序的目的，正是讓「快」不等於「草率」。
換句話說，我們不是跳過了評估直接動手，而是評估的結論就是「現在動手比等待更安全」。只是這個評估過程，客戶在事前並不知道。
這次對話讓我們改變了什麼：把緊急處置授權寫進合約
那次之後，我們把緊急處置的授權等級、通報時限與報告格式寫進了與客戶的合作約定裡，具體是四件事。
事前取得授權，而不是事後解釋。 在維護服務開始時，就與客戶約定：哪些等級的漏洞允許我們先行處置、處置後多久內通報、通報內容包含什麼、客戶若希望任何變更都事前確認則需承擔的風險為何。這讓「先修再報」從單方面的判斷變成雙方的共識。
事前讓客戶理解風險分級。 在平時的溝通中，就讓客戶知道漏洞有等級之分，大部分的更新可以排程、可以討論，但極少數的重大事件需要立即反應。當客戶對「重大」有概念，事發時就不需要從頭解釋。
事後通報有固定格式。 每一次緊急處置的報告都包含：發生了什麼、我們的評估依據、做了什麼、驗證了什麼、客戶需要做什麼、後續追蹤事項。這也是 ISO/IEC 27001 要求的佐證留存，一份報告同時服務客戶溝通與稽核需求。現在這些報告的初稿由 AI 工作流依專案類型產生、工程師審核後送出，做法在〈資安團隊如何靠 AI 工作流做到第一時間反應〉有說明。
把溝通也當成處置的一部分。 修補完成不代表事件結束，客戶理解並安心才算結束。所以現在我們會依專案的規模與性質，決定用訊息、書面報告或會議來說明，而不是一律發一封信了事。
回頭看，那位客戶的質疑是對的：我們的技術判斷沒有問題，但溝通設計有缺口。這個缺口後來補上了，也成為我們今天服務流程的一部分。我們的創辦人在〈團隊一夜修完 25 個專案，我卻不想談速度〉一文中，從經營者的角度談了為什麼「先處置、後通報」必須是制度而不是膽識。
給企業負責人的建議：如何與維護廠商約定漏洞處置
如果你的網站或系統交由外部廠商維護，以下幾件事值得現在就確認：
- 合約裡有沒有緊急處置條款？ 明確約定重大漏洞的處置權限、通報時限與格式。沒有的話，現在就補。
- 你知道自己的系統用了哪些版本嗎？ 至少要知道 PHP、Node.js、CMS、框架的版本，以及它們的支援終止日。
- 你的廠商有主動監控漏洞公告嗎？ 問他們：「上一次重大漏洞公告時，你們多久之後通知我？」如果答案是「等你問才知道」，這是警訊。
- 重大漏洞不要等開會。 若你收到廠商的緊急處置通知，優先確認「修了什麼、驗證了什麼」，而不是「為什麼沒先問我」。該問的是事前的授權設計，不是事發時的反應速度。
- 要求紀錄。 每次處置都應該有書面紀錄，這是你的資產，也是稽核與保險的依據。
常見問題
維護廠商在沒有通知的情況下更新我的網站，合理嗎？ 視事前約定與漏洞等級而定。對重大漏洞而言，等待確認的時間就是風險暴露的時間，業界普遍做法是在合約中授權廠商先行處置、事後限時通報。如果合約沒有約定，建議盡快補上，而不是事後爭論。
漏洞嚴重程度怎麼判斷？ 常見依據是 CVSS 評分，9.0 以上為 Critical，7.0 到 8.9 為 High。但實務上還要看是否可遠端利用、是否需要身分驗證、是否已有公開攻擊程式，以及你的系統暴露程度。
小網站也會被攻擊嗎？ 會。攻擊者多以自動化工具對全網掃描，目標是「有漏洞的主機」而不是「重要的主機」。小網站被入侵後常被當成跳板或用來散布惡意程式。
ISO/IEC 27001 的變更管理會拖慢緊急修補嗎？ 不會，前提是制度中有定義緊急變更程序。制度提供的是評估標準與行動框架，讓緊急狀況下的決策有依據，反而能加快判斷。
升級後網站出問題怎麼辦？ 合格的緊急變更程序一定包含備份與回復方案。升級前完整備份或快照，升級後依清單驗證，若有問題可回復或現場修正。這也是為什麼要選在離峰時段執行。
需要協助嗎？
如果你不確定自己的維護合約是否涵蓋緊急處置，或希望有人協助盤點系統版本與風險，歡迎預約諮詢。影響視覺科技的資安團隊可協助企業建立弱點管理與變更管理流程，以及 ISO/IEC 27001 的建置與導入。