2026年7月29日，CISA 發布了 《2026年網路安全基準最低要素》Software Bill of Materials (SBOM)，取代自2021年起實施的國家電信與資訊管理局（NTIA）基準，該文件由美國國家安全局（NSA）、聯邦調查局（FBI）以及15個國際網路安全機構共同起草。
《2026 年軟體物料清單（Software ）最低要素規範》（Bill of Materials (SBOM) ）是美國網路安全與基礎設施安全局（CISA）針對軟體物料清單（SBOM）必須包含哪些資料所更新的規範，其中最具影響力的變更在於結構而非數量：2026 年的要素規範並未禁止根據原始碼清單生成 SBOM，但要求編製者須聲明 SBOM 的生成方式、對可執行產物進行雜湊運算，並為無法填入資料的每個欄位加上標籤。 僅基於清單的 SBOM 現可透過機器可讀的形式揭露其自身的缺漏。
MetaDefender Software Supply Chain 這是OPSWAT 的軟體供應鏈安全平台，旨在分析軟體構件、二進位檔和容器映像層——這正是新推出的雜湊值、生成背景及覆蓋範圍要求所所需的數據類別。
一覽無遺
- 17 個資料欄位— 9 個 SBOM 元資料、8 個元件資料
- 6 項實務與流程
- 新增 10 個欄位、8 項重大更新、1 項移除（「存取控制」已併入「分發與配送」）
- 適用於所有軟體，「包括開源軟體、人工智慧軟體及 SaaS」
- 並非新規定——而是對組織生成及請求 SBOM 方式的優化
2026 年 SBOM 變更中，對「僅含原始碼」的 SBOM 而言最難達成的部分
1. 元件雜湊值需要可執行產物
「元件雜湊值」與「元件雜湊演算法」明確規定了雜湊的對象：「將加密雜湊演算法套用至可執行元件產物所產生的輸出結果。」並非清單條目，亦非宣告的版本字串。
- 讀取 package-lock.json、pom.xml 或 requirements.txt 的解析器不會接觸可執行工件，因此這兩個雜湊字段均返回「未知」
- 若已存在雜湊函數，該演算法必須使用 IANA 雜湊函數文字名稱 ，並須經由如 NIST 等權威機構核准
- 正是透過雜湊值，收件人才得以確認所描述的組件與實際寄出的組件相符
2. SBOM 生成背景使該方法成為記錄的一部分
「SBOM 生成背景」是此次新增內容中最不引人注目，卻在結構上最具意義的一項：「SBOM 編寫者生成 SBOM 時所處的相對軟體生命週期階段，以及當時可用的資料。」CISA 定義了三個值——「建置前」、「建置中」和「建置後」——並將每個值與 SBOM 的生成方式掛鉤：從原始碼生成的 SBOM 對應於最早的階段，而透過二進位分析工具生成的 SBOM 則對應於最晚的階段。
- 採購團隊可以指定他們願意接受的生命週期階段，並傾向採用從編譯後的產物中提取的 SBOM，而非源碼層級的 SBOM
- 漏洞管理平台可根據聲明中的上下文對檢測結果進行權重分配
- 源自原始碼的 SBOM 仍屬允許，但不得再被視為與從最終二進位檔產生的 SBOM 等同
3. 廣度取代深度，且無最低要求
2021 年的「深度」要素僅要求頂層依賴項——CISA 現指出，該定義「反映了當時 SBOM 工具的能力，而非做出明智安全決策所需資訊的深度」。涵蓋範圍的要求則更為嚴格：「構成目標軟體的所有元件，包括傳遞性依賴項。沒有最低深度要求。」
此測試具有實用性。若 SBOM 未列出與該漏洞相關的元件，接收方「應能據此推斷，新通報的漏洞不會影響其系統」。未列出即視為證據，但此原則僅在涵蓋範圍足夠完整時才成立。僅靠解析清單，不太可能達到此標準，原因如下：
- 靜態連結及內嵌的程式碼— 不會產生任何清單條目
- C 和 C++ 專案— 沒有任何通用的套件管理工具會追蹤建置時引入的 DLL 和共享物件
- 複製的原始碼——CISA 將其描述為「實質上是一種依賴項，最好以『分支』及『依賴關係』的形式進行追蹤」
- Container 映像層— 透過 layer 指令安裝，而非在清單中宣告的套件
未知資訊現須予以申報
- 作者應將自己未知的信息與被蓄意隱瞞的信息區分開來
- 建議作者建立一套機制，讓收件者能就經刪節的安全相關內容提出查詢
- 「若 SBOM 編寫者隱瞞了必要的元件資料，組織可能會認為該 SBOM 不完整」
- 「容錯」原則已被取代，理由是接收方「有權預期 SBOM 資料的準確性」——如今，「選用不適當工具」所導致的錯誤，已成為接收方進行風險評估時可納入考量的正當因素
CISA 針對 2026 年 SBOM 要素所做的其他變更
變更 | 這是什麼 | 為何這很重要 |
SBOM 作者簽名（新增） | 與 SBOM 作者綁定的數位簽名 | 讓接收方能確認 SBOM 為真實無誤，且在簽署後未經篡改 |
元件授權(新) | 各組件所採用之授權條款 | 揭露版權與合規風險；CISA 指出 SPDX 授權 ID |
機器可處理資料（原名為「自動化支援」） | 僅限 SPDX 和 CycloneDX | 由於 SWID 格式使用不廣，因此已將其移除；同時將接受的格式縮減為兩種 |
零組件製造商（原名：供應商名稱） | 每個元件對應一個命名組織 | 當來源不明時，會新增一個明確的「來源不明」備用選項 |
頻率（更新） | 針對每個包含變更元件的版本、更新及建置，均會產生一份新的 SBOM | 這種節奏很難靠人工維持，這促使各團隊轉向自動化生成 |
彌合建後差距
2026 年的更新反映了 CISA 的評估：SBOM 工具已足夠成熟，足以提出更高要求，而該機構目前預期所需的信息，則位於建置流程的後端。
MetaDefender™Software Supply Chain 可直接從建置後的產出物產生 SBOM 資料：
- 會掃描 artefact、二進位檔和容器映像層，而不僅是依賴檔案
- 透過 可攜式可執行檔 (PE) 元資料及基於簽名的識別方式
- 在 CycloneDX 和 SPDX 中產生 SBOM，並強化現有報告，以呈現先前掃描中遺漏的元件與 CVE
- 參照 GHSA、CVE 及 EUVD，並標記不符合規範的授權
- 可與 CI/CD 建置管線及 JFrog Artifactory 等建置成果註冊庫整合，使 SBOM 生成能伴隨每次建置進行
如欲瞭解MetaDefender 、Software 及Supply Chain 如何在整個開發生命週期中支援 SBOM 要求：
常見問題
CISA 2026 年 SBOM 最低要素有哪些變更？
此次更新新增了十個資料欄位，進行了八項重大修訂，並移除了一項元素。最重大的結構性變更在於將「深度」（Depth）替換為「覆蓋範圍」（Coverage），而包括「元件雜湊值」（Component Hash Value）、「SBOM 生成背景」（SBOM Generation Context）及「SBOM 作者簽名」（SBOM Author Signature）在內的新欄位，則提升了各界對 SBOM 資料生成與驗證方式的期待。
CISA 2026 版本的 SBOM 最低要素是否為強制性規定？
不。CISA 並未設定任何合規期限或執法機制，並明確指出該文件「不構成任何合規、監管或法律目的之建議」。其實質效力源自採購要求，以及援引 SBOM 基準的法規，例如《歐盟網路韌性法案》。
CISA 2026 年 SBOM 最低要素是否要求進行二進位檔分析或建構後分析？
並非明確如此。然而，「元件雜湊值」需要存取可執行 artefact；「SBOM 生成上下文」則要求作者宣告生命週期階段；而未填寫的欄位必須標示為「未知」。因此，僅包含原始碼的 SBOM 既符合格式規範，同時也記錄了自身的缺漏之處。
《CISA 2026》的最低要求是否適用於人工智慧軟體和 SaaS？
是的。適用範圍涵蓋所有軟體，包括開源軟體、人工智慧及 SaaS。CISA 指出，這些類別可能需要額外要素，但並未在此處加以定義，而是參照 2026 年 5 月發布的 G7 關於人工智慧軟體組件清單（SBOM）的聯合指引。
CISA 2026 最低要素規範中，哪些 SBOM 格式是被接受的？
SPDX 和 CycloneDX 被描述為兩種廣泛用於生成和使用 SBOM 的格式。SWID 標籤已被移除，因為「這並非一種廣泛使用的 SBOM 資料格式，且目前尚無多種工具支援」。任何格式的過時版本均不應用於新軟體。
