過去採購一台產線設備，我們習慣看產能、精度、節拍、保固與備品。現在再用同一張檢查表，往往會漏掉最難處理的一部分：設備裡到底跑了哪些軟體，而且未來十年由誰負責更新。
智慧設備早已不是單純的機械加 PLC。它可能包含嵌入式 Linux、Web 管理介面、遠端維護代理程式、開源函式庫、資料庫、AI 模型、雲端 API 與第三方通訊模組。當設備進廠時，我們不只買下一台機器，也把一條看不見的軟體供應鏈一起接進了現場。
設備壽命與軟體壽命，從來不是同一個尺度
製造設備常以十年甚至更久為使用週期，但它裡面的作業系統、函式庫與通訊元件，可能兩三年就停止維護。機構還很穩、精度也符合要求，軟體卻已經收不到安全更新；供應商仍願意修馬達，原本替它開發管理介面的團隊卻早已解散。
這個落差在傳統驗收裡不容易被看見。設備能開機、能連線、能完成試產，不代表它具備可維護性。很多問題要等到弱點公告、網路架構調整、憑證到期，或某個雲端服務停用時才浮現。到了那時，團隊才開始追問版本、原始碼、相依套件與更新責任，通常已經太晚。
我現在看智慧設備，會把「能不能長期安全運作」當成與產能同等重要的能力。因為停機不是唯一風險。無法更新的設備也可能迫使工廠保留舊協定、放寬防火牆、維持過期伺服器，最後讓一台機器的限制，變成整個廠區架構的技術債。
SBOM 不是交差文件，而是設備的成分標示
SBOM，也就是軟體物料清單，常被理解成資安稽核要求：列出產品用了哪些軟體元件、版本與授權，交一份檔案就算完成。我認為這樣太可惜。
對技術主管來說，SBOM 更像設備的成分標示。當新的安全弱點出現，我們應該能快速回答：哪些設備受到影響？問題元件是直接使用，還是藏在另一個套件裡？目前運行的是哪個版本？供應商是否已有修補？如果不能更新，有沒有隔離或替代方案？
如果沒有成分清單，這些問題只能靠寄信逐台詢問，或讓工程師登入設備人工盤點。設備數量一多、供應商一換、文件一散，判斷時間就會從幾小時變成幾週。資安事件真正昂貴的地方，往往不是修補本身，而是不知道自己是否受影響。
不過，一份在驗收日產生後就不再更新的 SBOM，也只能描述設備出生時的樣子。後續韌體升級、維修換板、加裝模組或遠端維護，都可能改變軟體成分。所以 SBOM 必須跟著版本與資產生命週期更新，並能對應到實際安裝中的設備，而不是只留在採購附件裡。
採購階段不問，正式上線後就只剩談判
很多軟體供應鏈問題，到了維運階段才提出，其實已經失去大部分選擇權。設備停不得、產線改不起，供應商若只提供整包韌體、不揭露元件，企業通常只能接受。
因此我會在採購與驗收階段先問清楚幾件事：
- 是否提供機器可讀、可更新的軟體物料清單；
- 安全更新支援多久，停止支援前會提前多久通知；
- 弱點發生時，由誰判斷影響、提供修補與替代控制；
- 更新是否能先在測試環境驗證，失敗時如何回復；
- 設備是否依賴外部雲端、授權伺服器或特定網路服務；
- 遠端維護使用什麼身份、憑證與稽核機制；
- 供應商或元件退場時，資料匯出、離線操作與接手方案是什麼。
這些要求不是要供應商保證永遠沒有弱點。那不切實際。真正需要的是責任與反應機制：出現問題時，雙方知道誰要提供什麼資訊、多久內回應，以及修補不能立刻上線時怎麼降低風險。
更新不能直接照搬 IT 的做法
工廠設備的更新治理，也不能簡化成「有漏洞就自動升級」。辦公系統重開幾分鐘也許可以接受，產線設備更新失敗，可能影響節拍、品質判定、通訊格式與安全互鎖。
所以 OT 環境需要的是風險導向的更新流程。先確認弱點是否真的能在目前配置下被利用，再盤點暴露面與補償控制；接著在相近環境測試韌體、驅動與上位系統的相容性，安排停機窗口，準備可執行的回復步驟，最後確認版本、功能與資料通訊都正常。
這裡的重點不是拖延修補，而是讓修補本身不製造新的營運事故。資安、設備、製程、資訊與供應商必須共享同一份變更紀錄。只由資安團隊寄一張弱點清單，或只由設備商說「建議升級」，都不足以支持現場決策。
AI 與雲端服務讓清單邊界更難畫
智慧設備加入 AI 後，成分不再只是一堆安裝在盒子裡的套件。模型檔、推論框架、資料前處理程式、外部 API，甚至雲端平台上的託管服務，都可能影響設備行為。
這時候我不會糾結所有東西是否都要塞進同一種 SBOM 格式，而是先確保依賴關係能被追溯：某個品質判定使用哪版模型？模型依賴哪個 runtime？資料送到哪個服務？服務版本改變是否需要重新驗證？雲端不可用時，設備會停止、降級，還是繼續使用最後一版結果？
清單的目的不是收藏名稱，而是支援決策。只列出元件卻不知道它和哪台設備、哪個功能、哪條產線有關，仍然很難處理風險。理想上，軟體成分要能連回資產、韌體版本、網路區域、業務影響與維護責任，成為設備管理的一部分。
真正要管理的是十年後仍能做選擇
我不期待工廠裡每台舊設備都能立刻補齊完美的軟體清單。實務上可以從新採購與高風險資產開始，先建立最低要求，再逐步補上既有設備。即使供應商無法提供完整 SBOM，也至少應記錄韌體版本、外部連線、遠端維護方式、已知關鍵元件與支援期限。
這件事表面上是資安治理，底層其實是選擇權治理。當供應商停止服務、元件爆出弱點、雲端產品退場或法規改變時，企業能不能盤點影響、隔離風險、替換依賴，而不是只能停機或繼續冒險？
智慧工廠談了很多即時資料、AI Agent 與數位分身，但所有智慧能力最後都落在一層層軟體依賴上。那些依賴若看不見、查不到、換不了，再漂亮的架構也只是把不確定性包進設備外殼。
所以我現在採購一台智慧設備，不只問它今天能做多少，也會問十年後還剩下哪些路可以走。知道裡面有什麼、誰負責維護、何時會退場，以及出問題時怎麼退回安全狀態，才是真正可持續的智慧製造。