![](https://s4.itho.me/sites/default/files/styles/picture_size_large/public/field/image/pxl_20240516_030155887.jpg?itok=_6KmeOpI)
攝影/余至浩
近年來,國外許多政府開始要求軟體供應商建立SBOM(Software Bill of Materials,軟體物料清單)。例如美國白宮在2021年發布行政命令,為了強化國家網路安全,要求其供應商都要提供SBOM。歐盟在幾個月前通過《網路韌性法案》(EU Cyber Resilience Act, CRA),同樣要求2027年前軟體供應商必須提供SBOM,不提供的話,將面臨至少1,500萬歐元的罰款。另外還有醫療相關產品,包括在美國FDA和歐盟MDR醫療法規中都有要求SBOM,臺灣食藥署也有相關要求。
林上智是國際自動化協會臺灣分會會長,在今年的臺灣資安大會上,他歸納了企業SBOM當前應用和實務上常見的六大挑戰和迷思,並提出應對的建議。
SBOM指的是軟體物料清單,類似於企業生產管理中常見的BOM表(物料清單)。林上智表示,不同於BOM記載產品本身各項成本、組成件、加工流程及供應商,SBOM軟體物料清單主要記錄軟體構成元件及其關聯表。
他表示,企業採用SBOM有四大好處,首先可以用來加強安全管理,透過獲取軟體元件的版本、名稱來進行CVE或弱點追蹤;其次,它可以掃描授權,確保軟體商業授權和開源軟體授權規範都得到遵守。最重要的是透明度,SBOM表提供了一個透明且共享的平臺,能夠減少資源浪費。最後,SBOM還能降低人力和資源成本。
他舉例說明,一間公司通常會有很多產品線和產品單位,各個不同BU部門可能會使用相似的工具,例如OpenSSL軟體套件,但彼此並不知道對方有使用,版本也各有不同。一旦出現漏洞,可能得花更多人力和時間來修復。有了SBOM表,這種情況就可以避免。
迷思1: SBOM 表可以用各種格式和方法產生
林上智歸納了 SBOM 在應用和實務上的六大挑戰和迷思。第一個誤區是不少人誤以為SBOM表可以用各種格式和方法產生。他引用美國NITA的定義表示,SBOM的內容必須符合一定的格式,且必須是機器可讀的,也就是說不能使用紙本文件來提供。
迷思2: SBOM中只需列出自行開發的軟體,對於使用的開源軟體或商用套裝軟體則不需列入
第二個迷思是認為SBOM中只需列出自行開發的軟體,而對於使用的開源軟體或商用套裝軟體則不需列入其中。他表示,實際上,SBOM應包括產品中所有的軟體元件,不論是自行開發的、開源的還是商用的軟體,只要用在自己的產品中,就應該被列入SBOM,因為這些元件都是產品的一部分。這樣才能提供完整的軟體物料清單,有效管理安全風險和相依性。
迷思3: SBOM表只要購買商業軟體或掃描工具就可以自動建立,不需要人為介入
他提到的第三個常見迷思是認為SBOM表的建立,只要購買商業軟體或掃描工具就可以自動建立,不需要人為介入。但他表示,不同SBOM的格式,有各自支援的工具,包含商業軟體、開源軟體,這些工具都有可能存在誤判或漏判的情況,因此仍然需要人工確認,確保SBOM的準確性和完整性。
迷思4:SBOM表產生後,就意謂完成所有工作
許多企業認為SBOM表產生後,就意謂完成所有工作是第四個常見迷思。林上智強調,「千萬不要以為只要有SBOM表就行,重點是要拿它來做什麼事」。他指出,有些企業會使用SBOM來進行資產盤點和組態管理,也有的會與資安管理和資安開發流程結合,用於管理產品的弱點和檢測潛在的安全與授權問題,這些都是可以應用SBOM的地方。
他也引用美國NTIA對於軟體物料清單的工具分類,分為三大類,第一類是SBOM 表產生工具,這類工具可以透過分析原始碼或執行檔來產生軟體物料清單;第二類是軟體物料清單接受格式的工具,如SW360,這類工具可以用來管理SBOM 表的內容和版本等;第三類是軟體物料清單格式轉換工具,可以在不同格式的SBOM 表之間進行轉換,確保SBOM內容格式的一致性。
迷思5:SBOM產生需要掃描程式碼,沒有程式碼就無法生成
許多人認為產生SBOM一定需要掃描程式碼,沒有程式碼就無法生成SBOM。這是第5個常見迷思。他表示,事實上,SBOM表可以在軟體開發的不同階段生成,包括設計、程式碼、建置、分析、部署環境和Runtime階段。每個階段都可以生成SBOM表,以反映該階段的軟體元件和依賴關係。
他指出,在軟體開發的這六個階段中,通過程式碼生成或分析執行檔產生SBOM是最常見的做法。相比之下, runtime階段產生的SBOM較為少見,但該階段的SBOM内容是最準確的,但也最具挑戰性。他也說,目前法令或法規都只要求要有SBOM,但沒有要求要多準確,一定要在runtime階段做分析。但他認為這是會未來長遠的發展趨勢。
迷思6:使用SBOM表掃描已知漏洞,沒有掃描到代表就很安全
最後一個迷思是使用SBOM表掃描已知漏洞,沒有掃描到代表就很安全。他引用CVE背後的NVD資料庫的說明,有時可能出現可能有弱點,但沒有掃到的情況,例如弱點發布時間差或資料庫還沒更新等。
面對SBOM在實務上的種種挑戰,他建議,企業在開發產品一定要考慮到模組化,這樣在SBOM表管理上會比較容易,他舉例,過去很常看到一體式產品,把所有東西都打包,但這樣的情況下,產品就只會有一個SBOM,就沒辦法看到產品更細步的清單內容,且一旦遇到其中使用的開源軟體有問題需要修正時,就必須整個SBOM表一起修正,沒辦法僅就開源軟體的SBOM表來修改。
再者,他強調,SBOM表的格式選擇很重要。他指出,目前SBOM常用的軟體資料交換格式包括SPDX、CycloneDX和SWID三種。其中,SPDX由Linux基金會推動,也是ISO 5962的標準,是目前最多人使用的格式,並且支援多種資料格式,包含Tag/value、RDF/XML、JSON、yml、xls等。其次是由OWASP力擁的CycloneDX的格式。他也列出這三大SBOM格式 對應到美國NTIA的SBOM表的名稱。
對於企業是否需要將產品的SBOM表公開?他表示,企業不需要公開其產品的 SBOM,而是依法提供給監管機構或特定客戶的要求提供。此外,在SBOM 的保護方面,應涵蓋整個生命周期,包括SBOM 的派送、接受/驗證、資料擷取和管理、ETL(擷取、轉換及載入)過程以及映射和評估管理,以確保SBOM內容的完整性和及時性,防止惡意篡改。
熱門新聞
2024-09-02
2024-09-02
2024-09-06
2024-09-02
2024-09-02
2024-09-03
2024-09-04
2024-09-02