你把掃描接進建置流程，設了一條規則：Critical 就擋。

然後跑第一次。

三十七個專案，三十五個紅的。而且那些 Critical 大多在三年前就存在了，跟今天這次改動一點關係都沒有。

第二天，有人在群組裡問這個可以不可以先跳過。第三天，有人把它改成警告。第四天，沒有人再看它了。

門檻不是被推翻的，是被繞過的。

為什麼第一次一定全紅

因為你在一個存量上，套了一條為增量設計的規則。

任何跑了三年的專案都背著技術債。你第一次掃，掃到的是那三年的總和。把三年的債算在今天這個 PR 上，作者當然不服，而且他是對的。

既有違建的處理是同一個道理。新的違建要拆，既有的列管限期改善。如果新法上路第一天就要把全市既有違建全部拆掉，結果會是一棟都拆不了。問題不在法規不夠嚴，在於它嚴到沒有人能執行。

核心設計：把「新引入」跟「既有」分開

這是整篇唯一真正重要的一句話。

實作上怎麼分？跟基準線比。

建立一次基準，把當下的狀態整批記錄下來，之後每次掃描只看差異。多數工具都支援這件事，只是預設不開。

所以門檻該問的問題變成：

這次改動讓事情變糟了嗎？

而不是「現在夠不夠好」。

這個設計還有一個附帶好處：**門檻從第一天起就可以設得很嚴，因為它不會誤傷任何人。**你要擋的只有「今天新帶進來的」，那本來就該擋。

三層判準，由外而內

分清楚存量與增量之後，才輪到「什麼情況要擋」。

**第一層：已知遭在野利用嗎。**這一層最硬，因為它陳述的是事實，不是預測。已經有人在真實世界拿它攻擊真實目標，沒有什麼好討論的。

**第二層：被利用的機率。**這一層要你自己訂切點，而且要先接受一件事：它會錯。機率模型給的是傾向，不是保證。訂高了漏，訂低了吵，兩邊都會發生。

**第三層：有沒有修補版本。**這一層最容易被放在錯的位置。

多數人把「有修補版本」當成加分項。它其實應該是**「擋」的前置條件**。

理由很現實：**擋一件無法修的事，只會產生豁免，不會產生修補。**上游還沒釋出修補版本的弱點，你擋下去，開發者能做的只有申請例外。你得到的是一張例外單，不是一個修好的產品。

沒有修補版本的那些，該做的是記錄、評估可達性、必要時做緩解措施，而不是卡在建置流程裡。

**嚴重度分數刻意不在這三層裡。**Day 16 講過，嚴重度衡量的是弱點本身，不是你的處境。它適合當排序依據，不適合當閘門。

豁免要跟門檻一起設計

Day 20 那六個決策問題裡的第五題，今天展開。

一個沒有豁免機制的門檻，會在第一次擋到緊急發版的時候被整個關掉。所以豁免這件事與其說是妥協，更像是門檻能存活的條件。

豁免單要有四個欄位：

第三列是這張表的重點。而且到期時要自動重新出現，不要靠人記得。靠人記得的到期日，等於沒有到期日。

還有一件事值得誠實面對：**一個健康的系統應該看得到豁免的總數，而且那個數字要有人負責。**豁免本身不是失敗，藏起來的豁免才是。如果你發現豁免數量持續上升，那通常代表門檻訂錯了，不是團隊不自律。

交付物：門檻設計決策表

這張表刻意不給數值。切點要看你的產品暴露程度、修補節奏、團隊規模，抄別人的數字只會得到別人的爭吵。

三個提醒。

**第一，先建基準線，再開門檻，順序不能反。**反過來做就會得到開頭那個故事。

**第二，第六列請不要填「擋」。**無法修的東西擋了只會產生豁免。填「記錄並評估可達性」比較誠實，也比較有用。

**第三，最後一列容易被當成形式，但它是唯一能告訴你門檻訂得對不對的指標。**豁免數量緩慢下降，代表設計是對的；持續上升，代表你該回頭改門檻，而不是去催人。

明天 Day 24：「定期測試與審查」到底要做到什麼程度

Part II(3) 沒有規定頻率，所以你要自己定義並自證。什麼時候跑什麼、範圍多大、證據留成什麼樣。以及硬體廠躲不掉的一題：晶片商給的二進位檔沒有原始碼，靜態分析根本掃不到，那一塊怎麼辦。

順便問一句。你們現在的建置流程裡：

如果掃描擋下一個沒有修補版本的弱點，開發者會怎麼做？

（a）走豁免流程，有紀錄　（b）找人口頭放行　（c）自己改掉掃描設定　（d）沒有掃描，所以不會發生

留個字母就好，不用打長篇。（b）跟（c）都無關紀律，是設計沒把出口留好。

這系列每天更新，覺得有用的話幫忙訂閱一下，謝謝。

參考：Regulation (EU) 2024/2847 Annex I Part II(2)(3)；CISA KEV 已知遭利用弱點目錄、FIRST EPSS 利用機率評分、CVSS 嚴重度分級為其公開定義。基準線做法、三層順序與豁免欄位為個人整理，尚未經導入驗證，非法規明文。