工業控制系統（IACS）與關鍵基礎設施在數位化轉型浪潮下，日益仰賴開源軟體來支援自動化流程、視覺化監控與資料處理。若未落實必要的治理與安全評估，這些開源軟體應用可能成為駭客入侵或系統失效的潛在攻擊面。OWASP 在 2024 年歸納出的「十大開源軟體安全風險」（Top 10 OSS Risks）提供了檢視此一議題的完整視角；以下將逐一引用該清單的原文標題，並從工控領域的脈絡分別探討其風險敘述、常見情況與對應解方。
OSS-RISK-1: Known Vulnerabilities in Dependencies
此類風險意指開源元件已經在 CVE 或其他通路被揭露具備弱點，但工控系統仍持續使用這些含漏洞的版本且無法及時修補，最終讓攻擊者利用「已知弱點」進行滲透。
常見的實際情況:
在工業控制系統與關鍵基礎設施的情境中，軟體一經上線往往長期運行；若為避免高昂的停機維護成本而延後升級計畫，先前已經揭露的漏洞便可能長期存在並持續帶來潛在風險。由於生產線或基礎設施若停擺，往往會遭受重大的經濟與社會衝擊，因此管理階層多半在風險與營運考量之間權衡，進而暫緩修補已知的弱點。
可應對方式:
若在短期內無法停機或處理相容性問題，可先採用網段隔離、防火牆策略及入侵偵測工具等方法，局部阻擋可能的攻擊向量作為補償性控制。之後，可於離線或測試環境中驗證更新程式的功能與相容性，再利用維護時段完成正式修補。同時，也可以在企業層面導入自動化或半自動化的漏洞掃描與版本盤點流程，及早偵測並控管所有已知漏洞，進一步減少系統暴露風險。
OSS-RISK-2: Compromise of Legitimate Package
此風險在於開源專案或其散佈管道被駭客入侵，導致原本「合法」的套件在最新版本中被植入惡意程式，進一步讓使用者在更新時毫無防備地將惡意程式帶入系統。
常見的實際情況:
工控系統由於作業週期長且多仰賴供應商固定提供的更新版本，一旦官方檔案庫或維護者帳號遭到駭入，下游便可能大規模受到影響。過往也曾出現維護者帳號被盜用或套件檔案庫遭到駭入的案例，讓原本安全的專案成為攻擊跳板，且受害者在初期常不自知。
可應對方式:
每次下載更新檔案時，先進行數位簽章（驗證真實性）或雜湊值（檢查完整性）比對，避免在未經檢驗的情況下直接套用「官方更新」。若條件許可，也可導入離線檢測流程或檔案比對機制。供應鏈安全稽核同樣不可忽視，可要求供應商採用多因子驗證、嚴謹的版本管理與安全審查，以降低供應商階段就遭植入惡意程式的風險。
OSS-RISK-3: Name Confusion Attacks
駭客利用與常見套件或函式庫名稱高度近似的手段（例如 typosquatting、brand-jacking），在使用者下載或安裝時造成混淆，最終讓惡意元件被誤以為是官方版本。
常見的實際情況:
開發環境裡，工程師與外包廠商有時候基於習慣或者時間考量，僅透過關鍵字搜尋來定位開源套件；若名稱只差一字或發音類似，容易在匆促中下載錯誤的惡意版本，無意間將其導入生產系統核心區域。
可應對方式:
企業內部可建置受控檔案庫或鏡像系統，集中管理經過稽核的開源套件。不論新安裝或升級，都須經過離線比對程序，核對維護者帳號、專案文件與社群活躍度等資訊，確保所下載的版本確為官方專案。此作法有助於降低名稱混淆攻擊在工控環境中的危害。
OSS-RISK-4: Unmaintained Software
若部分開源元件或其特定版本已停止維護，一旦發生功能缺陷或安全漏洞，也不會再獲得官方修補，長期下來導致風險不斷累積。
常見的實際情況:
工控系統往往運作數年或甚至十數年，若核心函式庫或驅動程式在此期間遭到社群或維護者棄養，當後續發生漏洞時便無法及時獲得修補。過去不乏專案因維護度不足而令下游廠商得自力修補或整體替換，帶來高昂的技術與管理挑戰。
可應對方式:
在設計或採購階段可優先選擇具有長期支援（LTS）或維護週期明確的開源專案。若發現已導入的元件缺乏維護度，則可在社群中尋求替代方案，或於企業內 fork 該專案並持續維護必要功能。同時可在內部實施活躍度檢測並預留足夠安全資源，以應對可能的替換或增修需求。
OSS-RISK-5: Outdated Software
系統長期使用上游已釋出更新版本或安全修補的舊版軟體，卻未能及時升級，導致在舊版本中持續累積已知漏洞與相容性風險。
常見的實際情況:
工控環境向來對穩定度以及可用性高度重視，因此企業常因顧慮升級帶來的營運中斷或者相容性問題而停留在老舊版本。上游雖然持續推出新功能與安全修補，但若下游遲遲不更新，就會堆積大量潛在漏洞，最後在重大事故或系統崩潰時面臨更大的升級難題。
可應對方式:
企業層面可透過 SBOM 定期盤點所有關鍵開源套件版本，並視離線測試結果評估小幅或大幅升級策略。先在沙箱或測試環境檢驗相容，確保在生產中實施時能降低風險。此有計畫的升級方式有助於平衡系統安全與功能可用性，免於被動面對嚴重事故。
OSS-RISK-6: Untracked Dependencies
系統中可能存在經由非標準或間接管道加入的開源套件，開發與維運人員並不知情，無法評估與監控其潛在漏洞或合規風險。
常見的實際情況:
在工控系統的建置與維運過程中，常會因不同功能需求而採用「客製化的驅動程式（custom driver）」、「特定協定介面的程式庫（protocol interface）」或「外包開發團隊撰寫的附加程式碼」，這些都屬於可能由第三方或內部自行打造、非標準管道安裝的軟體元件。若未在軟體物料清單（SBOM）中妥善記錄，便無法使用一般的掃描工具加以偵測，也就無法及時掌握這些元件是否存在漏洞。結果是，一旦某個元件出現安全缺陷，就可能在毫無防備的情況下被引入工廠的生產核心，對整體系統造成潛在風險。
可應對方式:
可從合約與管理流程著手，要求供應商與內部團隊提供並定期更新 SBOM，並採用多種掃描工具（如 FOSSology、Dependency-Check）進行交叉比對，將所有直接或間接依賴統一列入安全報告。一旦發現未被控管的隱藏套件，應立即評估其維護度與授權合規性，並迅速納入正常維運機制，避免成為潛在危害。
OSS-RISK-7: License and Regulatory Risk
開源套件的授權條款或法規相容性若與企業商業模式、產業法規互相衝突，可能引發法律與合規疑慮。若缺乏明確授權，企業亦有可能面臨侵權訴訟風險。
常見的實際情況:
有些開源專案未標示清晰授權，或帶有不適用於工控領域的約束條款，企業在未審查下便導入系統後，若之後牽涉政府採購、出口管制或客戶合約等，恐怕引發重大法規合規風險，也可能因授權爭議被迫中斷使用。
可應對方式:
宜依循 OpenChain ISO/IEC 5230 等標準建立開源合規流程，並結合自動化工具檢測各套件的授權細節，及早排除不明或衝突的元件。亦可在供應商合約條款中規範開源合規責任，要求合作廠商對所採用的套件負起授權符合性義務，避免未來出現版權糾紛或法規違規的狀況。同時也可參考 OpenChain ISO/IEC 18974 開源資安國際標準，以確保在工控環境中導入開源軟體時，兼顧更全面的資安風險管控。
OSS-RISK-8: Immature Software
不成熟的開源專案往往缺乏完善的測試、版本控管和程式碼審核，程式品質與安全性因此無法得到保證，一旦在高負載或特定情境下運行，可能導致崩潰或重大漏洞。
常見的實際情況:
工控環境對系統穩定度要求極高，若選用功能仍不穩定或缺乏安全檢核的新興套件，生產線在面臨高負載或意外情況時可能出現大範圍停工或設備危害。許多處於早期階段的開源專案尚未建立足夠的測試覆蓋率與審核機制。
可應對方式:
在正式導入前，可先於離線環境進行壓力測試、靜態程式碼掃描、已知弱點掃描或模糊測試，並針對高風險環境額外實施滲透測試，以評估各種可能的攻擊向量。此外，也需觀察專案的社群維護度、版本釋出頻率與程式碼審核流程，以及是否已在 CI/CD 或 DevOps 中整合測試程式，綜合判斷該工具是否符合工控領域所需的穩定度與安全門檻。若評估結果顯示該專案尚未達到成熟標準，可考慮採用其他更完善的替代方案，或投入更多資源強化其測試體系，確保能滿足工控環境的要求。
OSS-RISK-9: Unapproved Change (Mutable)
若開源元件的下載方式無法確保版本已固定或透過安全通道進行傳輸，駭客可能在過程中竄改檔案，使最終導入的程式碼與預期不符，導致系統潛在安全風險。
常見的實際情況:
工控系統對版本變動相當敏感，但若開發人員或工程師透過 HTTP 或動態無版本連結下載更新檔，極有可能在毫無警覺的狀態下接收被調包的檔案。這種「未經批准的變更」若進入生產核心區域，將成為難以溯源的安全隱患。
可應對方式:
企業應明訂相關規範，禁止使用 HTTP 或動態 URL 下載開源元件，並強制所有檔案必須具備版本標記、雜湊值驗證或者數位簽章，經測試環境驗收後方可投入生產。同時，需結合完善的變更管理、紀錄制度與組態管理機制，將檔案來源、對應版本、雜湊值與審核意見完整備查，確保在發生異常時能夠迅速追蹤並釐清責任歸屬。
OSS-RISK-10: Under/over-sized Dependency
無論是功能少的套件還是龐大的函式庫，都可能出現規模不成比例的安全與維護風險。前者若維護者帳號遭駭，所有下游使用者都難以倖免；後者若包含許多不必要的功能模組，則會擴大攻擊面並增加潛在漏洞。
常見的實際情況
部分小型專案僅有極少數開發者維護，一旦作者停止維護或帳號被駭，就會大面積波及所有下游使用者。另有一些大型函式庫在工控場景下實際只用到極小部分功能，卻同時承擔其餘模組的安全風險。這種規模失衡常使系統維運的複雜度不斷提升。
可應對方式:
可落實『最小功能原則』，在工控系統中只導入真正需要的功能，避免隨意堆疊過度微小或體量龐大的套件。若預期必須整合大型函式庫，可透過分層網路與功能隔離，將不必要或高風險模組置於次要區域。同時，若能自行開發輕量功能或選擇維護度更佳的替代方案，也有助於降低維運與安全管理上的負擔。
總結：面向工控的開源供應鏈安全
綜觀而言，OWASP 所歸納的這十大風險在工控（OT/ICS）環境中格外明顯。由於系統週期長、穩定度與合規要求嚴苛，任何開源元件若管理不當或包含漏洞，都可能造成大規模停工或公共安全風險。為應對上述挑戰，建議從設計初期便導入安全理念並妥善規劃整體供應鏈控管。
- 採行 Secure by Design
在專案初期就把安全規劃納入系統架構與開發流程，避免後期出現重大漏洞才臨時補救。 - 使用 SBOM（軟體物料清單）
透過 SBOM 全面掌握所用開源元件的版本、來源與維護狀況，有助於在脆弱性爆發時及早確認影響範圍，並快速採取對應措施。 - 落實真實性或完整性驗證
針對所有更新檔案與套件，宜先進行數位簽章或雜湊檢查，避免不明改動在上游被植入；同時也可在組織內建立離線驗證或檔案比對機制，確保「官方更新」實際為官方所發佈。 - 結合分層防禦、嚴謹變更程序與補償性控制
配合網路隔離、防火牆策略、漏洞掃描與多層監控，即使短期內無法立即修補，也能先以臨時補償方案壓制風險擴散。 - 長期維護與合規落實：
工控系統週期長，宜選用維護期清晰且授權合規的開源元件；同時定期評估法規與標準動向，如 OpenChain ISO/IEC 5230、ISO/IEC 18974等，使整體供應鏈安全更具備持久性。
在數位化轉型的趨勢下，上述策略能協助工控業者在提升效率的同時，維持系統韌性與安全，確保關鍵基礎設施及產業營運得以穩定運作。
SZ Lin with Cybersecurity & Embedded Linux 