先把前提寫死，因為前提變了，底下的順序就全部作廢。

**一個人。三個月。一家硬體公司，產品有賣到歐盟，而且早就賣了好幾年。**沒有預算買平台，沒有第二個人可以分工，第 14 條的通報義務已經生效。

這不是最佳實務，是在這個框裡只能做這麼多。

而且我要先講不做什麼。因為只要從「要做什麼」開始列，清單永遠會長到做不完，然後你會在第二週就開始挑軟的做。

我不做的七件事

**一、不買平台，也不評估工具。**採購週期比三個月長，而且你現在還不知道自己的流程長什麼樣。先買工具，最後會變成工具定義你的流程。

**二、不做完整資產盤點。**全部型號盤完要半年。只盤「有賣到歐盟、而且還在支援期間內」的那幾條，其他的先放著。

**三、不開漏洞獎勵計畫。**入口都還沒有人顧，開了只是把流量放大，然後你會被自己招來的東西淹掉。

**四、不做五級嚴重度分級。**三級就夠：會中斷工作的、排程處理的、退件合併的。五級是大組織的奢侈品，小團隊用五級只會多出兩層爭論。

**五、不追求 SBOM 涵蓋率百分之百。**先讓每一次建置都產出一份，哪怕不完整。一份會自己更新的不完整清單，比一份完整但三個月沒動過的檔案有用得多。

**六、第一季不開門檻擋建置。**只計數，建基準線。一上來就開門檻，你這個月會全部花在處理豁免爭議上，而且那些爭議還會讓你被貼上擋路的標籤。

**七、不寫完整的政策文件體系。**一頁的 CVD 政策，加一份決策人指定書，比三十頁的制度手冊有用。手冊可以之後補，時鐘不會等手冊。

七條的共同點是：它們都很像「做了會有成果」的事，而且都很好寫進進度報告。這正是它們危險的地方。

第 1 到 30 天：只做四件事

目標只有一個，撐得住明天就有人丟一條 CVE 進來。

**第一，指定決策人與代理人，寫下來。**誰有權決定「這件事要不要通報」，名字、代理人、聯絡方式。這一步排第一，因為前三十天真正的風險從來就不在工具，而在案件進來的時候沒有人按得下送出鍵。工具不到位只是慢，沒有人決定是直接違法。

**第二，開一個對外入口並且公開它。**一個信箱、一個 security.txt、一頁 CVD 政策。入口排第二而不排第一，理由很簡單：沒有人顧的入口等於沒有入口，所以決策人要先到位。

**第三，建一張獨立的合規時鐘紀錄表。**知悉時間、來源、24 小時、72 小時、14 天各自的到期時刻、目前狀態。一張試算表就夠，這一步不需要任何系統。它排在第三，是因為前兩步到位之後，它是唯一還缺的那一塊。

**第四，盤出歐盟在售清單，附上最小版本的元件建檔。**型號、韌體版本、核心第三方元件。這一步最花時間，所以放在最後，讓它跟前三步平行跑。

三十天結束的驗收標準只有一句話：現在有人丟一條 CVE 進來，你答得出「誰判、多久要回、影響哪幾條產品線」。

三個月要交屋的房子，先做水電跟防水，系統櫃之後再補。順序反過來，之後每一次補救都要先拆掉剛做好的東西。

第 31 到 90 天：把人治換成可稽核

前三十天那四件事是靠一個人記得住撐起來的。這兩個月要做的，是把它變成別人接手也跑得動的東西。

**第五，把判斷寫成表單必填欄位。**受影響產品、版本、重現步驟、影響描述、回報者聯絡方式。系統先擋掉一半，剩下的才值得人看。

**第六，三級分級與各級的響應時限。**寫下來、公開在內部，這樣爭論的對象變成規則，不再是你本人。

**第七，SBOM 進建置流程，每次都產，只產不擋。**這一步排在流程之後，因為沒有流程的 SBOM 只是一堆檔案，沒有人會去看。

**第八，做一個最小的反查工具。**輸入一個 CVE 編號，輸出受影響的套件與版本區間，再比對元件建檔。它排最後，因為它依賴第四步那份建檔，建檔不對，工具做出來也是空的。

這四步做完，你手上會多一樣東西：**紀錄。**到這裡為止所有的動作都會留下痕跡，而痕跡就是後面那兩年唯一拿得出來的東西。

第 91 天到 2027 年 12 月：按季度排

第三段不再以天計算，改成一季一個主題，而且每一季的產出都直接對應 Annex VII 的某一格。

為什麼門檻排第一季不排第三季？因為門檻要先跑滿一季，你才有足夠的數據知道切點訂得對不對。訂完就走的門檻沒有意義。

為什麼供應商那段排到第三季？因為那是唯一一件不完全由你控制的事，回信要等、談判要時間，排太前面你會卡在等待裡，而前面兩季還有很多自己做得完的事。

三個我會做得不一樣的地方

**一、決策人指定書排在第一週，不等組織圖定案。**它看起來像行政文件，實際上它是唯一能讓時鐘動起來的東西。等組織定案再指定，你會發現組織永遠在定案中。

**二、元件建檔要排得更前面。**這是整份清單裡唯一一件越晚做越貴的事，因為每多出一版韌體，就多一份對不起來的資料，而且那份資料只會越來越難補。

**三、先寫「不做什麼」，再排順序。**這件事我是寫這三十天的過程中才想清楚的。受限的計畫真正的難度不在挑出該做的，在於扛得住不做那些看起來也該做的。

交付物：三個月排序卡

印出來貼在看得到的地方。每一格只有做完跟沒做完兩種狀態，不要有百分比。

先確認七個不做

□ 不買平台　□ 不做完整盤點　□ 不開獎勵計畫　□ 不做五級分級
□ 不追 SBOM 百分之百　□ 第一季不開門檻　□ 不寫制度手冊

第 1 到 30 天

□ 決策人與代理人，有名字、有聯絡方式、寫下來
□ 對外入口上線：信箱、security.txt、一頁 CVD 政策
□ 合規時鐘紀錄表：知悉時間與三個到期時刻
□ 歐盟在售清單與最小版本元件建檔

驗收：有人丟一條 CVE 進來，答得出誰判、多久要回、影響哪幾條產品線。

第 31 到 90 天

□ 通報表單必填欄位
□ 三級分級與響應時限，公開在內部
□ SBOM 進建置流程，每次都產，只產不擋
□ 最小反查工具：CVE 編號進，受影響產品線出

驗收：這四件事換一個人接手，還跑得動。

第 91 天起，一季一個主題，照上面那張表走。

明天 Day 29：資安什麼時候會有抗生素

一年將近五萬條 CVE，但弱點類型只有九百多種。如果我們每天撈的是個案，那有沒有可能打的是機轉。附一個用公開資料做的小實驗，結果不漂亮也放上來。

順便問一句。如果明天有人給你三個月跟一個人：

你會先做哪一件？

（a）指定決策人　（b）開對外入口　（c）盤產品與元件　（d）先買工具再說

留個字母就好。選（d）很正常，那是最容易跟主管交代的一個。

這系列每天更新，覺得有用的話訂閱一下，我盡量不寫廢話。

參考：Regulation (EU) 2024/2847 第 13 條、第 14 條、第 31 條、Annex I Part II、Annex VII。三段式排序、七件不做的事與季度主題為個人整理，前提是單人、三個月、硬體製造商，前提改變順序即不適用；尚未經完整導入驗證。