CERT-In (印度電腦緊急應變小組) 隸屬於 MeitY (電子與資訊技術部)，自從根據 2008 年資訊技術修正法案被指定為國家網路安全主管機關以來，其角色一直在穩步擴大。
2024 年，CERT-In 針對 SBOMSoftware 物料清單）發佈了第一份專用指引，定義了最小元素、格式和實施要求。
僅一年之後，在 2025 年 7 月，2.0 版大幅擴大了範圍，將覆蓋範圍擴大到 SBOM、QBOM、CBOM、AIBOM 和 HBOM，進一步將安全軟體供應鏈確立為國家核心復原策略。
對於 CIO 和 CISO 來說，這些準則會對營運、財務和法規造成影響。組織必須作好準備，以展現稽核就緒的 SBOM 作法、讓供應商與合作夥伴符合法規要求，並採用自動化以管理規模 SBOM。
本文提供了達成 CERT-In SBOM 指導方針合規性的逐步路線圖，涵蓋範圍、技術標準、供應商選擇，以及適用於印度企業和在印度營運的全球組織的最佳實務。
CERT-In SBOM 指導方針：範圍、適用性和主要要求
什麼是 CERT-In？為什麼它要發佈 SBOM 指導方針？
CERT-In 是印度的國家網路安全機構。其 SBOM 指導方針旨在強化供應鏈安全、提高軟體元件的可視性，並確保對漏洞做出更快速、標準化的回應。
什麼是 CERT-In？為什麼它要發佈 SBOM 指導方針？
合規性適用於政府、公共部門、基本服務和軟體出口商，以及整個軟體生命週期的開發商、整合商和代理商。
根據 CERT-In 指南的 SBOMCore 要素
根據指引，SBOM 必須包括以下資料：
- 元件名稱、版本、供應商和授權
- 依賴與起源
- 漏洞和修補程式狀態
- 使用期限、使用限制和關鍵性
- 唯一識別碼、校驗和及作者資訊
透過要求這些最基本的元素，CERT-In 可確保 SBOM 可執行、機器可讀，並可供稽核。
OPSWAT SBOM 如何協助滿足 CERT-In 要求
OPSWAT SBOM有助於 CERT-In SBOM 資料欄位的自動化與收集，從軟體元件詳細資訊、透明度與風險、授權與使用等主要領域提供可視性與透明度。
Software 元件詳細資訊
- 元件名稱：軟體元件或資料庫的名稱。
- 元件版本：元件的版本號或識別碼。
- 元件供應商：提供元件的實體（廠商、第三方或開放原始碼）。
- 元件來源：元件來源 (專屬、開放源碼或第三方)。
- 唯一識別碼：用來追蹤不同版本和所有權的元件的獨特代碼。
- SBOM 資料的作者：負責建立 SBOM 項目的實體。
- 時間戳記：記錄 SBOM 記錄的日期和時間。
Software 透明度與風險
- 元件依賴：此元件依賴的其他元件或函式庫。
- 漏洞：與元件相關的已知安全問題，包括嚴重性和 CVE 參考資料。
- 修補程式狀態：目前漏洞的更新或修補程式可用性。
- 校驗和或切細值：驗證檔案完整性的加密值。
- 可執行屬性：元件是否可執行。
- 歸檔屬性：元件是否包裝為歸檔檔案。
- 發佈日期：元件首次釋出的日期。
授權與使用
- 元件授權：使用元件的授權類型與條款。
- 使用限制：元件使用的法律或法規限制。
Software 元件符合 CERT-In SBOM 規範
實現 CERT-In 合規性是一個分階段的過程，需要開發、安全、運營和合規性團隊之間的協調。每個利害關係人都會在軟體生命週期中的不同階段，扮演建立、維護和共用 SBOM 的角色。
下表包含來自 CERT-In 技術指南的內容和範例，說明 SBOM 的責任如何與常見的軟體元件相結合：
| 元件Software軟體 | 範例 | SBOM 等級 | SBOM 作者 | 為什麼？ |
|---|---|---|---|---|
| 主要應用 | 資料分析器應用程式 | 應用層級 SBOM | 由產品開發團隊建立 | 完整的 SBOM 連同應用程式交付給客戶或監管機構 |
| 關鍵Software 元件 [資料庫、架構] | PostgreSQL | 頂層 SBOM | 若供應商未提供 SBOM，則由內部開發 | 確保重要元件的可追蹤性 |
| 平台/中介軟體 [例如：網路伺服器、運行環境] | Apache TomcatServer | 交付 SBOM | 由平台/供應商提供 | 採購時共享；整合供應商提供的元件 |
| 第三方程式庫/SDK | Postfix & Twilio SDK | 轉換式 SBOM | 由上游供應商建立，若無法取得，則由內部建立 | 涵蓋間接從屬關係和外部服務 |
定義角色和責任後，組織便可進入符合規定的實際步驟。分階段的路線圖有助於建立人員、流程和技術的成熟度。
1.進行就緒評估和差距分析
識別軟體清單、弱點追蹤和供應商提供的 SBOM 的現行做法。將這些與 CERT-In 所需的資料欄位和格式對應。
2.建立內部 SBOM 政策與治理架構
為開發人員、IT 作業、採購、安全和法規遵從團隊定義明確的角色。管治可確保 SBOM 在整個企業中一致地建立、維護和共用。
3.選擇並實施 SBOM 生成工具
自動化至關重要。工具必須
- 為每個新版本、修補程式或更新產生 SBOM
- 與 DevOps 管道、原始碼倉庫和容器註冊處整合
- 以 CycloneDX 和 SPDX 格式輸出，用於法規校準
4.將 SBOM 工作流程整合到 SDLC 和採購中
在每個 SDLC 階段嵌入 SBOM 生成：
- 設計 SBOM：已規劃的元件
- 原始 SBOM：開發依賴
- 建立 SBOM：在編譯期間
- 分析的 SBOM：建造後檢查
- 已部署的 SBOM：已安裝的環境
- 運行時 SBOM：監控使用中的元件
採購合約應強制所有供應商交付 SBOM。
5.保持持續的合規性和審計就緒狀態
建立持續的 SBOM 更新，與 VEX (Vulnerability Exploitability eXchange) 和 CSAF 等弱點公告整合，並透過加密、HTTPS 和數位簽章確保安全儲存和共用。
想要瞭解如何利用 SBOM 來實現您的安全策略嗎？
CERT-In 接受的 SBOM 格式和技術標準
CycloneDX 和 SPDX：公認的標準
CERT-In 認可 CycloneDX 和 SPDX 為 SBOM 自動化的主要機器可讀格式。
- CycloneDX: 輕量級，以安全為中心，針對弱點管理最佳化
- SPDX：以授權為重點，廣泛採用於合規檔案
如何評估和選擇 CERT-In SBOM 相容供應商或解決方案
選擇正確的供應商或解決方案對於合規性和作業效率都至關重要。
評估 CERT-In SBOM 符合性供應商的主要標準
- 支援 SPDX 和 CycloneDX
- 與 DevOps 管道和 CI/CD 工作流程整合
- 能夠產生多重 SBOM 層級 (設計、建置、部署、運行時)
- 審計就緒的報告和安全的共用機制
詢問潛在供應商關於 CERT-In 整合的問題
選擇合適的合作夥伴與建立內部 SBOM 流程同樣重要。CIO 和採購領導者應將 CERT-In 一致性作為其 RFP 和盡職調查清單的一部分。需要詢問的關鍵問題包括
- 您是否提供 CERT-In 認可格式 (SPDX, CycloneDX) 的 SBOM？
- 您的 SBOM 每隔多久更新一次？
- 您能為 SBOM 生成、驗證和安全共用提供哪些自動化功能？
- 如何強制執行安全的 SBOM 發佈（例如加密、RBAC、數位簽章）？
- 您的解決方案是否與 DevOps 管道、弱點資料庫和 CERT-In 建議整合？
- 您如何支援合規性稽核和持續的法規報告？
事先詢問這些問題有助於確保供應商不僅在紙面上符合規定，而且有能力維持符合 CERT-In 不斷演進的準則的 SBOM 實踐。
供應商選擇和入職檢查清單
- 支援 CERT-In 所需的資料欄位和格式
- 自動生成、追蹤和更新
- 提供以角色為基礎的存取控制和安全共用
- 在受監管行業中的實際應用
無縫 SBOM 實作的最佳範例
適用於大型企業的成熟策略
- 從基礎工作流程開始，逐步擴大成熟度
- 在所有採購合約中規定 SBOM 的交付
- 在 SDLC 早期整合 SBOM 生成，採用左移方法
- 就 SBOM 意識和法規要求對員工進行培訓
常見錯誤與避免方法
即使是用意良好的 SBOM 計畫，如果組織只是敷衍了事，也可能會失敗。CERT-In 強調 SBOM 必須準確、全面，並持續更新。以下是一些最常見的陷阱以及如何避免它們：
| 常見錯誤 | 說明 | 如何避免 |
|---|---|---|
| 將 SBOM 視為靜態報告 | 許多組織在發行時會產生 SBOM，但從未更新。這會讓他們對修補程式、更新或新的相依性所引進的弱點視若無睹。 | 將 SBOM 視為一個活生生的庫存。透過 CI/CD 管道自動更新，讓每次新的建置或發行都能刷新 SBOM 資料。 |
| 未包含反式依賴關係 | 忽略間接的元件，例如由其他依賴項目拉入的開放原始碼程式庫，會造成危險的盲點，讓攻擊者有機可乘。 | 使用自動化的 SBOM 產生工具，可遞迴映射所有直接和轉式的依賴關係，確保完全涵蓋整個軟體供應鏈。 |
| 依賴手動製作而沒有自動化 | 手動編譯 SBOM 既費時又容易出錯，而且在企業規模上無法持續。這也增加了格式不一致的風險。 | 整合自動化與標準化。採用以 CERT-In 認可格式（如 SPDX 和 CycloneDX）產生 SBOM 的工具，並在發佈前強制執行驗證。 |
通過避免這些錯誤，並將 SBOM 實踐嵌入到日常開發工作流程中，組織可以將合規性轉化為戰略優勢，在滿足 CERT-In 要求的同時降低風險。
準備審計
維護完整的 SBOM 儲存庫、記錄管理實務，並與 CERT-In 稽核範本保持一致。
面向未來的法規變更
CERT-In 的路線圖已經暗示了更廣泛的 BOM 要求（硬體、AI 和雲端）。採用可擴充、靈活工具的企業將最能適應。
自動化、合規和保護：OPSWAT 的 SBOM 管理方法
Software 套件與工件的 SBOM
讓軟體開發團隊能夠識別、優先處理和處理開放源碼相依性的安全漏洞和授權問題。
Software 套件與工件的 SBOM
讓軟體開發團隊能夠識別、優先處理和處理開放源碼相依性的安全漏洞和授權問題。
Container 影像的 SBOM
分析容器映像，併為包名稱、版本資訊和潛在漏洞生成 SBOM。
MetaDefender Software Supply Chain™
超越 SBOM 規範，並應對先進、不斷演進的軟體供應鏈攻擊。
OPSWAT MetaDefender Software Supply ChainMetaDefender 軟體供應鏈安全解決方案提供更廣泛的可視性，以及對供應鏈風險的強大防禦。透過我們的零信任威脅偵測與防禦技術，可確保您的軟體開發生命週期 (SDLC) 不受惡意軟體與漏洞的威脅，強化應用程式的安全性與合規性。
偵測程式碼中的惡意軟體
30 多個防毒引擎的組合可提高偵測率，並有效防止惡意軟體感染工作站、容器或原始碼。
識別硬編碼金鑰
主動式 DLPTM 可識別密碼、機密、權標、API 金鑰等憑證，或遺留在原始碼中的其他敏感資訊。
保護 以防供應鏈攻擊
評估和評估容器映像每一層下存在的任何惡意軟體、漏洞或其他潛在風險。
整合變得簡單
無論您的團隊是使用原始碼儲存庫、容器註冊、二進位服務，或是結合各種工具，MetaDefender Software 供Supply Chain 都能提供與熱門平台的原生整合，以確保您整個 SDLC 的安全。
常見問題
不遵守 CERT-In SBOM 指導方針會受到什麼處罰？
監管審計以及與政府和基本服務簽訂合約的潛在限制。不遵守 CERT-In SBOM 指導方針可能會使組織容易遭受資料外洩，進而被處以高額罰金。
SBOM 必須多久更新一次？
在每次新版本、更新、修補程式或供應商變更時。
是否可以包含開放原始碼和第三方元件？
是的。必須完全瞭解所有的依賴關係 - 直接依賴關係和轉換依賴關係。
規模較小的企業是否獲得豁免？
受規管行業以外的新創公司可能獲得有限的寬免，但我們強烈鼓勵採用。
CERT-In 如何與全球標準接軌？
印度的方法反映了NIST和歐盟網路復原法等國際架構，確保了跨境相容性。
應該如何處理漏洞揭露？
透過VEX 和 CSAF 諮詢，與 CERT-In 警報和內部 SBOM 系統整合。
自動化扮演什麼角色？
自動化可持續符合法規、減少人為錯誤，並確保混合 IT 環境的可擴充性。
特定產業的考量：金融機構、Supply Chain和關鍵基礎設施
金融業
銀行和 NBFC 的 SBOM 作業方式必須符合 RBI 的網路安全規定，並對敏感資料處理提出更嚴格的稽核要求。
Supply Chain
供應商必須提供 SBOM 作為合約的一部分。組織應維護內部和外部的 SBOM 目錄，以提高透明度並進行風險管理。
關鍵基礎設施
電信、國防和能源等部門都面臨監管重疊的問題。SBOM 的做法必須與更廣泛的系統彈性和國家安全框架相結合。
下一步是什麼？為 SBOM 準則作好準備至關重要
CERT-In SBOM 指導方針標誌著印度企業的轉折點。從一開始對 SBOM 的狹隘關注，到現在擴展為軟體供應鏈可視性和風險管理的全面框架。
OPSWAT SBOM 技術超越了法規遵循的層面，將供應鏈可視性嵌入整個 SDLC，並將多層安全性與程式碼儲存庫、容器註冊處和 DevOps 管道整合在一起。
瞭解OPSWAT 如何協助您的企業簡化 CERT-In SBOM 合規性，並確保軟體供應鏈的安全。
