Annex I Part II(3) 的全文，翻成中文大概二十個字：製造商應定期對產品進行有效的測試與審查。

沒有頻率，沒有方法，沒有涵蓋率門檻。

建築物的公共安全檢查申報也寫「定期」，但後面接著一張表，依用途類別與樓地板面積告訴你是一年一次還是兩年一次。CRA 這一條沒有那張表。它把定義權交給你，順手把舉證責任一起交給你。市場監督機關不會說多久一次才算定期，但會問你為什麼是這個數字，然後看你有沒有照著跑。

所以今天處理兩件事：怎麼把「定期」定義成守得住的東西，以及晶片商給的二進位檔沒有原始碼、靜態分析掃不到的那一塊怎麼交代。

「定期」要同時定義三件事

頻率、範圍、證據。缺任何一個都不算做到。只有頻率，掃的是哪一版、涵蓋哪些模組沒人說得清楚；只有範圍，拿不出哪一天掃的。

還有一個實際理由要綁在一起講：**頻率訂太高，範圍就會被偷偷縮小。**要求每次 PR 都跑完整深度掃描，結果通常是有人把設定悄悄改成只掃三個目錄。

用事件定義，不要只用時間定義

CRA 寫的是「定期」，聽起來像時間。但工程上有意義的問法是：**什麼事情發生的時候，要跑什麼。**改三行跟出貨給歐盟客戶，該跑的檢查不會是同一套。純事件驅動則有一個最容易被忽略的漏洞：**弱點資料庫每天都在變，你的程式碼沒改，不代表結論沒變。**所以矩陣最後要補一條時間型的定期全掃當底線，這跟 Day 22 那個「活的 SBOM」是同一件事的兩面。

五個觸發節點，各跑各的

我判斷該這樣拆，但還沒導入驗證。

**一、MR／PR 進來的時候。**只跑輕量檢查：這次改動碰到的檔案，以及依賴宣告檔有沒有動，工具要支援增量掃描。判準是「開發者願不願意等」，等不了就會被繞過。

**二、跨團隊或跨產品線合併共用元件的時候。**這個節點是硬體廠獨有的，純軟體的教學文不會寫。一個網路模組的驅動從別條產品線搬過來，帶著自己的依賴樹與技術債，而它在那條線上通過，是因為那條線的門檻不一樣。合併點要當成一次新引入處理。

**三、Release 節點。**全量深掃，產出完整 SBOM，證據封存。這是唯一不該妥協時間的節點，因為出貨之後這一版的狀態就要寫進技術文件。

**四、週期性全掃。**不看有沒有改動，照時間跑，理由就是資料庫會動。

**五、上游安全公告或供應商通知進來的時候。**範圍只有受影響的元件，但要橫跨所有還在支援期間內的產品版本。輸入在外面，時鐘也在外面。

每個節點都要填四個欄位：範圍、時間預算、擋不擋、證據留什麼。填完才算定義了「定期」。

掃不到的那一塊

Day 20 我列過硬體韌體有三塊掃不到：靜態連結進去的函式庫、晶片商給的二進位檔、打包壓縮層。三塊有一個共同點，全都在原始碼與依賴宣告檔之外。要看見它們，工具得從另一頭進去。

這裡值得把三種掃描分清楚，因為很多人把它們混成一句「我們有掃」：

前兩種掃的是你打算交付什麼，第三種掃的是你實際交付了什麼。

食品廠有配方表，也有出廠檢驗報告。兩份都要，但只能留一份的話，留檢驗報告。CRA 管的是放到歐盟市場上的那個產品，不是你的建置腳本。

它的原理是特徵比對：函式簽章、字串常數、版本字串、編譯痕跡。要誠實講一件事：**它給的是機率性的結論，誤判率比來源端 SCA 高。**函式庫被裁切、被改過、被靜態連結之後，特徵會糊掉，有時候只能告訴你版本落在某個區間。

但一份有機率的清單跟沒有清單，差距不在同一個量級。而且它順手會給你兩樣原始碼看不到的東西：二進位強化選項有沒有開（RELRO、堆疊保護、NX、PIE，直接對到 Annex I Part I(k) 的利用緩解措施），以及誤留在映像裡的金鑰與憑證。

不推薦任何廠商，但選型有一條分水嶺要先問：**能不能拆到 MCU 韌體那一層。**能拆 Linux 檔案系統映像的工具不少，能拆馬達控制器裡那顆沒有檔案系統的裸機映像的不多，而那正是硬體廠最需要的。

掃不到不等於免責

掃描工具的極限是工程事實，不是法律豁免。Annex I Part II(1) 要你識別並記錄產品中的元件，沒寫「掃得到的才要記」。所以掃不到的那塊要有補償措施，四層由外而內：

**合約層。**向供應商索取該元件的 SBOM，或至少一份已知弱點清單與支援期限。拿不到會怎樣，明天整天在講。

**識別層。**就算什麼都問不到，至少記下檔名、雜湊值、供應商、取得日期、版本字串、對應到哪幾條產品線。它的價值在未來：外面丟一條 CVE 進來時，你靠它決定要不要緊張，而不是打電話問供應商，然後在時鐘跑的時候等回信。

**風險層。**對掃不到的區塊做暴露面判斷：有沒有開對外的 port、有沒有處理不受信任的輸入、跑在什麼權限下。掃不到內容，至少評估得了位置。

**聲明層。**技術文件裡誠實寫「這一段以供應商聲明為依據，未經獨立驗證」。

最後這層最反直覺，卻最省事。留白會被當成沒做，寫清楚是一個有邊界的保證。**查廠時最危險的答案不是「我們掃不到」，是「我們全部都掃過了」。**前者是已知限制，配著補償措施；後者只要被抽驗到一個對不上的元件，整份文件的可信度就一起垮。

交付物：觸發矩陣與補償措施登記表

一樣不給數值。時間預算看建置環境，擋不擋看團隊承受度。

填寫準則：

□ 同一列裡，「擋」與「時間預算長」不要同時出現。擋得住的前提是等得起。
□ 五列裡至少有一列是「擋」，通常是 Release 那列。
□ 證據欄不要只填「報告」。填清楚是哪一版的什麼報告、存在哪、保存多久。這一欄 Day 26 會整份拿去用。
補償措施登記表

每一個掃不到的區塊各填一份。

最後一列務必填。沒有到期日的登記表，三個月後就是一份沒人相信的舊資料。

明天 Day 25：拿不到上游 SBOM，就承諾不了支援期間

晶片商只支援三年，你要在包裝上公開標示五年。這一題與其說是談判技巧，不如說是你敢不敢簽下去。附一份供應商詢問信範本。

順便問一句。如果現在有人問你，你們出貨的那顆韌體映像裡面有什麼：

你能在多久之內拿出一份清單？

（a）幾分鐘，建置流程會自動產　（b）幾天，要找人重跑一次　（c）幾週，要問供應商　（d）拿不出來

留個字母就好。我自己這一題也還沒有滿意的答案。

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

參考：Regulation (EU) 2024/2847 Annex I Part I(k)、Part II(1)(3)。觸發矩陣五個節點與補償措施四層為個人整理，判斷該這樣做但尚未經導入驗證，非法規明文。