iT邦幫忙

2026 iThome 鐵人賽

DAY 30
0
Security

從 CSSLP 視角建構恰到好處的軟體安全系列 第 30 篇

Day 29 | 從食安事件談第三方軟體分析與來源完整性驗證

  • 分享至 

  • xImage
  •  

Introduction

食用油檢出一級致癌物「苯駢芘」的事件鬧得沸沸揚揚。

站在一般餐飲店家的角度,這往往是無妄之災:店家既不是黑心榨油廠,也沒有在後巷私煉地溝油,只是單純向合格盤商採購營業用油。結果大廠油品爆出苯駢芘超標,第一線門市立刻迎來顧客的質疑與主管機關的清查要求。

主管機關的後續調查與流向追蹤揭示了供應鏈的真實樣貌:問題油品是沿著特定供應商與特定批號向下游擴散;而問題的根源,往往交織著產地船期品質落差、進料驗收疏漏、製程控溫不當與檢驗監測多項管理缺失。

面對這類風險,下游業者如果只做到:

  • 「供應商有 HACCP」
  • 「供應商有 ISO 22000」
  • 「供應商拿得出檢驗報告(COA)」

實務上依然停留在「盲目相信供應商」的被動層次。

相對地,成熟的企業落實的是:

供應商資格審查 → 批號追蹤 → COA → 進貨抽驗 → 定期第三方檢驗 → 異常批次隔離

這代表管理重點不再只是「供應商有沒有一紙認證」,而是企業自身有沒有建立起第二層品質檢驗與追溯控制。


Discussion

在軟體工程中,向外部引入第三方套件就如同餐廳向盤商進口食材。許多開發團隊往往對自家撰寫的原始碼進行嚴格的審查與測試,卻對「引進門的外部套件」抱持無條件的信任。

然而,從 Apache Log4j 到 XZ Utils 等事件早已證實:「大牌子」不等於零缺陷、更不代表絕對安全。當你將第三方元件(Third-Party Components, TPC)或開源軟體(OSS)引入系統時,你的應用程式就無條件繼承了該元件所有的底層弱點、惡意後門與潛在授權限制。


軟體組成分析(SCA, Software Composition Analysis)

  • 比喻: 拿起食材成分標籤,以檢驗儀器快速比對禁用添加物與有害物質資料庫,清查有無黃麴毒素、過期劣質油或超標雜質。
  • 技術落實: SCA 工具自動掃描專案的相依設定檔,盤點所有直接相依與間接傳遞相依套件(Transitive Dependencies)。SCA 能對接 NVD 等弱點資料庫列出已知 CVE,並分析潛在的傳染性授權(如 Copyleft / GPL)風險,避免企業商業閉源專案陷入被迫公開程式碼的智財爭議。

OWASP 軟體元件驗證標準 (SCVS, Software Component Verification Standard)

  • 比喻: 依據客觀標準評估供貨油廠的製程成熟度;若大品牌工廠爆出環境髒亂、衛生管理長期失能,即便商標再知名,也應列為不合格對象。
  • 技術概念: 運用 OWASP SCVS 所定義的階梯式控制等級(Level 1 至 Level 3),量化評估第三方軟體供應商在軟體建置、安全測試、流程透明度與相依性管理上的成熟度,作為採購准入、分級管理與終止合作的客觀標準。

來源與履歷溯源(Pedigree & Provenance)

  • 比喻: 查驗原油的進口船期、榨油廠、出廠檢驗批號,並確認桶身上的防拆封條完好無損,確保這桶油未在轉運過程中被調包或混入回收油。
  • 技術概念: 軟體的「來源血統(Provenance / Pedigree)」指該元件自誕生以來,包含原始作者、每次 Git Commit 異動、代碼審查紀錄、建置環境與分發路徑的完整歷史脈絡與不可篡改紀錄。組織必須掌握「這行代碼究竟是誰寫的?在哪個官方 Repo 維護?」,防範引入遭惡意攻擊者接管或由可疑匿名帳號維護的污染套件。

Takeaways

Copyleft / Viral License (著佐權 / 傳染型授權)

只要修改、衍生或在特定情況下靜態/動態鏈結包含此授權的程式碼,該軟體在散布或發行時,整體專案的原始碼都必須以相同的授權條款公開開放。常見範例:GNU General Public License (GPL)

Permissive License (寬鬆型授權)

允許企業將該開源組件進行修改、閉源,甚至是包裝進專有的商業產品中重新發行,而不強制要求公開衍生軟體的原始碼。常見範例:MIT License、Apache 2.0、BSD License。

SBOM (軟體物料清單)

一份正式、機器可讀(Machine-readable)的記錄,詳列軟體構建所包含的所有第三方套件、開源依賴項、版本及其相依性關聯。當爆發嚴重漏洞(如 Log4j)時,安全人員可直接透過 SBOM 比對清單,快速定位系統是否受到影響,加速修補應變。

Escrow (程式碼託管)

開發商將軟體原始碼、構建指南與相依配置交付給第三方託管機構保存。
在特定事件發生時(如開發商破產、倒閉、終止支援或嚴重違約),託管機構才會將原始碼釋放給買方。

Further Reading

NICS SBOM (Software Bill of Materials)
https://material.nics.nat.gov.tw/material/maintainable/Guide_to_SBOM_and_OSV_Tools/

OWASP Software Component Verification Standard
https://scvs.owasp.org/


上一篇
Day 28 | 從食材產銷履歷談軟體供應鏈風險
下一篇
Day 30 | 供應商風險治理與事件應變
系列文
從 CSSLP 視角建構恰到好處的軟體安全 共 31 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言