【臺灣資安大會直擊】安全產品開發流程成產業標配，IEC 62443-4-1改版在即，聚焦3大重點：對齊國際、預設安全、SBOM與開源

產品資安的態勢在2025年有重大轉變，在全球資安法規與標準的快速演進下，安全軟體開發生命週期（SSDLC）更成為檯面上的焦點，重要性顯著提升，成為應對資安挑戰並確保產品合規的關鍵要求。例如，大家可能沒想過的是，這一兩年，包括造船產業、醫療器材產業等，已經積極透過建立嚴格的資安規範，讓SSDLC成為必備條件。

此外，我們這幾年持續報導物聯網安全法規、軟體供應鏈等議題時，經常介紹Security by Default（預設即安全）、SBOM（軟體物料清單）、開源軟體安全等新興資安概念，如今這些概念也成為產品安全合規的實質要求。

安全產品開發流程日益受重視，一些產業規範已納入必需要求

過去經常在臺灣資安大會發表演說的國際自動化協會（ISA）臺灣分會會長林上智，他今年特別強調SSDLC、IEC 62443-4-1流程標準的重要性，原因在於這些領域出現了顯著的新進展，而他之所以能掌握第一手資訊，正是因為他目前正主導IEC 62443-4-1流程標準的修訂工作。

簡單來說，IEC 62443標準，是國際廣泛採納與認可的工業自動化及控制系統標準，而IEC 62443-4-1的部分，主要聚焦在「安全產品開發生命週期（Secure Product Development Lifecycle（SPDLC）requirements」的要求。而上述SPDLC其實與SSDLC具有相同的概念，強調：從產品的需求分析、設計、實作與測試，以及產品上線後的缺陷管理、更新，還有使用者手冊等相關文件，一直到產品生命週期結束，都必須將資安要素融入每一個階段。

在這次演說中，林上智特別闡釋了IEC 62443-4-1的最新發展現況，揭示其影響性與最新變化。

從影響性來看，林上智指出，近年造船產業、醫療產業都已經將IEC 62443-4-1納入強制要求，讓SSDLC要求成為必備。

因此我們可以看出，IEC 62443-4-1似乎在產業間變得越來越重要，過去廠商導入可能多是自我要求或供應鏈要求，現在有些產業規範則是明確定義這方面的要求。

林上智進一步解釋，以造船產業而言，國際船級協會聯合會（IACS）去年7月正式實施了UR E26與UR E27規範，這是網路安全首次強制要求納入船級規則，換言之，新造船舶若沒有符合UR E26或UR E27的要求，將無法通過驗船，等於無法投保與下水營運，因此，其實質效力已等同於法律法規。

其中UR E27最為重要，當中針對船上設備與系統提出具體要求，並明確規範軟體開發流程必須遵循SDLC（軟體開發生命週期）的要求。林上智指出，在UR E27中更是直接引用了IEC 62443-4-1標準，甚至詳細列出相關章節編號，包括SM-8與SUM-2，這突顯了該規範已針對對船舶設備具關鍵影響的開發流程進行了精選，並將其納入強制性要求。

以醫療產業而言，包括美國、歐盟、臺灣等食品藥物監管單位，也都針對生產血壓計、MRI等醫療設備製造商提出網路安全要求，上市前都必須通過資安相關的檢驗。這當中最受矚目的一例，是美國食品藥物管理局（FDA）2023年9月發布的醫療器材資安指引，當中清楚載明需參考IEC 62443標準，並直接點名IEC 62443-4-1。由此可見，在其他產業的開發流程中，IEC 62443-4-1標準也被廣泛採用。

IEC 62443-4-1標準改版聚焦三大方向：對應國際、預設安全、SBOM與開源軟體安全

關於SSDLC的議題，事實上，這些年我們持續報導這方面的消息，不只IEC 62443-4-1標準開發流程認證受重視，國際間也有諸多重要參考資源，包括ISO 27034，NIST SSDF，以及OWASP SAMM等。

近年還有美國CISA與多國網路安全單位，亦發布Security by Design的警報與相關指引，以及最新歐盟網路韌性法（Cyber Resilience Act，CRA）等法規實施的消息。

在這次演說中，林上智搶先公開了IEC 62443-4-1的最新變化，揭露這項標準的現行修訂方向，首先就是強調對齊國際標準與法規態勢而來，另也指出Security by Default、SBOM等面向的強化，在此我們整理出未來3大改版重點：

●改版重點一：對應國際框架與準則

目前市面上有眾多標準與框架，這對產品與系統開發商造成了一定的困擾。因此，林上智指出，修訂IEC 62443-4-1的首要任務，就是要與其他國際標準及法規進行全面的比較與對應，以確保更有效對應當前的資安挑戰。

例如，他們的4-1工作小組，已檢視美國NIST SSDF軟體開發安全框架（NIST SP 800-218），以了解IEC 62443-4-1是否需要補充或調整，這方面已有成果展現。林上智表示，今年3月他們已發布相關白皮書，比較IEC 62443-4-1標準，NIST SSDF框架，找出一些無法對應的項目的原因，納入改版考量，當中也有相當少部分是完全無法對應的內容，主要是顆粒度較細的要求。

特別的是，他們也審視了半導體產線設備資安標準規範SEMI E187，當中也有包含開發流程的對應，預計這方面的對應很快就可以公開，而安全功能方面則是會對應到IEC 62443-4-2。

另一個大家關注的重點，是最新的歐盟CRA網路韌性法，林上智表示，他們已展開對應分析，若發現IEC 62443-4-1標準與CSA要求存在落差，將會研議在新的條文中進行補強或調整。

●改版重點二：聚焦「Security by三兄弟」概念強化

這次改版的另一大重點，是這兩年美國政府與多國網路安全單位不斷提倡的「Security by Design」、「Security by Default」與「Security by Demand」，林上智用Security by三兄弟這樣的簡稱，方便大家認識與記憶。

林上智指出，過去IEC 62443-4-1便一再強調Security by Design的原則，因此這部分預計不會有太大的變動。例如，安全功能應該在一開始就被納入考量、設計與實作，而非產品設計完才疊床架屋地進行補強。

他更希望大家謹記，Security by Design的意義在於，並非僅僅增加安全功能，而是決定產品是否值得信賴的關鍵。

本次改版的重心，主要放在Security by Default、出廠時預設即安全。這意味著使用者在購買產品後，無需進行過多的操作、額外的複雜設定或支付額外費用，即可具備防禦常見攻擊手法的能力，也就是讓使用者「不設定」也安全。

不過，林上智指出，要將Security by Default概念融入標準內，並不容易處理，尤其需要考量到工業控制環境中設備使用年限較長等特殊狀況。他以FTP為例說明，由於FTP本身不夠安全，若依預設即關閉的原則處理，但在工廠等特定場景中，就可能出現因FTP關閉而不能生產的情況。

換言之，若要讓Security by Default能落實，其實非常看場景、場域與情境。

林上智表示，這幾個月來，他們4-1工作小組與美國CISA等單位不斷討論，尤其是Security by Default與可用性的兩難問題，因為Security by Default必需要存在，可是又不能影響可用性。

他們目前討論結果是，將從層次更高的風險評估、風險建模，並依照場域、場景、情境來決定產品要怎麼做設定，才是所謂的Security by Default，並持續對外徵集不同意見。

此外，還有像是產品不應存在使用者不知情的後門程式，目前共識是任何使用者不知情的程式都算，若有工程帳號或Debug帳號使用者必須知曉這些所有存在的帳號，相關討論持續在進行。

同時他也強調，Security by Default不會是獨立的章節，而是會分散到每一個開發章節之內。

●改版重點三：強化SBOM與開源軟體安全管理

最後一個改版重點，是加強對軟體供應鏈與開源軟體的安全管理。

林上智指出，在改版會議中，他們深入探討了軟體供應鏈的各項議題，特別是美國政府於2021年發布的行政命令，該命令已經明確要求美國聯邦政府在採購軟體時，必須提供軟體物料清單（SBOM）。

過去，IEC 62443-4-1雖然提到軟體裡面要有inventory，也就有這樣的概念存在，但並未明確定義SBOM一詞。因此，本次改版將新增相關要求，強制建立SBOM的管理機制。

雖然標準只會規範「應該」做，不會具體規定「如何」做。但林上智也分享其經驗，指出目前主流的三種SBOM格式，包括SPDX（ISO 59626）、CycloneDX、SWID（ISO 19770），前兩者是他通常會建議的選項。原因在於，SPDX是Linux基金會的專案，若業者的產品與嵌入式系統或Linux相關就很適用，若要轉換為其他格式也可行，但需確保轉換後的正確性；CycloneDX亦廣泛被採用，其精美的介面令人印象深刻。至於最終選擇何種格式，則取決於企業自身的需求。

至於SBOM表的生成，林上智表示，SBOM表可以在軟體開發的不同階段生成，無論是在需求規格階段、程式碼階段，或是建置、測試或執行階段，目前常見作法是在程式碼開發階段產生，但他提醒，需注意可能發生的誤判，因為某些函式庫（library）的使用情況，可能是在執行當下才能確定。目前，對於應在何種階段產生SBOM，並無嚴格的規範。

或許有些人認為，SBOM僅是一份清單或列表，但林上智強調，SBOM應被視為一種信任機制。它並非漏洞報告，也不是單純的產出結果，而是協助我們管理軟體的信任基礎。

在SBOM之外，另一重點是開源軟體管理，也是這次改版的強化方向。林上智解釋，之前IEC 62443-4-1與開源軟體最相關的部分，是SM9章節的第三方套件，但原先規範顆粒度較粗，可能導致管理上的疏漏。

因此，這次會特別針對開源軟體進行規範，畢竟，現在很少有開發者會從頭編寫一個完整的程式，其重要性不言而喻。

林上智也透露，若企業在開源軟體開發上，遇到不確定如何進行的情況，雖然IEC 62443-4-1本身不會提供具體做法，但會在補充指引增加一些建議。例如，可以參考ISO/IEC 18974標準，此為Linux基金會旗下的專案，聚焦OpenChain安全保障規範，目的是協助企業在使用開源軟體時，透過特定的流程與機制，處理相關的資安注意事項。

綜上所述，我們可以了解目前IEC 62443-4-1改版討論的方向與重點，林上智也提到他們正持續徵集意見，以完善這次針對安全開發流程內容的修訂。