El CERT-In (Equipo de Respuesta a Emergencias Informáticas de la India), dependiente del MeitY (Ministerio de Electrónica y Tecnología de la Información), ha ido ampliando progresivamente su papel como autoridad nacional en materia de ciberseguridad desde su designación en virtud de la Ley de Modificación de la Tecnología de la Información de 2008.
En 2024, CERT-In publicó sus primeras directrices específicas sobre la SBOM (Software de componentesSoftware ), en las que se definen los elementos mínimos, los formatos y los requisitos de implementación.
Apenas un año después, en julio de 2025, la versión 2.0 amplió considerablemente su alcance, extendiendo la cobertura a SBOM, QBOM, CBOM, AIBOM y HBOM, y consolidando aún más las cadenas de suministro de software seguras como una estrategia nacional fundamental para la resiliencia.
Para los directores de sistemas de información (CIO) y los directores de seguridad de la información (CISO), estas directrices tienen implicaciones operativas, financieras y normativas. Las organizaciones deben estar preparadas para demostrar que sus prácticas en materia de SBOM están listas para ser auditadas, garantizar que los proveedores y socios cumplan los requisitos de cumplimiento normativo y adoptar la automatización para gestionar las SBOM a gran escala.
Este artículo ofrece una guía detallada para cumplir con las directrices del CERT-In sobre la lista de materiales de seguridad (SBOM), y abarca el alcance, las normas técnicas, la selección de proveedores y las mejores prácticas para las empresas indias y las organizaciones internacionales con operaciones en la India.
- Directrices de CERT-In sobre la SBOM: alcance, aplicabilidad y requisitos clave
- Cómo ayuda OPSWAT a cumplir los requisitos de CERT-In
- Ajustar Software al cumplimiento de la SBOM de CERT-In
- Formatos de SBOM y normas técnicas aceptados en el marco de CERT-In
- Cómo evaluar y seleccionar proveedores de servicios de cumplimiento de la SBOM
- Buenas prácticas para una implementación fluida de la SBOM
- Automatizar, cumplir con la normativa y proteger: el OPSWAT para la gestión de la SBOM
- MetaDefender Software Chain™
- Preguntas frecuentes
- Consideraciones específicas por sector: instituciones financieras, Supply Chain e infraestructuras críticas
- ¿Y ahora qué? Es fundamental prepararse para las directrices de Cert-In sobre SBOM
Directrices de CERT-In sobre la SBOM: alcance, aplicabilidad y requisitos clave
¿Qué es CERT-In y por qué ha publicado unas directrices sobre la SBOM?
CERT-In es la agencia nacional de ciberseguridad de la India. Sus directrices sobre la lista de materiales de seguridad (SBOM) tienen por objeto reforzar la seguridad de la cadena de suministro, mejorar la visibilidad de los componentes de software y garantizar respuestas más rápidas y estandarizadas ante las vulnerabilidades.
¿Qué es CERT-In y por qué ha publicado unas directrices sobre la SBOM?
El cumplimiento normativo se aplica a la administración pública, el sector público, los servicios esenciales y los exportadores de software, así como a los desarrolladores, integradores y distribuidores a lo largo de todo el ciclo de vida del software.
Core de una SBOM según las directrices del CERT-In
Según las directrices, las listas de materiales de software (SBOM) deben incluir datos tales como:
- Nombre del componente, versión, proveedor y licencia
- Dependencias y origen
- Vulnerabilidades y estado de los parches
- Fechas de fin de vida útil, restricciones de uso y nivel de criticidad
- Identificadores únicos, sumas de comprobación e información sobre el autor
Al exigir estos elementos mínimos, CERT-In garantiza que las SBOM sean útiles, legibles por máquina y estén preparadas para su auditoría.
Cómo ayuda OPSWAT a cumplir los requisitos de CERT-In
OPSWAT facilita la automatización y la recopilación de los campos de datos del SBOM de CERT-In, con el fin de ofrecer visibilidad y transparencia en las principales áreas, desde los detalles de los componentes de software hasta la transparencia y los riesgos, pasando por las licencias y el uso.
Detalles Software
- Nombre del componente: Nombre del componente de software o de la biblioteca.
- Versión del componente: Número de versión o identificador del componente.
- Proveedor del componente: Entidad que suministra el componente (proveedor, tercero o código abierto).
- Origen del componente: Procedencia del componente (propietario, de código abierto o de terceros).
- Identificador único: código específico para el seguimiento del componente a lo largo de las distintas versiones y cambios de titularidad.
- Autor de los datos del SBOM: entidad responsable de crear la entrada del SBOM.
- Marca de tiempo: Fecha y hora en que se registró la entrada de la SBOM.
Software y riesgos Software
- Dependencias del componente: Otros componentes o bibliotecas de los que depende este.
- Vulnerabilidades: Problemas de seguridad conocidos relacionados con el componente, con indicación de su gravedad y referencias CVE.
- Estado del parche: Disponibilidad de la última actualización o parche para las vulnerabilidades.
- Sumas de comprobación o hash: valores criptográficos que permiten verificar la integridad de los archivos.
- Propiedad «Ejecutable»: indica si el componente se puede ejecutar.
- Propiedad de archivo: indica si el componente está empaquetado como un archivo comprimido.
- Fecha de lanzamiento: Fecha en la que se lanzó por primera vez el componente.
Licencias y condiciones de uso
- Licencia del componente: Tipo de licencia y condiciones que rigen el uso del componente.
- Restricciones de uso: Limitaciones legales o reglamentarias relativas al uso de los componentes.
Ajustar Software al cumplimiento de la SBOM de CERT-In
El cumplimiento de la norma CERT-In es un proceso gradual que requiere la coordinación entre los equipos de desarrollo, seguridad, operaciones y cumplimiento normativo. Cada parte implicada desempeña un papel en la creación, el mantenimiento y el intercambio de SBOM en diferentes etapas del ciclo de vida del software.
La siguiente tabla, que recoge el contenido y los ejemplos de las Directrices Técnicas de CERT-In, ilustra cómo las responsabilidades relacionadas con la SBOM se corresponden con los componentes de software habituales:
| Software | Ejemplo | Nivel de la lista de materiales (SBOM) | Autor de la lista de materiales (SBOM) | ¿Por qué? |
|---|---|---|---|---|
| Aplicación principal | Una aplicación de análisis de datos | SBOM a nivel de aplicación | Creado por el equipo de desarrollo de productos | Lista completa de materiales (SBOM) entregada junto con la aplicación al cliente o al organismo regulador |
| Software clave Software [base de datos, marco de trabajo] | PostgreSQL | SBOM de primer nivel | Desarrollado internamente si el proveedor no facilitó una lista de materiales de software (SBOM) | Garantiza la trazabilidad de los componentes críticos |
| Plataforma/Middleware [p. ej., servidor web, entorno de ejecución] | Server Apache Tomcat | Lista de materiales de entrega | Proporcionado por la plataforma/el proveedor | Se comparte tras la adquisición; integra componentes proporcionados por el proveedor |
| Bibliotecas y SDK de terceros | Postfix y el SDK de Twilio | SBOM transitiva | Creado por el proveedor principal o internamente si no está disponible | Abarca las dependencias indirectas y los servicios externos |
Una vez definidos los roles y las responsabilidades, las organizaciones pueden pasar a las medidas prácticas para garantizar el cumplimiento normativo. Una hoja de ruta por fases ayuda a desarrollar la madurez en el ámbito del personal, los procesos y la tecnología.
1. Realizar una evaluación del estado de preparación y un análisis de deficiencias
Identificar las prácticas actuales en materia de inventario de software, seguimiento de vulnerabilidades y listas de componentes de software (SBOM) facilitadas por los proveedores. Compararlas con los campos de datos y formatos exigidos por CERT-In.
2. Establecer una política interna de SBOM y una estructura de gobernanza
Defina funciones claras para los equipos de desarrollo, operaciones de TI, compras, seguridad y cumplimiento normativo. La gobernanza garantiza que las listas de materiales de seguridad (SBOM) se elaboren, mantengan y compartan de forma coherente en toda la empresa.
3. Seleccionar e implementar herramientas de generación de SBOM
La automatización es fundamental. Las herramientas deben:
- Generar SBOM para cada nueva versión, parche o actualización
- Integración con flujos de trabajo de DevOps, repositorios de código fuente y registros de contenedores
- Exportación en formatos CycloneDX y SPDX para el cumplimiento normativo
4. Integrar los flujos de trabajo de la lista de materiales de seguridad (SBOM) en el ciclo de vida del desarrollo de software (SDLC) y en los procesos de adquisición
Incorporar la generación de SBOM en todas las fases del ciclo de vida del desarrollo de software:
- SBOM de diseño: componentes previstos
- SBOM de origen: dependencias de desarrollo
- Generar SBOM: durante la compilación
- SBOM analizada: inspección posterior a la compilación
- SBOM implementada: entorno de instalación
- SBOM en tiempo de ejecución: supervisión de los componentes activos
Los contratos de adquisición deberían exigir a todos los proveedores la presentación de una lista de componentes de software (SBOM).
5. Mantener el cumplimiento normativo y la preparación para las auditorías
Establecer actualizaciones continuas de la SBOM, integrarla con avisos de vulnerabilidad como VEX (Vulnerability Exploitability eXchange) y CSAF, y garantizar un almacenamiento y un intercambio seguros mediante cifrado, HTTPS y firmas digitales.
¿Quieres saber cómo aprovechar la SBOM en tu estrategia de seguridad?
Formatos de SBOM y normas técnicas aceptados en el marco de CERT-In
CycloneDX y SPDX: los estándares aceptados
CERT-In reconoce CycloneDX y SPDX como los principales formatos legibles por máquina para la automatización de las listas de materiales de seguridad (SBOM).
- CycloneDX: ligero, centrado en la seguridad y optimizado para la gestión de vulnerabilidades
- SPDX: un formato centrado en las licencias y ampliamente utilizado para la documentación de cumplimiento normativo
Cómo evaluar y seleccionar proveedores o soluciones de cumplimiento de la SBOM de CERT-In
La elección del proveedor o la solución adecuados es fundamental tanto para el cumplimiento normativo como para la eficiencia operativa.
Criterios clave para evaluar el cumplimiento de la SBOM por parte de los proveedores según CERT-In
- Compatibilidad con SPDX y CycloneDX
- Integración con los procesos de DevOps y los flujos de trabajo de CI/CD
- Capacidad para generar varios niveles de SBOM (diseño, compilación, implementación y tiempo de ejecución)
- Informes preparados para auditorías y mecanismos de intercambio seguro
Preguntas que se deben plantear a los posibles proveedores sobre la compatibilidad con CERT-In
La selección de los socios adecuados es tan importante como el establecimiento de procesos internos de SBOM. Los directores de sistemas de información (CIO) y los responsables de compras deberían incluir la conformidad con CERT-In en sus listas de requisitos para las solicitudes de propuestas (RFP) y de diligencia debida. Entre las preguntas clave que deben plantearse se incluyen:
- ¿Proporcionan listas de materiales de software (SBOM) en formatos aprobados por CERT-In (SPDX, CycloneDX)?
- ¿Con qué frecuencia se actualizan sus SBOM: solo con cada lanzamiento o de forma continua?
- ¿Qué soluciones de automatización ofrecen para la generación, validación y intercambio seguro de listas de materiales (SBOM)?
- ¿Cómo se garantiza la distribución segura de la SBOM (por ejemplo, mediante cifrado, RBAC o firmas digitales)?
- ¿Se integra su solución con los flujos de trabajo de DevOps, las bases de datos de vulnerabilidades y los avisos de CERT-In?
- ¿Cómo se gestionan las auditorías de cumplimiento y la presentación continua de informes reglamentarios?
Plantear estas preguntas desde el principio ayuda a garantizar que los proveedores no solo cumplan con los requisitos sobre el papel, sino que también sean capaces de mantener prácticas de SBOM que se ajusten a las directrices en constante evolución de CERT-In.
Lista de verificación para la selección e incorporación de proveedores
- Es compatible con los campos de datos y formatos exigidos por CERT-In
- Automatiza la generación, el seguimiento y las actualizaciones
- Ofrece controles de acceso basados en roles y un intercambio seguro de archivos
- Adopción demostrada en sectores regulados
Buenas prácticas para una implementación fluida de la SBOM
Estrategias probadas para grandes empresas
- Empieza con los flujos de trabajo básicos y ve aumentando la madurez con el tiempo
- Exigir la presentación de una SBOM en todos los contratos de adquisición
- Adopta un enfoque de «shift-left» integrando la generación de la SBOM en las primeras fases del ciclo de vida del desarrollo de software (SDLC)
- Formar al personal sobre la importancia de la SBOM y los requisitos normativos
Errores comunes y cómo evitarlos
Incluso las iniciativas de SBOM bienintencionadas pueden fracasar si las organizaciones las abordan de forma superficial. CERT-In hace hincapié en que los SBOM deben ser precisos, exhaustivos y actualizarse continuamente. A continuación se enumeran algunos de los errores más comunes y cómo evitarlos:
| Error habitual | Explicación | Cómo evitarlo |
|---|---|---|
| Considerar el SBOM como un informe estático | Muchas organizaciones generan una SBOM en el momento del lanzamiento y nunca la actualizan. Esto hace que no sean conscientes de las vulnerabilidades introducidas por los parches, las actualizaciones o las nuevas dependencias. | Considera la SBOM como un inventario dinámico. Automatiza las actualizaciones a través de tu canalización de CI/CD para que cada nueva compilación o lanzamiento actualice los datos de la SBOM. |
| No incluir las dependencias transitivas | Pasar por alto los componentes indirectos, como las bibliotecas de código abierto que se incorporan a través de otras dependencias, genera puntos ciegos peligrosos que los atacantes aprovechan. | Utilice herramientas de generación automática de SBOM que identifiquen de forma recursiva todas las dependencias directas y transitivas, garantizando una cobertura completa de toda la cadena de suministro de software. |
| Depender de la creación manual sin automatización | La compilación manual de la SBOM requiere mucho tiempo, es propensa a errores y resulta insostenible a escala empresarial. Además, aumenta el riesgo de que los formatos no sean uniformes. | Integra la automatización y la estandarización. Adopta herramientas que generen SBOM en formatos aprobados por CERT-In, como SPDX y CycloneDX, y exige su validación antes del lanzamiento. |
Si evitan estos errores e integran las prácticas de SBOM en los flujos de trabajo diarios de desarrollo, las organizaciones pueden convertir el cumplimiento normativo en una ventaja estratégica, reduciendo el riesgo y cumpliendo al mismo tiempo los requisitos de CERT-In.
Preparación para las auditorías
Mantener repositorios completos de la lista de materiales de seguridad (SBOM), documentar las prácticas de gobernanza y ajustarse a las plantillas de auditoría de CERT-In.
Prepararse para los cambios normativos
La hoja de ruta de CERT-In ya apunta a unos requisitos de la lista de materiales (BOM) más amplios (hardware, inteligencia artificial y nube). Las empresas que adopten herramientas escalables y flexibles estarán en mejor posición para adaptarse.
Automatizar, cumplir con la normativa y proteger: el OPSWAT para la gestión de la SBOM
OPSWAT
OPSWAT ayuda a los desarrolladores a tener un control preciso de los componentes de software presentes en el código fuente y los contenedores. Manténgase un paso por delante de los atacantes, identifique amenazas y detecte vulnerabilidades sin afectar a la velocidad de desarrollo.
Lista de materiales de Software (SBOM) para Software y artefactos Software
Permite a los equipos de desarrollo de software identificar, priorizar y resolver las vulnerabilidades de seguridad y los problemas de licencia relacionados con las dependencias de código abierto.
Lista de materiales de Software (SBOM) para Software y artefactos Software
Permite a los equipos de desarrollo de software identificar, priorizar y resolver las vulnerabilidades de seguridad y los problemas de licencia relacionados con las dependencias de código abierto.
Lista de materiales de software (SBOM) para Container
Analizar imágenes de contenedores y generar una SBOM con el nombre del paquete, la información de la versión y las posibles vulnerabilidades.
MetaDefender Software Supply Chain™
No se limite al cumplimiento de la SBOM y haga frente a los ataques avanzados y en constante evolución que afectan a la cadena de suministro de software.
OPSWAT MetaDefender Software Supply Chain ofrece una mayor visibilidad y una defensa sólida frente a los riesgos de la cadena de suministro. Con nuestras tecnologías de detección y prevención de amenazas de confianza cero, su ciclo de vida del desarrollo de software (SDLC) queda protegido frente al malware y las vulnerabilidades, lo que refuerza la seguridad de las aplicaciones y el cumplimiento normativo.
Detectar malware en el código
La combinación de más de 30 motores antivirus aumenta las tasas de detección y evita de forma eficaz que el malware infecte estaciones de trabajo, contenedores o código fuente.
Identificar los datos confidenciales codificados de forma estática
DLPTM Proactive identifica credenciales como contraseñas, claves secretas, tokens, API u otra información confidencial que haya quedado en el código fuente.
Secure contra Supply Chain
Analizar y evaluar cualquier malware, vulnerabilidad u otros riesgos potenciales que puedan existir en cada capa de una imagen de contenedor.
Integraciones simplificadas
Tanto si tu equipo utiliza repositorios de código fuente, registros de contenedores, servicios binarios o una combinación de herramientas, MetaDefender Software Supply Chain integraciones nativas con las plataformas más populares para garantizar la seguridad a lo largo de todo el ciclo de vida del desarrollo de software (SDLC).
Preguntas frecuentes
¿Qué sanciones se aplican en caso de incumplimiento de las directrices del CERT-In sobre la lista de materiales de seguridad (SBOM)?
Auditorías normativas y posibles restricciones en los contratos con la administración pública y los servicios esenciales. El incumplimiento de las directrices del CERT-In sobre la lista de materiales de seguridad (SBOM) puede dejar a las organizaciones expuestas a filtraciones de datos, lo que puede acarrear multas elevadas.
¿Con qué frecuencia deben actualizarse las listas SBOM?
Cada vez que se lance una nueva versión, una actualización, un parche o se cambie de proveedor.
¿Se pueden incluir componentes de código abierto y de terceros?
Sí. Es imprescindible tener una visibilidad completa de todas las dependencias, tanto directas como transitivas.
¿Están exentas las empresas más pequeñas?
Las empresas emergentes que no pertenecen a sectores regulados pueden beneficiarse de un alivio limitado, pero se recomienda encarecidamente su adopción.
¿En qué medida se ajusta el CERT-In a las normas internacionales?
El enfoque de la India se ajusta a marcos internacionales como el del NIST y la Ley de Ciberresiliencia de la UE, lo que garantiza la compatibilidad transfronteriza.
¿Cómo se deben gestionar las notificaciones de vulnerabilidades?
A través de los avisos de VEX y CSAF,integrados con las alertas de CERT-In y los sistemas internos de SBOM.
¿Qué papel desempeña la automatización?
La automatización permite garantizar el cumplimiento normativo de forma continua, reduce los errores humanos y asegura la escalabilidad en entornos de TI híbridos.
Consideraciones específicas por sector: instituciones financieras, Supply Chain e infraestructuras críticas
Sector financiero
Los bancos y las entidades financieras no bancarias deben adaptar sus prácticas en materia de SBOM a las disposiciones del Banco de la Reserva de la India (RBI) sobre ciberseguridad, con requisitos de auditoría más estrictos para el tratamiento de datos sensibles.
Supply Chain
Los proveedores deben presentar las listas de materiales de software (SBOM) como parte de los contratos. Las organizaciones deben mantener inventarios de SBOM internos y externos con fines de transparencia y gestión de riesgos.
Infraestructuras críticas
Sectores como las telecomunicaciones, la defensa y la energía se enfrentan a solapamientos normativos. Las prácticas relacionadas con las listas de materiales de seguridad (SBOM) deben integrarse en marcos más amplios de resiliencia de los sistemas y seguridad nacional.
¿Y ahora qué? Es fundamental prepararse para las directrices de Cert-In sobre SBOM
Las directrices sobre SBOM de CERT-In marcan un punto de inflexión para las empresas indias. Lo que comenzó como un enfoque limitado a las SBOM se ha convertido ahora en un marco integral para la visibilidad de la cadena de suministro de software y la gestión de riesgos.
La tecnología OPSWAT va más allá del cumplimiento normativo, ya que ofrece visibilidad de la cadena de suministro a lo largo de todo el ciclo de vida del desarrollo de software (SDLC) e integra seguridad multicapa con repositorios de código, registros de contenedores y procesos de DevOps.
Descubra cómo OPSWAT ayudar a su empresa a simplificar el cumplimiento de la normativa CERT-In SBOM y a proteger su cadena de suministro de software.
