91APP 資安事件：5,025 天之後，技術、制度與信任的考驗

前東家 91APP 在 2026 年十月發生重大資安事件，從遭受入侵、發現異常，到調查結果對外公布，整理幾個重要的時間點：

身為曾經在 91APP 服務將近八年、離開也快四年的前員工，看到這次事件，心裡有許多感觸。一方面，從公開的事件報告中，看到了許多熟悉的處理方式與團隊文化；另一方面，站在今天的角度，也重新思考大型 SaaS 系統面臨的資安挑戰，以及還有哪些可以做得更好的地方。

這篇文章不打算評論個別人員的責任，也沒有接觸這次事件的內部調查資料，只是以一位前員工、曾經參與系統開發與維運的工程工作者，以及現在局外人的角度，紀錄一些想法。

事件處理

91APP 在 10/22 公布的 事件報告，內容包含資安事件摘要、詳細時間軸、根因分析（RCA, Root Cause Analysis）、短期防堵措施、後續改善計畫，以及消費者與品牌電商最關心的補償方案。

看到這份報告，心裡有一種非常熟悉的感覺。因為只要曾經在 91APP 經歷過 P1（Priority 1）等級的重大異常事件，大概都會對這樣的處理流程印象深刻，也能想像這段時間團隊所承受的壓力，以及各單位共同處理問題的情景。

過去在 91APP，只要發生重大系統異常，辦公室開放區通常會有一到兩面大白板，作為事件處理的資訊中心。各單位負責人站在白板前，輪流同步狀況：

什麼時間發生了什麼事、已經做了哪些處理、觀察到什麼現象、接下來需要做什麼、是否需要其他團隊協助。

這不只是單純回報工作進度，而是整個產品開發團隊共同解決問題的時刻。負責承接內外部溝通的團隊，當時主要是 Help Desk，會將這些資訊持續蒐集、整理，包含在白板上建立時間軸，彙整成可以向業務單位及其他利害關係人說明的內容。

白板上除了事件時間軸，還會有接下來需要立即處理的事項、負責單位，以及下一次同步的時間。一般可能是早上、中午、下班前各一次；遇到雙十一這類年度重大活動，晚上八點、九點也可能持續同步。依照事件嚴重程度，資訊同步的頻率還會更高。

對於經歷過幾次系統「炸鍋」的人來說，這些流程大概都不陌生。

事件處理時，團隊蒐集的是各式各樣尚未整理的資訊，有些是事實，有些是推測，也有一些後來可能被推翻。隨著調查進行，資訊會逐漸收斂，建立比較完整的事件時間軸，並找出問題的根因。最後再將這些內容轉換成可以向品牌客戶、消費者及社會大眾說明的事件報告。

這次看到 91APP 公布的內容，我很容易聯想到當年的工作場景。當然，這並不代表我知道這次內部實際如何運作，只是從報告呈現的結構與細節，看到了過去熟悉的事故處理方法。

我認為這是一種值得肯定的團隊能力。重大事件發生時，能不能把不同單位的資訊快速彙整起來、建立共同認知，並讓所有人朝相同方向行動，往往是事故處理效率的關鍵。

難與雜

這幾年軟體開發的變化非常快，AI 正在改變開發流程，提高程式撰寫、測試、問題分析與維運工作的效率。但同樣的技術，也開始被運用在資安攻擊上。

從這次 91APP 公布的事件報告，可以看到一個值得關注的現象。

根據官方報告，調查團隊在系統中發現 ARTEX 的攻擊痕跡。ARTEX 是一套 AI 自主滲透測試系統（AI Autonomous Penetration Testing System），能夠透過 AI 自動尋找系統漏洞、規劃入侵路徑，並執行相關操作。這次事件中，根據 91APP 的調查結果，攻擊者利用未及時更新的第三方工具 Appsmith 所存在的漏洞，進入內部網路，再從 GitLab 取得其中一座訂單資料庫的金鑰，最後非法存取訂單資料。

這件事反映了一個正在發生的變化。

以往要執行比較完整的滲透測試（Penetration Testing），通常需要具備一定經驗的資安專家，投入時間探索系統、分析漏洞與設計攻擊路徑。現在 AI 的加入，讓這些工作有機會變得更加自動化。從防守者的角度來看，就像面對一個可以持續工作、不斷嘗試不同路徑的白帽駭客，只不過對方未必具有善意。攻擊者可以利用 AI 提高效率，但防守方仍然需要面對既有系統的複雜性，以及日積月累的技術債。

過去我曾經在內部倡導混沌工程（Chaos Engineering）的概念，試圖在可控的條件下，主動對系統注入故障，驗證系統的可靠性（Reliability）與韌性（Resilience）。例如，刻意讓部分服務失效、模擬網路中斷，或者增加特定元件的負載，觀察整個系統能不能正確應對。如果希望進一步在正式環境（Production）執行這些驗證，就需要更嚴格的保護措施、明確的實驗範圍，以及可以隨時終止的機制。

但在以交易為核心的電商軟體公司，這樣的想法往往會被認為過於激進，因為系統一旦出錯，影響的不只是服務本身，還可能直接影響品牌客戶的營收與消費者的交易。資安檢測也有類似情況。傳統上，企業通常委託外部資安公司執行滲透測試，檢查常見漏洞，例如 OWASP Top 10 所涵蓋的風險。但這類定期檢測，也不代表能夠持續掌握所有正在變化的攻擊面。

混沌工程與滲透測試雖然是不同領域，但背後有一個共同的思維：

與其等問題發生後才知道系統的弱點，不如在可控的情況下，主動驗證我們對系統的假設。

尤其當 AI 能讓攻擊更加自動化，防守方更需要將持續驗證、漏洞管理與系統韌性納入日常工程流程。技術可以透過 AI 加速，但風險治理與責任承擔，終究還是要回到組織與團隊。

更好

好的、值得鼓勵的部分說完了，接下來也整理一些個人觀察與建議。以前 台北何先生 註一 在內部向同仁分享願景時，經常會提到一句話：「我們好，還要更好！」

這句話我一直記得。從這次公布的事件報告出發，我認為至少有三個值得進一步思考的方向。

第一個是 資安治理

官方報告提到，攻擊者透過 Appsmith 的漏洞進入內部網路，並從 GitLab 取得資料庫金鑰，進而存取正式環境的訂單資料。這裡最值得檢視的，我認為不是單一工具，而是整體資安治理架構。

GitLab 本身是軟體開發團隊常用的工具，特別是在 CI/CD 流程中，經常需要使用各種 Credential、Secret Key、Token 等敏感資訊。但這些資訊究竟應該存放在哪裡？誰有權限存取？憑證能使用多久？失效後如何更新？都是架構設計時就需要考慮的問題。

從目前公開的報告，還無法確認金鑰究竟存放在 GitLab 的 Repository、CI/CD Variables，還是其他位置，因此不能直接推論是某種特定的管理方式出了問題。

但至少有一個問題值得追問：

為什麼攻擊者取得內部系統的部分權限後，還能進一步取得正式環境資料庫的有效憑證？

我認為可以從 DevSecOps 的角度，重新檢視 Secret Management、Credential Lifecycle、Least Privilege，以及 Network Segmentation。

例如，敏感憑證可以透過獨立的 Secret Vault 或其他適當的集中管理機制處理，降低長期憑證暴露的風險。CI/CD 流程需要操作正式環境，不代表 CI 主機就應該長期擁有廣泛的資料庫存取權限。網路連線、帳號權限、憑證有效期限與操作範圍，都應該有明確限制。

更重要的是，這些不應只是在發生事故之後才補強，而應該在 架構設計與 Review 階段，就成為團隊共同遵循的安全原則。

註：更進一步則是 Zero Trust 架構，也就是所有內部系統之間的操作都需要有嚴謹的信任機制，作法像是 OAuth / OIDC / API 治理等，這部分也是我在架構部門時倡議的做法之一。

第二個是 資料預警機制

電商系統與銀行有一些相似的地方。Commerce Cloud 的核心包含訂單、會員、商品與交易等資料。這些資訊具有高度商業價值，也可能成為攻擊者想要竊取的目標。傳統資安防護常把重點放在阻止攻擊者進入系統，但我認為還有另一個同樣重要的問題：

如果攻擊者真的進來了，我們能不能及早發現資料正在被異常存取？

這就需要建立資料行為與流向的預警機制。

例如，特定服務帳號平常一天只會查詢少量訂單資料，突然開始大量查詢，這樣的行為是否能被發現？原本只需要在內部網路交換資料的服務，突然產生大量對外傳輸流量，是否應該觸發預警？或者，某些重要資料突然出現大量異常變更，是否能夠透過資料庫稽核日誌、Change Data Capture（CDC）、資料一致性檢查等機制，提早察覺？

不同問題需要不同的技術處理。資料庫的 WAL（Write-Ahead Logging）、Replication 或 Binary Log 等機制，可以協助記錄資料變更、支援復原或資料同步，但不能單靠這些機制，就判定是否發生資料外洩。要偵測大量讀取與非法擷取，仍需要資料庫存取行為監控、異常查詢分析與網路流量監控等能力。

早期我負責 Infra 工作時，就曾經建立網路隔離與 Outbound Traffic 監控機制，限制系統可以對外連線的方向，並觀察異常的資料傳輸行為。當時思考的核心，就是減少不必要的資料流動，並讓異常行為有機會被提早發現。這些方法未必能阻止所有攻擊，但能增加攻擊者的操作難度，也有機會縮短從入侵到發現之間的時間。

第三個是 事件當下的對外溝通方式 ，也是這次最容易引起討論的地方

為什麼從 10/04 首次接獲異常通報，到 10/15 開始向品牌客戶說明，中間經過了十一天？在事件尚未完全確認之前，是否可以先提供初步的風險提醒？

何英圻董事長在 10/22 的聲明 中，解釋當時選擇先查明再通知，是希望避免在資訊尚未確認時提供錯誤內容，同時也坦承，回頭來看，在 10/08 成立緊急小組時，就應該同步提醒品牌客戶。

我可以理解這個決策背後的考量。在重大資安事件中，如果沒有足夠證據就貿然公布，很容易產生錯誤資訊，甚至讓品牌客戶與消費者更加混亂。但是從另一個角度來看，資訊空白也會產生問題。時間越長，壓力鍋就越大。

這段時間，我大概有一個禮拜，每天打開 Threads、Facebook 或新聞網站，都會看到與 91APP 相關的討論。甚至有朋友在 Facebook 分享自己收到不明訂單的經驗，也有業界朋友私訊問我到底發生了什麼事，怎麼會這麼嚴重。看到這些訊息，心裡確實捏了一把冷汗。

因為當官方資訊還不夠完整時，媒體、社群、品牌客戶與消費者，都會試圖透過各自取得的片段資訊，拼湊事件全貌。而每個人拼出來的故事，可能完全不同。

資訊不完整，不代表不應該溝通；重要的是清楚區分哪些已經確認、哪些仍在調查。

有沒有比較好的做法？

其實許多大型科技公司，例如 Google Cloud、AWS、GitHub，都有對外的 Service Status 或 Incident Management Dashboard。除了呈現系統健康狀態，也會公告目前正在處理的事件、已知影響範圍、處理進度與下一次更新時間。當然，系統服務中斷與資安入侵是不同類型的事件，不能把所有調查細節直接公開。但仍然可以透過適當的分級與揭露機制，提供外界必要的風險資訊。

例如，事件初期就可以明確說明：目前接獲哪些類型的異常通報、正在調查什麼、哪些事情尚未確認、已採取哪些保護措施，以及下一次預計何時更新。

即使暫時沒有新的調查結果，也可以透過固定的更新節奏，讓品牌客戶知道事情仍在持續處理。

這次 91APP 已經建立公開的 事件說明頁面，呈現事件時間軸、目前狀態、補償方案與後續更新，這是值得肯定的做法。但如果類似的機制能夠在事件更早期就啟動，讓受影響的利害關係人持續取得可信賴的資訊，或許就能降低許多不必要的猜測與不安。

By the way，Incident Management Dashboard 這個概念，我記得大約在 2017 或 2018 年，也曾經在內部提出過，希望建立一套涵蓋團隊內部、全公司，以及對外使用者的事件資訊機制。可惜當時的我，還沒有足夠的能力與影響力，讓這件事情真正成形。如今再回頭看，感觸特別深。

誠信正直

在商業社會裡，我們經常會看到各種為了追求利益而產生的誇大宣傳、利用消費者心理的行銷手法，甚至透過去脈絡化的資訊，刻意影響大眾的認知。這些事情不只出現在商場，在生活中其實也很常見。也正因為如此，我一直認為，能夠說一是一、說二是二，有條理地陳述真實狀況，並且做到言行一致，是一件非常可貴的事。

對企業而言，尤其如此。一家企業提供的服務，往往與社會的日常生活緊密連結。不管是提供民生必需品的交易平台，還是高端晶片製造業，企業都需要對客戶、使用者與社會承擔責任。而我認為，這些責任的基礎，就是「誠信正直」。

91APP 的業務模式是 B2B2C，主要客戶是品牌企業，但服務最終接觸的，仍然是一般消費者。這代表 91APP 不只需要取得品牌企業的信任，也需要透過品牌企業，間接承擔對廣大消費者的責任。過去在 91APP 服務時，「誠信正直」就是我所認識的企業文化之一。也因此，這次事件讓我特別關注，公司如何面對調查結果、如何向外界說明，以及如何承擔後續責任。

10/22 公布的事件報告，揭露了目前掌握的攻擊路徑、事故時間軸、防堵措施，以及對品牌客戶與消費者的補償承諾。對於因這次事件遭受財務損失的消費者，91APP 也公開承諾提供補償，並與品牌客戶協商後續處理方式。我認為，願意公開說明問題、承認處理過程中的不足，以及提出具體的責任承擔，是值得正面肯定的第一步。台北何先生這次的公開說明，至少展現了願意面對問題、承擔責任的態度。

但我也認為，誠信正直不是發布一份事件報告，就能宣告完成的事。目前受影響範圍仍在調查，後續的補償、改善措施，以及主管機關的查核結果，也都需要持續追蹤。

真正的誠信，不只是願意把已知的事實說出來，更是當後續發現新的問題時，仍然願意持續公開、修正，並且負起責任。

如果這次事件最後能夠留下完整的調查紀錄、具體的技術改善，以及可信賴的後續處理成果，我認為才真正有機會成為台灣 SaaS 產業值得參考的案例。

最後

在 91APP 事件報告 的開頭，有一個很有意思，也讓我感到熟悉的數字：

10/03 日前無資安事件維持期間：5,025 天

超過五千天，接近十四年。這概念出自於電影《環太平洋》（Pacific Rim）裡的 War Clock。電影中的戰爭時鐘，用來記錄距離上一次怪獸攻擊（Kaiju Attack），已經過去了多少天、多少小時、多少分鐘。當新的攻擊發生，計時便重新開始。我記得大約在 2017 或 2018 年，91APP 內部也曾引入類似的概念，透過計時呈現距離上一次重大事件已經過去多久。

因為系統穩定運作的每一天，背後其實都有許多人在努力。不過，5,025 天這個數字本身，仍需要有明確的事件定義與起算基準，才能正確理解它代表的意義。真正重要的，或許不是計時器累積了多少天，而是當計時器歸零的那一天，團隊如何面對問題，以及未來如何重新累積信任。

91APP 是台灣具代表性的 SaaS 軟體服務公司之一。這次事件不只考驗 91APP 的資安能力，也讓整個台灣 SaaS 產業有機會重新思考，在 AI 加速改變軟體開發與資安攻防的時代，我們需要建立什麼樣的工程文化與治理制度。AI 可以協助我們更快地撰寫程式、分析日誌、尋找問題，甚至自動執行測試。但大型系統的複雜性，不會因為有了 AI 就自動消失。跨團隊的資訊落差、系統架構的歷史包袱、安全治理的盲點，以及組織在壓力之下的決策能力，仍然需要靠人持續改善。

AI 可以提高每個「點」的處理效率，但重大事件發生時，把資訊點連成「線」的，仍然需要團隊；而要將這些線拼成完整的「面」，則需要建立在彼此的信任之上。

這段時間，我沒有主動聯絡前同事，也沒有私下詢問這次事件的細節。一方面，是希望保留局外人的觀察角度，不利用過去的關係取得未公開資訊；另一方面，也是不想打擾正在處理事故的團隊。因為我很清楚，重大事故發生的當下，團隊承受的不只是技術問題，還有來自客戶、輿論，以及各方期待的壓力。

這個時候，最需要的不是沒有事實基礎的猜忌與質疑，而是讓團隊能夠專注處理問題的空間。但信任也不代表不需要檢視問題。相反地，真正的信任，應該建立在坦誠面對問題、願意接受檢視、持續改善，以及勇於承擔責任的基礎上。我期待昔日的團隊能夠從這次事件中重新站穩，也期待 91APP 能將這次經驗轉化成更成熟的資安治理與工程能力。畢竟，一家企業的價值，不只在於系統正常運作時能創造多少營收，更在於系統發生問題時，是否仍然有能力、有勇氣，對客戶與社會負責。

5,025 天的計時器已經歸零。接下來要重新累積的，不只是沒有事故的天數，還有客戶、消費者與社會對這家企業的信任。

  • 註一：91APP 同仁私下稱呼這樣叫何董 - “台北何先生”
  • 註二：本文依截至 2026/10/23 已公開的資料整理，事件調查與後續處理結果仍應以正式公告為準。

Comments

▲ TOP ▲