CERT-In （印度计算机应急小组）隶属于 MeitY（电子和信息技术部），自 2008 年《信息技术修正法案》指定以来，一直在稳步扩大其作为国家网络安全管理机构的作用。
2024 年，CERT-In 发布了第一份关于 SBOMSoftware 材料清单）的专门指南，定义了最低要素、格式和实施要求。
仅一年后，即 2025 年 7 月，2.0 版大幅扩大了范围，将覆盖面扩展到 SBOM、QBOM、CBOM、AIBOM 和 HBOM，进一步将安全软件供应链确立为国家核心抗灾战略。
对于首席信息官和首席信息安全官来说，这些指导方针会带来运营、财务和监管方面的后果。企业必须做好准备，展示审计就绪的 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 | Transitive 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 流程同样重要。首席信息官和采购负责人应将 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，即使是用心良苦的 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 要求（硬件、人工智能和云）。采用可扩展、灵活工具的企业将处于适应的最佳位置。
自动化、合规和保护：OPSWAT 的 SBOM 管理方法
Software 和工件的 SBOM
使软件开发团队能够识别、优先处理和解决开源依赖项的安全漏洞和许可问题。
Software 和工件的 SBOM
使软件开发团队能够识别、优先处理和解决开源依赖项的安全漏洞和许可问题。
Container 图像的 SBOM
分析容器镜像，生成包含软件包名称、版本信息和潜在漏洞的 SBOM。
MetaDefender 软件 Supply Chain™
超越 SBOM 合规性，应对先进的、不断演变的软件供应链攻击。
OPSWAT MetaDefender Software Supply Chain提供更高的可视性和对供应链风险的强大防御。借助我们的零信任威胁检测和预防技术，您的软件开发生命周期（SDLC）可免受恶意软件和漏洞的侵害，从而加强应用程序的安全性和合规性。
检测代码中的恶意软件
30 多种防病毒引擎的组合提高了检测率，有效防止恶意软件感染工作站、容器或源代码。
识别硬编码秘密
主动式 DLPTM 可识别密码、机密、令牌、API 密钥等凭证或其他遗留在源代码中的敏感信息。
Secure 集装箱Secure ，防范Supply Chain 攻击
评估和评价容器镜像每一层下存在的任何恶意软件、漏洞或其他潜在风险。
集成变得简单
无论您的团队是使用源代码库、容器注册表、二进制服务，还是组合使用各种工具，MetaDefender 软件 Supply Chain 都能提供与流行平台的本地集成，以确保整个 SDLC 的安全。
常见问题
不遵守 CERT-In SBOM 指南会受到什么处罚？
监管审计以及与政府和重要服务机构签订合同的潜在限制。不遵守 CERT-In SBOM 准则可能会使组织容易受到数据泄露的影响，从而导致巨额罚款。
SBOM 必须多久更新一次？
每次发布新版本、更新、补丁或更换供应商时。
能否包含开源和第三方组件？
是的。对所有依赖关系--直接依赖关系和传递依赖关系--的完全可见性是强制性的。
小型企业是否可以豁免？
受监管行业以外的初创企业可能获得的救济有限，但我们强烈鼓励它们采用这种方法。
CERT-In 如何与全球标准保持一致？
印度的方法反映了NIST和欧盟《网络复原力法》等国际框架，确保了跨境兼容性。
如何处理漏洞披露？
通过与 CERT-In 警报和内部 SBOM 系统集成的VEX 和 CSAF警报。
自动化能发挥什么作用？
自动化可实现持续合规性，减少人为错误，并确保混合 IT 环境的可扩展性。
特定部门的考虑因素：金融机构、Supply Chain和关键基础设施
金融部门
银行和非银行金融公司必须使 SBOM 的做法与 RBI 的网络安全授权保持一致，并对敏感数据的处理提出更严格的审计要求。
Supply Chain
供应商必须将 SBOM 作为合同的一部分。各组织应维护内部和外部 SBOM 清单，以提高透明度并进行风险管理。
关键基础设施
电信、国防和能源等行业面临监管重叠的问题。SBOM 实践必须与更广泛的系统复原力和国家安全框架相结合。
下一步是什么？为 SBOM 指南做好准备至关重要
CERT-In SBOM 准则标志着印度企业的一个转折点。从最初对 SBOM 的狭隘关注，到现在扩展为软件供应链可视性和风险管理的全面框架。
OPSWAT SBOM 技术超越了合规性，在整个 SDLC 中嵌入了供应链可视性，并将多层安全性与代码库、容器注册表和 DevOps 管道集成在一起。
了解OPSWAT 如何帮助您的企业简化 CERT-In SBOM 合规性并确保软件供应链的安全。
