圖1 2015年至2020年軟體產品漏洞攻擊事件(資料來源：Sonatype<2020>，工研院整理)以下針對產品開發週期中，常見的供應鏈資安攻擊來源進行說明：
(一)產品設計階段：這類型攻擊通常使用Google Play或是Apple App Store和其他第三方應用程式配送平台，將隱藏惡意程式公開傳播到行動裝置。駭客通常會設計為看起來合法的應用程式，但可能夾帶廣告軟體、竊取信用卡資訊。例如：XcodeGhost事件，該攻擊手法起源於Apple應用程式開發者出於方便選擇了中國當地第三方管道（如：百度、迅雷，或者從社交平台等）下載開發程式，而這些開發程式庫被注入稱之為「XcodeGhost」的惡意程式，導致開發者編譯出來的App都帶有後門程式，行動裝置上可能在非授權情況下將隱私資訊提交給第三方。
(二)產品開發階段：這攻擊主要透過獲得開發者帳戶存取權限來修改開源程式，再運用常用軟體包進行傳播的惡意程式，以便於竊取受害者的機敏資料。例如：2020年2月駭客鎖定Ruby開發者常用的開發工具發動供應鏈攻擊，駭客在提供程式庫和程式的市集RubyGems上架超過700個惡意軟體，並使用正牌程式的名稱和功能說明，使得開發者難以辨識這些惡意軟體，上架不久後就被開發者下載10萬次。
(三)產品部署階段：這種攻擊通常是指運用被盜或偽造憑證簽章，將惡意程式透過軟體更新時帶到攻擊目標，並透過網路或硬體進一步擴大感染其他的下游客戶電腦。例如：2020年12月14日知名資安供應商SolarWinds坦承，從2020年3月到6月間釋出的SolarWinds Orion Platform 2019.4 HF 5至2020.2.1版本遭到駭客入侵，目前安裝含漏洞Orion Platform版本的客戶數接近1.8萬家。
綜上所述，新型態的供應鏈攻擊可以在科技產品開發生命週期的任何階段，鎖定以產品為目標，讓攻擊方得以實現存取、間諜活動和營運活動破壞。通常駭客都會採取簡單的欺騙戰術，例如：將惡意軟體偽裝成合法產品，或者使用間接手段來存取和修改正版程式碼，甚至駭客還可能利用第三方工具、共享程式庫和第三方程式碼（如：開源軟體）進行滲透。此外，許多軟體生命週期結束之後，由於缺乏安全漏洞的修補與更新，使得傳統的軟體增加資安風險。然而，要避免供應鏈威脅發生，則應該確保企業使用的每個產品都是可信賴產品，必須導入安全設計原則、自動化安全測試、軟體供應鏈溯源，以及監測產品行為，確保禁止任何非授權的使用者操作，其強化產品安全性和品質。
國際政策開始引導產業採用產品安全開發標準，並推動產品資安合規驗證
從2018年起各國政府開始陸續制定供應鏈安全政策（如表1），紛紛要求其關鍵產業針對供應鏈進行資安風險管理，最顯著的例子就是2017年9月歐盟提出「Cybersecurity Act」，已於2019年6月27日正式生效，並預期2023年將有許多資通訊產品（如：5G設備）將被列入強制認證項目。
其二，美國2020年4月29日美國國務卿蓬佩奧（Mike Pompeo）所宣布的「5G Clean Path政策」，以及美國國防部在2020年1月底公布基於NIST SP 800-171所設計的供應鏈網路安全成熟度認證（Cybersecurity Maturity Model Certification，CMMC）。目前國防部的供應鏈大約有三十萬家承包商，而其中根據美國國防部統計約有29萬家（97％）基本上沒有任何的網路安全措施，CMMC框架是一組強制性的網路安全要求，國防部供應鏈中的所有承包商都必須實施，然後由獨立的CMMC第三方評估組織（C3PAO）進行驗證。美國國防部並在2020年第三季開始大約10個RFP（Request for Proposal）中包括CMMC要求，並計畫在2026年之前讓CMMC成為所有國防部採購案的必要需求。
表1 國際政策與法規發展趨勢
|
國家
|
單位
|
相關法規描述
|
|
美國
|
白宮
|
2019年5月川普總統簽署「Executive Order on Securing the Information and Communications Technology and Services Supply Chain」行政命令
2021年2月拜登總統簽署「Executive Order on America’s Supply Chains」，其中涵蓋要求部會提出資安因應做法
|
|
國務院
|
推動5G乾淨網路計畫
|
|
國土安全部
|
2018年11月成立「ICT Supply Chain Risk Management Task Force」，參加者包含20個政府單位、40家ICT與晶片大廠參加。
2019年開始參與者合力研擬合格製造商清單，以防堵有安全風險的ICT產品。
|
|
商務部
|
NIST於2018年發布Cybersecurity Framework （CSF）1.1版，特別將「供應鏈風險管理」增列至核心類別
2021年2月NIST宣布發布NISTIR 8276《資通供應鏈風險管理的關鍵實踐：產業觀察》
|
|
歐盟
|
ENISA
|
2017年9月歐盟再提出「Cybersecurity Act」，已於2019年6月27日正式生效。
2020年6月歐盟將公布ICT產品、流程與服務優先清單，2023年將被列入強制認證項目
歐洲議會智庫（European Parliament Think Tank）於2020年10月22日呼籲歐洲議會建立強制性的歐盟供應鏈盡職調查制度，而歐盟委員會已開始發表研究報告和進行公眾諮詢。
|
|
日本
|
NICT
|
日本在2018年版的《資通安全戰略》中，強調加強企業的能力，呼籲供應鏈各方積極協作，透過企業間多樣化的連接，創造有價值的供應鏈。
日本政府定在2020年提交資安技術安全法案——《特定高度電信普及促進法》。
|
|
中國
|
中國標準化委員會
|
中國標準化委員會2018年10月正式發布了國家標準GB/T 36637-2018《資訊安全技術ICT供應鏈安全風險管理指南》。
2020年4月，中華人民共和國中央網路安全和資訊化委員會辦公室、中華人民共和國國家發展和改革委員會等12個部門聯合發布了《網路安全審查辦法》。
|
上述的政策與法規促使國際大廠將供應鏈資安納入企業風險評估項目，不僅是產業對於其供應鏈資安治理風險管理，同時各廠也日益擔心ICT產品與服務之供應鏈中的威脅與漏洞，陸續開始要求其供應鏈滿足特定產品資安認證（如表2），加入整體產業導入安全設計原則。對於許多公司而言，為了確保自己所開發的產品系統是安全的，因此需要一套開發人員可遵守的軟體安全設計原則和最佳實務指引。透過產品安全開發標準有助於強迫開發者於工作中嚴格遵守軟體安全開發流程（包含：架構、設計、開發和部署的資安規則），也有助於將系統的嚴重瑕疵降到最低。
表2 國際資安標準與相關認證方案
|
產業
類別
|
消費物聯網
|
先進製造
|
運輸產業
|
醫療電子
|
電信產業
|
半導體設備
|
|
資安
標準
|
EN 303645
|
IEC 62443
|
ISO 21434
TS 50701
|
ISO 14971
UL2900
|
3GPP SCAS
|
SEMI6506
SEMI6566
|
|
認證
方案
|
歐盟EUCC
|
歐盟ICCS
|
歐盟EUCC
|
UL2900
|
GSMA NESAS
|
TBD
|
|
市場
採用
|
芬蘭、新加坡、印度、英國、英DTG等
|
歐盟國家
|
預計汽車產業將採用ISO 21434；歐盟鐵道產業將採用TS 50701
|
美國FDA認可醫療設備測試可遵循UL資通安全標準
|
超過10家電信商採用，包含：德國電信、西班牙電信、Vodafone、三大中國電信等
|
TSMC、Intel等
|
資料來源：工研院（2021）
軟體開發流程將持續整合自動化安全測試技術
許多產品通常是由複雜且不完善的軟體元件所組成，其中可能潛藏許多資安漏洞，而軟體系統安全性測試是安全軟體開發生命週期中的一種重要工具。它涵蓋從早期開發階段一直到生產階段的多種技術，傳統上產業只著重事後產品漏洞修補，當發生資安事件而導致產品故障，廠商不僅要為此投入大量資源修復漏洞，也同時支付一大筆罰款。
為了避免事後修補而造成額外的成本，就需要在開發流程執行高效系統安全測試，然而成效的關鍵則取決於在軟體開發生命週期進行測試的時間和頻率，當組織採用敏捷開發方法和DevOps時，軟體安全測試需要自動化整合到開發工作流中，並極大化自動檢測功能，包含：
- 靜態測試：可掃描軟體的原始程式檔，精準地找出安全問題的根本原因，並幫助修復其中暗藏的安全漏洞。
- 動態測試：動態測試會以可控管的方式對執行中的網路應用程式或服務模擬攻擊，找出執行中環境內可利用的弱點。
- 交互式安全性測試：透過對正在運行的程式碼進行檢測，利用混合靜態和動態分析技術來測試漏洞。
- 模糊測試：透過自動化、系統化方式向受測系統發送無效，或意外輸入來檢查軟體二進製檔案和程式庫中的資安漏洞，尤其是網路協議和檔案格式。
2019年開始Synopsys就開始將其旗下主要的產品進行整合取得階段性成果，例如：在2019年對CI/CD（Continuous Integration/Continuous Deployment 或是Continuous Delivery）工具（例如Jenkins和Jira）的支持顯著增加，其中Coverity、Seeker和Black Duck的等技術都整合成建構／測試／部署週期的一部分，現在Synopsys的產品被客戶視為一個整合度相當完整的平台。Synopsys的Polaris軟體平台已成為所有Synopsys安全測試產品的中央管理工具。此外，供應商的整合開發環境套件管理工具Code Sight也已整合到產品線中，可提供開發人員的安全測試提供完整使用者體驗。
加強軟體供應鏈透明化與可追溯性
當今軟體程式開發中，程式碼的很大一部分是依賴外部供應商（例如：開源軟體）所組成。然而，開源程式可能帶有重大漏洞，而且由於使用相當頻繁，因此潛在影響非常大（例如：Apache Struts存在遠端程式執行漏洞）。此外，授權限制也可能是開源軟體元件使用的問題，挑戰取決於軟體是內部員工使用，還是販售或轉售。因此軟體組成的源頭、軟體的可信度應該在整個產品供應鏈中共享確保軟體元件透明化管理，其中要滿足軟體供應鏈透明化，需要建立一套完整元件清單，有時也稱為“軟體物料清單（Software BOM）。目前市場採用率上，以美國美國商務部的國家電信和資訊管理局（NTIA）已經確立SBOM的重要性，此外美國FDA也要求醫療電子設備應該將SBOM納入採購的標準。國際上SBOM標準化也陸續被廣泛討論中，如SWID、Common Platform Enumeration（CPE）、SPDX、CycloneDX等。
國際上開始有業者推出相關解決方案，包括：Snyk和WhiteSource（兩者可提供容器應用程式掃描產品），以及Sonatype和Revenera（以前稱為Flexera），它們提供相關功能，例如：資料庫功能（以控制Open Source Software的使用）。此外，一些軟體安全測試工具大廠，也開始看見軟體組成分析工具的需求的成長，而發展在其產品上增加軟體組成分析功能，例如：Checkmarx的Contrast Security、Veracode和Synopsys。以下是軟體組成分析可提供的能力：
- 開源軟體辨識：將開源程式碼（和其他軟體）添加到程式的標準編譯技術來鑑定特定軟體開發包。另一種方式是掃描程式碼本身來辨識特定的程式。除了直接程式元件外，還標記引用的第三方程式。
- 軟體授權識別和風險評估：開源軟體幾乎是授權協議的條款進行發布，這個授權協議說明軟體的使用方式。由於存在數十個授權協議，並且條款差異很大。有些限制嚴格，有些幾乎沒有限制。若限制性嚴格的授權協議可能對軟體營運帶來重大的法律風險和智慧產權損失。工具可指示有問題的授權條款，分析特定授權條款來決定是否使用該開源軟體。
- 軟體漏洞分析：開源軟體也隱含漏洞，軟體組成分析解決方案的一項關鍵功能是辨識隱含漏洞的開源軟體。該功能已成為工具的差異化要素，供應商依靠大量的公共和私有資料庫來判斷開源軟體是否隱藏高危險漏洞。
- 軟體治理和控制：企業希望對應用程式中使用開源軟體部分進行版本控制，如果開發人員想要下載未經批准的軟體套件，例如：存取GitHub和Stack Exchange會被瀏覽器擋下。
- 報告和分析：辨識和預防軟體供應鏈風險時，SBOM的建立和共享會變得更加重要。工具應提供使用中的程式碼、程式碼之間的依賴性，以及使用程式碼的位置。SBOM報表有助於快速確定新漏洞或問題的潛在影響，使得資安團隊可以快速確定是否使用特定軟體，以及在何處使用該程式，並依此展開計劃補救措施。
建立產品供應鏈持續性安全評估機制
為了要銷售出去的產品在維運階段仍然能夠確保產品安全，產業開始導入產品持續性監測方案，透過主動式監控產品行為，以偵測系統異常行為，以及不正常資料傳輸或流動。產品必須假設總有一天駭客會找到漏洞攻破系統，因此產品設計應該建立多層次防禦，一旦駭客滲透到系統中必須能夠運用監控資料的移動或修改，判斷是否存在可疑或惡意行為。目前國際大廠亦透過策略合作或整併，來提升產品持續性監測。如：NTT和DENSO為強化5G車聯網服務安全，共同開發車輛安全營運中心（V-SOC）技術，DENSO提供可蒐集車輛運作資訊的車載系統，再由NTT提供的5G把資料送到雲端做即時監控分析，掌握自駕車的安全狀況。
此外，持續性漏洞也是強化產品安全重要方向之一，例如：趨勢科技與Snyk共同打造的資安防護服務（SaaS）專們提供產業能夠持續掌握開源軟體漏洞，讓企業能夠強化軟體漏洞的風險管理，且支援漏洞的優先排序，並提供修補建議。
結論
受到政府與國際大廠對安全性和隱私的需求日益提高，加上新法規要求驅動下軟體產品安全開發需求不斷成長。雖然安全開發生命週期概念已經存在數十年，但真正問題仍沒有因此解決，特別是近年來興起的軟體供應鏈資安威脅。各國政府積極投入資源發展相關產品安全開發標準，以及產品安全成熟度評估檢測方法，並紛紛打算成立實驗室進行產品安全測試與認證。
過去產業因為各國政府、關鍵基礎設施業者要求採購之科技產品因資安事件而導致產品故障，不僅台灣廠商要為此投入大量的資源修復漏洞，也同時支付了一大筆罰款。如今安全已成為產品競爭力的一環，該趨勢下將加速各種垂直產業（如：5G、工業物聯網、汽車電子、醫療電子等）要求其所屬供應鏈採用安全開發標準，以便於產品通過認證。
其次，則是加速建立產品開發流程能夠整合自動化軟體安全測試技術，未來產業可以思考導入完整安全軟體開發流程，取代片面檢測驗證，在設計的前期，就主動追蹤發掘資安漏洞，並快速完成修補。
除了安全測試之外，也開始重視開源軟體、第三方軟體供應鏈之溯源追蹤，如同硬體供應鏈一樣，軟體來自哪裡、有哪些安全風險，透過軟體溯源分析以充分了解軟體物料清單（Software Bill of Materials），確保掌握軟體源頭、漏洞與風險程度，並在生命週期內能提供安全修補程式。
最後，產品必須假設總有一天駭客找到漏洞攻破系統，因此產品設計應該建立多層次防禦，一旦駭客滲透到系統中必須能夠運用監控資料的移動或修改，判斷是否存在可疑或惡意行為。
參考文獻
[1] Sonatype, “2020 State of the Software Supply Chain Report”, 2020.
[2] The National Counterintelligence and Security Center(NCSC), “Software Supply Chain Attacks”, 2021.
[3] Consortium for IT Software Quality TM (CISQ), “Trustworthy Systems Manifesto”, 2020.
[4] Jon Boyens (NIST), Celia Paulsen (NIST), Nadya Bartol (Boston Consulting Group), “Case Studies in Cyber Supply Chain Risk Management: Palo Alto Networks, Inc.”, 2019.
[5] Jon Boyens (NIST), Celia Paulsen (NIST), Nadya Bartol (Boston Consulting Group), “Case Studies in Cyber Supply Chain Risk Management: Seagate Technology” , 2019.
[6] European Union Agency for Cybersecurity, “Guidelines for Securing the Internet of Things: Secure Supply Chain for IoT”, November 2020.
[7] National Telecommunications and Information Administration, “Software Bill of Materials (SBOM),” August 18, 2020.
[8] McLean, Virginia: MITRE Corporation, “Deliver Uncompromised: A Strategy for Supply Chain Security and Resilience in Response to the Changing Character of War”, August 2018.
[9] Office of the Under Secretary of Defense for Acquisition & Sustainment “Cybersecurity Maturity Model Certification (CMMC) Model v1.02”, March 2020.
[10] 王萌: Brightsight, “IoT安全認證標準趨勢與IoT設備組件認證介紹” , May 2021.
