寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

一開始，我以為 SBOM 就是一份 Software Component List
第一次接觸 SBOM — Software Bill of Materials（軟體物料清單） 時，其實概念並不難。就像製造業熟悉的 BOM（Bill of Materials）告訴我們產品用了哪些零件，SBOM 則是描述 Software 裡有哪些 Component。
例如一台 Router 的 Firmware，可能包含 Linux Kernel、OpenSSL、BusyBox、Web Server、Third-party Library 等，整理起來就像是一份 Software Ingredient List。
所以一開始，我也很容易把 CRA 的 SBOM Requirement 理解成：
「好，那我們產一份 SBOM 就好了。」
但研究越深入，我慢慢覺得，「有 SBOM」跟「SBOM 真的能支援 Vulnerability Handling」，可能是兩件不同的事情。

一、CRA 把 SBOM 放在哪裡？
這點我覺得很值得注意。
CRA Annex I 分成兩部分，Part I 是 Product Cybersecurity Properties，Part II 則是 Vulnerability Handling Requirements，而 SBOM 被放在 Part II。
CRA Annex I Part II 要求 Manufacturer 識別並記錄 Product 中的 Vulnerabilities 與 Components，並建立 Software Bill of Materials，而且至少涵蓋 Product 的 Top-level Dependencies。
這個位置讓我開始重新思考 SBOM。CRA 要 SBOM，可能不只是為了多一份 Documentation，它更重要的用途，應該跟 Vulnerability Handling 有關。

二、假設明天 OpenSSL 出現一個重大 Vulnerability
想像一個情境，星期一早上 OpenSSL 公布新的重大 Vulnerability。這時公司第一個問題可能不是：
「我們有沒有 SBOM？」
而是：
「哪些 Product 有用 OpenSSL？」
接著還會繼續問：哪些 Version？哪些 Firmware Release？哪些 Product Model？哪些仍在 Support Period？再下一題則是，這個 Vulnerability 在我們的 Product 上，真的可以被 Exploit 嗎？
假設公司有 200 個 Product，每個 Product 都有 SBOM，但這些資料分散在不同 R&D Engineer 的 Excel 裡，那麼雖然形式上「有 SBOM」，真正 Vulnerability 發生時，可能還是得花很多時間搜尋、比對與確認。
所以我現在比較在意的，已經不只是 SBOM 有沒有產出，而是：
SBOM 能不能被查詢、關聯與持續更新。

三、SBOM 真正開始有價值，是 Vulnerability 發生的時候
我自己現在會把 SBOM 跟 Vulnerability Management 放在一起看。
例如某個 CVE 出現之後：
CVE 出現
↓
找出 Vulnerable Component
↓
查哪些 Product 使用
↓
查哪些 Version 使用
↓
進行 Product Impact Analysis
↓
判斷 Exploitability
↓
決定 Remediation
如果這條線真的跑得起來，SBOM 才開始從單純的 Documentation，變成一種真正的 Product Security Capability。

四、SBOM 也不是 CVE Scanner
這個差異我覺得也很重要。
SBOM 告訴我們 Product 裡有什麼；Vulnerability Database / Scanner 則告訴我們某個 Component 可能有哪些已知 Vulnerability。
但：
Component 有 CVE，不一定等於 Product 就一定受影響。
例如 Vulnerable Function 根本沒有被使用，或 Product Configuration 讓 Attack Path 不存在。這時候即使 Scanner 找到了 CVE，後面還是需要進一步進行 Impact / Exploitability Analysis。
這也是後面 VEX — Vulnerability Exploitability eXchange 開始有價值的地方。

五、SBOM + VEX，我現在會這樣理解
如果用最簡單的方式理解：
SBOM：Product 裡有什麼？
VEX：這個已知 Vulnerability 到底影不影響 Product？
例如 SBOM 顯示 Product A 使用 Library X v2.0，而 Library X 出現 CVE-XXXX，但進一步分析後發現 Vulnerable Function 根本沒有被 Compile / Enable，那麼 VEX 就可能用來表達這個 Product 對該 Vulnerability 的實際狀態。
所以我自己覺得，SBOM 跟 VEX 如果能真正接到 PSIRT / Vulnerability Management，價值會比單純「產一個檔案」大很多。

六、那 SBOM 一定要公開給所有 Customer 嗎？
這也是我一開始很關心的問題。
我的理解是，CRA 要求 Manufacturer 建立 SBOM，不代表 SBOM 一律必須公開給所有使用者。
CRA Annex II 甚至提到，如果 Manufacturer 決定把 SBOM 提供給 User，才需要在 User Information 中說明 SBOM 可以在哪裡取得。
另外，CRA 也允許在特定 Union-wide Dependency Assessment 情況下，由 Market Surveillance Authorities 要求相關 Manufacturer 提供 SBOM。
所以我目前不會把 SBOM Requirement 直接理解成：
「SBOM 必須放在官網公開下載。」
至於實際要不要提供給 Customer，還可能需要考量 Contract、Customer Requirement、Security、IP / Confidentiality 等因素。

七、CRA 有指定 SBOM 一定要用 SPDX 或 CycloneDX 嗎？
這題在實務上很常出現。
目前 CRA Article 13(24) 授權 European Commission 未來可以透過 Implementing Acts，並考量 European / International Standards 與 Best Practices，進一步規定 SBOM 的 Format and Elements。
因此 SPDX 與 CycloneDX 當然都是目前很值得關注的 SBOM Format，但以我現在的理解，我不會直接說：
「CRA 已經規定只能使用其中某一種。」
這部分還是要持續追蹤後續 Implementing Acts、Harmonised Standards 與相關 Guidance 的發展。

八、那 CRA 要求 SBOM 做到多深？
CRA Annex I Part II 明確提到至少要涵蓋：
Top-level Dependencies。
看到 「at least」，我自己會特別注意，因為 Top-level Dependency 跟 Full Dependency Tree 並不是完全相同的概念。
假設 Product 使用 Component A，A 又依賴 B，B 又依賴 C，實務上到底應該追到哪一層最適合，我自己不會單純為了追求「越多越好」而無限往下展開，而是會一起考量 CRA Requirement、Vulnerability Management Need、Tool Capability 以及 Product Complexity。
未來相關標準與 Commission 的進一步規範，也可能讓這件事情更加清楚。

九、對 ICT Product，SBOM 相對容易想像
例如 Router Firmware，Build Pipeline 可能本來就知道使用了哪些 Open Source Package、Library、Kernel 或 Third-party Software。如果公司已經導入 SCA — Software Composition Analysis Tool，甚至可能可以自動產生 SBOM。
這時候比較大的挑戰，可能不是第一次把 SBOM 產出來，而是後續的 Version Management。
例如 Product A 的 Firmware 1.0 跟 Firmware 2.0，使用的 Component 可能已經不同，因此我會希望 SBOM 能跟：
Product + Version
建立明確關聯。
否則半年後看到一份 SBOM，卻不知道它對應的是哪一個 Firmware Release，真正要進行 Vulnerability Analysis 時，價值就會大幅下降。

十、Semiconductor 的情境又不太一樣
假設今天是一顆 MCU，Silicon 本身可能沒有大量 Software，但 Manufacturer 可能同時提供 Firmware、SDK、Driver、Middleware、Security Library 或 Reference Software。
這時候真正困難的問題反而是：
SBOM Scope 怎麼定？
我自己會先問，這些 Software 跟 Product 的關係到底是什麼？哪些是 Product 的一部分？哪些是另外提供的 Software Product？哪些屬於 Third-party Component？
釐清這些關係之後，再決定如何建立 Component Inventory，而不是因為公司賣的是 Chip，就直接認為 SBOM 與自己無關。

十一、Hardware BOM 跟 SBOM 也不要混在一起
Semiconductor / Hardware Company 本來就很熟 BOM，但：
Hardware BOM ≠ SBOM。
CRA Annex I Part II 明確使用的是 Software Bill of Materials。因此一顆 IC 裡有哪些 Transistor、Die、Package Material，並不是這裡所說的 SBOM。
但如果 Product 同時包含 Firmware / Software Component，那就可能需要進一步盤點。我自己會傾向把 Hardware Component Inventory 跟 SBOM 分開管理，有需要時再建立兩者之間的關聯，而不是直接把兩種 BOM 混成同一件事情。

十二、Supplier 也是 SBOM 很容易卡住的地方
Product 裡的 Software 不一定全部都是自己開發的。
例如 Supplier 提供一個 Binary，公司知道裡面有這個 Component，卻不一定知道它還包含哪些 Library 或 Dependency。這時候 SBOM 的完整度，很自然就會受到 Supplier Transparency 影響。
所以 CRA 做到後面，SBOM 很容易又會接到 Supplier Security。
未來對 Supplier 的要求，可能不只停留在「你們有 ISO 27001 嗎？」，還可能進一步關心 Component Version、SBOM 能否提供、Vulnerability 如何通知、Security Update 如何提供，以及 EOL 如何處理。
這些議題其實都開始跟 Product Security Supply Chain 接在一起。

十三、SBOM 還有一個問題：誰維護？
這是我自己覺得非常實際的一題。
如果 SBOM 只在 CRA Project 階段產一次，一年後 Product 已經經過多次 Update，Component 也換過好幾輪，但 SBOM 還停留在 v1.0，那麼真正發生 Vulnerability 時，這份過期的 SBOM 反而可能誤導分析。
所以我自己會希望 SBOM Generation / Update 能跟 Development / Build / Release Process 接起來。
例如：
Release 新 Firmware
↓
Generate / Update SBOM
↓
Version Control
↓
Repository
↓
Vulnerability Monitoring
這樣 SBOM 才比較像一個持續運作的 Lifecycle Capability，而不是 CRA Project 結案時留下來的一份靜態文件。

十四、所以我現在比較在意的不是「SBOM Tool 買哪一套」
Tool 當然重要，但如果公司還不知道 Product Owner 是誰、SBOM Scope 是什麼、Version 怎麼管理、Supplier Component 怎麼處理，以及 Vulnerability 發生後由誰分析，那麼就算買了 Tool，也不代表問題自然會被解決。
所以我自己現在比較傾向：
先把 Process 與 Data Relationship 想清楚，再決定 Tool。
因為最後真正要建立的，可能不是一個「SBOM 系統」，而是一套能把 Product、Version、Component、Vulnerability、Impact Analysis 與 Remediation 串起來的管理能力。

十五、如果讓我畫一個最簡單的 SBOM Lifecycle
我目前可能會這樣畫：
Product / Version
↓
Component Identification
↓
SBOM Generation
↓
Repository / Version Control
↓
Vulnerability Monitoring
↓
Product Impact Analysis
↓
VEX / Remediation Decision
↓
Security Update / Guidance
↓
SBOM Update
這不是 CRA 官方指定的流程，只是我自己目前研究及參與導入後，覺得比較能把 SBOM 跟 Product Security Lifecycle 接起來的一種方式。

Day 8 小結｜SBOM 的價值，可能不是「我有一份表」
研究到這裡，我自己對 SBOM 最大的觀念變化是：
SBOM 不是終點，它比較像 Vulnerability Management 的基礎資料。
真正發生 Vulnerability 時，公司能不能很快回答：
哪些 Product 有這個 Component？哪些 Version？是否真的受影響？還在不在 Support Period？需要採取什麼措施？
我覺得這些問題，才會真正測試一份 SBOM 是否「能用」。
而 CRA 把 SBOM 放在 Vulnerability Handling Requirements 裡面，也讓我更傾向從這個角度理解它。對 ICT Product 而言，可能比較容易從 Firmware / Software Component 開始；對 Semiconductor Product，則可能還要進一步釐清 Firmware、SDK、Driver、Middleware 與 Third-party Software 跟 Product 本身的關係。
所以不同 Product 的 SBOM Implementation，我自己認為未必需要長得完全一樣，重點還是它能不能支援後續真正的 Product Security 與 Vulnerability Handling。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
至於 SBOM Format、Depth、Content，以及未來跟 Harmonised Standards 的關係，我自己也會持續追蹤 Commission 後續規範與相關標準的發展。

Day 9 預告｜有 SBOM 之後，誰每天看漏洞？CRA 怎麼把 PSIRT 拉進 Product Lifecycle？
假設 SBOM 已經建好了，隔天某個 Component 出現新的 CVE。
然後呢？
誰收到 Vulnerability Information？誰判斷 Product Impact？誰決定要不要 Fix？誰跟 Customer 溝通？如果是 Actively Exploited Vulnerability，又是誰判斷是否涉及 Article 14 Reporting？
這時：
PSIRT — Product Security Incident Response Team
就開始變得很重要。
Day 9，我們來聊：
CRA、PSIRT，以及 Product Vulnerability 從「收到」到「處理」到底可能怎麼走。