PSIRT 成立的第一個月，一定會有人問你一句話：

「那你們到底修不修？」

這題答錯，團隊三個月後就會垮。而多數人第一次會答錯，因為「我們修」聽起來比較負責任。

三種模型，各自會壞在哪

三種都會壞，差別在壞得快不快、救不救得回來。

集中式壞得最快。一台工業電腦裡有作業系統、開機韌體、網路堆疊、驅動、開源函式庫，再往下還有晶片商給的 BSP。要中樞把這些全部修過一輪，需要的已經不是人力的問題，是分身術。

分散式壞得最安靜。每個團隊各自都做得不錯，但沒有人在看那個 24 小時的時鐘。等你發現漏送，已經是市場監管機關來信的時候。

混合式壞得最慢，所以它是唯一活得下來的。代價是界線要天天守。

順序也不能顛倒。研判必須在中樞，因為只有中樞看得到全部產品；修補必須在產品團隊，因為只有他們知道那段程式碼為什麼長那樣。把這兩件事對調的組織我看過，結果是研判做得很淺、修補做得很慢，兩邊都不到位。

中樞一接修補，會發生什麼

四件事，照順序發生。

**第一，研判開始排隊。**修補的工時通常是研判的好幾倍，而且不可預測。今天接一件，這週的研判就往後推。

**第二，時鐘不會跟著排隊。**第 14 條的 24 小時從公司知悉那一刻起算，不會因為你的人正在修另一件事而暫停。

**第三，人會被修補吸走，而且是自願的。**修補有明確的完成點：改完、測完、出版本，今天有成就感。研判永遠做不完，明天還有 132 條新的。人的注意力自然會流向做得完的那一邊。

**第四，等你發現的時候，中樞已經變成一個很慢的維護團隊。**它還在做事，只是不再做那件只有它能做的事。

中樞是結構技師，不是工班

結構技師畫圖、算載重、簽證。樓塌了他要負責。

但他不會自己爬上去綁鋼筋。原因有兩個：一棟樓的鋼筋不是一個人綁得完的；更重要的是，他一旦上去綁，就沒有人在看整棟樓的圖了。

PSIRT 中樞是同一個位置。它的價值不在動手，在於它是唯一一個同時看得到「所有產品 × 所有弱點 × 所有時限」的角色。這個視角一旦讓渡出去，就沒有人補得回來。

至於中樞具體該做哪幾件事、界線怎麼寫成別人能接受的文字，明天專門講。

混合式的三個前提

混合式不是預設就會成立，它需要三件事同時到位。少一件就會退化成集中式。

**一、每條產品線要有一個具名的對口。**填部門名稱不算數，要填名字。沒有名字的時候，案件會自己滾回中樞手上。

**二、修補的優先序由中樞排，但工時由產品團隊的主管給。**中樞有判斷權沒有人事權，這件事要在制度上講清楚，否則每次都變成人情協商。

**三、中樞要有權把案件標成「已通知、未處理」並留紀錄。**這一格的用途不在究責，在於讓合規時鐘的紀錄完整。查廠的時候，「我們通知了但對方沒排進去」跟「我們沒通知」是兩件完全不同的事。

交付物：三種模型選擇邏輯

不要憑感覺選。這五題回答完，答案通常只剩一個。

三個提醒。

**第一，最後一列不是玩笑。**很多公司的實際運作就是「誰先看到誰處理」，而它在案件量小的時候看起來很有效率。9 月 11 日之後它會第一個出事，因為它沒有可稽核的軌跡。

**第二，模型可以隨規模改，但不要在案件進行中改。**改模型要挑沒有案件的空窗期，並且把交接寫下來。

**第三，選了混合式，就要接受中樞的績效指標跟修補數量無關。**中樞該被衡量的是「該送的有沒有準時送出去」「該盤的有沒有盤完」，修掉幾條是產品團隊的數字。這一點沒有跟主管講清楚的話，年底考績會很難看，然後隔年這個角色就沒有人願意接。

順帶一提，這也是為什麼中樞的人選不能只看技術深度。它要的是能在資訊不完整的時候下判斷、而且敢把判斷寫下來的人。技術很強但凡事都想再查清楚一點的工程師，放在這個位置會很痛苦，對他也不公平。

明天 Day 09：中樞只做四件事

研判、評分、盤點、掌時鐘。界線劃清楚，團隊才不會被當成萬用資安客服。附一份可以直接貼在流程文件裡的職責邊界聲明範本。

順便問一句。你們現在的運作方式：

比較接近哪一種？

（a）集中式，資安自己修　（b）分散式，各團隊自己管　（c）混合式，中樞判斷產品團隊修　（d）看誰有空

留個字母就好，不用打長篇。（d）不用不好意思，它是所有公司的起點。

這系列每天更新，覺得有用的話幫忙訂閱討論。

參考：Regulation (EU) 2024/2847 第 14 條與 Annex I Part II(2)；模型分類與三個前提為個人整理，非法規明文，可對照 FIRST PSIRT Services Framework 的組織模式章節。