iT邦幫忙

2026 iThome 鐵人賽

DAY 26
1
Security

時鐘從「知悉」開始:從零打造 PSIRT,三十天走完歐盟 CRA 的通報與 SBOM系列 第 26 篇

Day 26|技術文件要留十年,而掃描報告卻存在某個人的筆電裡

  • 分享至 

  • xImage
  •  

先講兩條會決定你怎麼收尾的規定。

第 13(13) 條:技術文件與 EU 符合性聲明要供市場監督機關取用至少十年,或整個支援期間,孰長。

第 31 條:技術文件要在產品上市之前就備妥,而且在支援期間內持續更新。

兩條合起來的意思是,這份東西會活得比多數專案還久。十年後有人來要,你要拿得出來。

所以請先回答一個小問題:你們上一次 Release 跑的那份掃描報告,現在在哪裡?

如果答案是「在 CI 的 artifact 裡」,多數 CI 的預設保留期是三十天;如果是「在負責那個案子的工程師筆電裡」,那個人可能已經換部門了。
https://ithelp.ithome.com.tw/upload/images/20260926/20169113gpwSNmxYMm.png
Annex VII 八項,先看會卡住的那幾項

技術文件的內容是 Annex VII 明列的,八項:

https://ithelp.ithome.com.tw/upload/images/20260926/20169113ktagvhlhq4.jpg

八項裡有四項值得停下來。

**第 2 項的 (b) 子項,是整份文件裡最貼近這三十天的一段。**它要的是弱點處理流程的資訊與規格,明文包含:軟體物料清單、協調式弱點揭露政策、提供弱點通報聯絡地址的證據,以及安全散布更新所選用的技術方案。Day 13 到 Day 18 建的那條流程,在這裡變成一份要被翻閱的文件。特別注意「證據」兩個字,它要的不是你寫了一頁政策,是那個信箱真的存在、真的有人看。

**第 4 項要你寫出你當初怎麼決定支援期間。**昨天那張差距表就是這一項的答案。如果你當時只是拍了一個五年,這一格會很難填。

**第 5 項是目前最尷尬的一項。**官方公報上到現在還沒有 CRA 的調和標準,所以幾乎所有人只能走後半句那條路:未採用,說明替代解決方案。你得自己說明用了什麼方法、為什麼那個方法足夠。IEC 62443-4-1、SP 800-218 這類現成框架是最實際的填空材料,但涵蓋範圍與落差要你自己論證。

**第 6 項的測試報告,要涵蓋 Part II 的流程,不只 Part I 的產品。**多數人聽到測試報告會想到滲透測試,於是文件裡全是產品面的結果,流程面一片空白。Day 24 那張觸發矩陣填完之後,它本身就是流程面測試的主要證據。

版本凍結:文件寫的是哪一版,出貨的是哪一版

硬體廠在這裡有一個軟體專案沒有的麻煩。同一個型號的韌體一年可能出五版,Annex VII 第 1 項卻要你寫明「影響符合性的軟體版本」。

我的處理方式是分成兩層。技術文件的主體綁符合性評鑑當下的那一版,那是基準;之後每一版出貨只維護一份增量紀錄:這一版跟基準差在哪、SBOM 差異、掃描結果差異、有沒有引入新的高風險元件。

好處是查廠時不必翻五份平行文件,只翻一份基準加一條變更鏈。壞處是這條鏈斷一環,後面全部失去可信度。

實質修改到什麼程度要重新評鑑是另一個題目,也是長鬧鐘底下最容易被低估的維運成本。這裡只留一個判準:變更若影響了 Annex I Part I 任何一項的滿足方式,就當成要重新評鑑來準備。

建案完工圖如果跟實際蓋出來的不一樣,真正的麻煩會出現在後面每一次修繕,因為每次都得重新測量。

符合性聲明只有一頁,但它把前面全部釘在一起

Annex V 列的內容很短:產品名稱與型號、製造商或授權代表的名稱地址、本聲明在製造商單獨責任下簽發的陳述、可追溯的聲明對象、符合相關歐盟法規的陳述、採用的調和標準或共同規範或資安認證、必要時公告機構的名稱編號與所發證書、其他補充資訊。

八個欄位,一頁紙。四幕二十六天的工作,最後收斂成這張紙上的一句「單獨責任」。

它跟技術文件的關係要分清楚:聲明是給市場看的,技術文件是給查的人看的,聲明上每一行背後都要有文件撐著。Module A 自我評鑑的意思是沒有第三方幫你背書,撐不撐得住只有你自己知道,直到有人來問。

交付物:證據保存規格與技術文件目錄

https://ithelp.ithome.com.tw/upload/images/20260926/20169113rUq52Kkfg7.jpg

四條填寫準則:

□ 保存年限一律以「上市日加十年」或「支援期滿」孰長為底線,不要各欄各訂。
□ 保存位置不可以是個人裝置,也不可以只有 CI 的 artifact。多數 CI 預設保留三十天,那個預設值會安靜地吃掉你的證據。
□ 「誰能取用」要填得到人,因為查廠當天需要的是有人能在一小時內把檔案調出來。
□ 每一份證據都要能回推到版本:哪一個型號、哪一版韌體、哪一次建置。回推不了的證據等於沒有。
技術文件目錄

Annex VII 八項各填一列,這張表本身就可以當成技術文件的封面。

https://ithelp.ithome.com.tw/upload/images/20260926/201691130KGsZd6urH.jpg

最後一欄是這張表唯一的重點。前四欄是盤點,第五欄才會讓文件活著。第 31 條要求的是持續更新,一份三年沒動過的技術文件,在查的人眼裡跟沒有差不多。

幕四到這裡收掉。從 Day 19 那十三條要求與八條流程開始,中間七天在講怎麼把 SBOM 做成一條產線、怎麼設門檻、怎麼面對掃不到的東西、怎麼把承諾期限談出來。後方那間造船廠最後被記得的,是它交出了多少艘有編號、有紀錄、找得回來的船。

明天 Day 27:三千條進去,三十條出來

幕五開場。兩個方向的箭頭:主動掃自己的程式碼,跟被動反查外面丟進來的 CVE。多數團隊只做了前面那一邊,而後面那一邊才是有時鐘的。附 VEX 產出範本。

順便問一句。你們最近一次 Release 的掃描報告:

現在存在哪裡?

(a)有指定的保存位置與年限 (b)在 CI 裡,沒改過預設保留天數 (c)在某個人的電腦或共用資料夾 (d)沒有留

留個字母就好。(b)是最容易出事的一個,因為它看起來像有做。

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

參考:Regulation (EU) 2024/2847 第 13(13) 條、第 31 條、Annex V、Annex VII。截至 2026 年 9 月,歐盟官方公報上尚無 CRA 調和標準,故 Annex VII 第 5 項多數情況須以替代解決方案說明。版本凍結的兩層做法與證據保存年限取法為個人整理,尚未經導入驗證,非法規明文。


上一篇
Day 25|上游只給三年,而你要在包裝上印五年
下一篇
Day 27|三千條進去,三十條出來
系列文
時鐘從「知悉」開始:從零打造 PSIRT,三十天走完歐盟 CRA 的通報與 SBOM 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
hunterlin
iT邦新手 5 級 ‧ 2026-09-30 11:17:21

選 (a)有指定的保存位置與年限

我要留言

立即登入留言