Las SBOM como evidencia de cumplimiento: ISO 27001, SOC 2 y NIS2

Evidencia no es cumplimiento

Un control se cumple con un proceso que funciona. La evidencia demuestra que funciona. Una SBOM demuestra algo concreto: qué contenía una versión determinada. No dice nada sobre el control de acceso, la respuesta a incidentes ni si alguien actuó ante un hallazgo.

También puede ser errónea sin que nadie lo note. Un generador que leyó los archivos equivocados produce una SBOM válida que omite la mitad del producto. El análisis de vulnerabilidades de esa SBOM sale limpio, la plataforma de cumplimiento ve que se ejecutó un análisis y todos los controles aparecen en verde. Qué verifica un control de SBOM de SOC 2 en verde explica ese fallo en detalle.

La evidencia de una SBOM cuenta cuando:

1. Está vinculada a una versión. Una SBOM por cada versión que entregó, no una para el repositorio.
2. Está completa, o dice qué le falta. Una SBOM que declara sus lagunas es fiable en lo que incluye.
3. Se conserva durante el periodo que cubre la auditoría. Un auditor que toma muestras del pasado marzo necesita la SBOM del pasado marzo.
4. Se revisa de nuevo cuando aparecen vulnerabilidades nuevas. Una lista que nadie compara con los avisos nuevos demuestra poco sobre la gestión de vulnerabilidades.

Para saber qué contiene una SBOM, consulte qué es una SBOM. Para los marcos de desarrollo seguro de productos industriales y de software federal estadounidense, consulte IEC 62443-4-1 y NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 es la norma con la que se certifica un sistema de gestión de la seguridad de la información (glosario). El anexo A enumera 93 controles; una organización selecciona los que exige su evaluación de riesgos y los registra en su declaración de aplicabilidad (Statement of Applicability). ISO/IEC 27002:2022 da la guía de implantación. Ninguna de las dos menciona las SBOM. La tabla solo cita los títulos de los controles, en su versión inglesa, y resume de qué trata cada uno.

Control	De qué trata	Cómo sirve de evidencia una SBOM o un registro de build	Lo que no cubre
5.9 "Inventory of information and other associated assets"	Saber qué activos tiene y quién es su propietario	El software que entrega y ejecuta es un activo. Una lista de componentes por versión es el inventario de lo que contiene.	Hardware, datos, personas y servicios
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Gestionar el riesgo que traen los proveedores y la cadena de suministro TIC	En dos sentidos. Como comprador, puede exigir SBOM a sus proveedores y vigilarlas. Como proveedor, su SBOM es lo que le pide el proceso de cadena de suministro de su cliente certificado. Los componentes de código abierto forman parte de la cadena de suministro TIC pero no vienen con ningún acuerdo con el proveedor, y precisamente por eso importa su inventario.	Contratos, evaluaciones y revisiones de proveedores
8.8 "Management of technical vulnerabilities"	Obtener información sobre vulnerabilidades, evaluar su exposición y actuar	Una lista de componentes actualizada, cruzada con los avisos de seguridad y reevaluada cuando aparecen otros nuevos, más un registro de qué versiones contenían una versión vulnerable y desde cuándo	Aplicar parches a su infraestructura, analizar hosts y las propias decisiones
8.25 "Secure development life cycle"	Reglas para desarrollar software y sistemas de forma segura	Un proceso de publicación registrado y repetible: cada versión compilada en el mismo pipeline, con su SBOM	La mayor parte del control: formación, entornos, diseño y revisión
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Requisitos, diseño y código	No directamente. Tratan de lo que usted escribe, no de lo que incorpora.	Todo: aquí la evidencia son la revisión de código, el SAST y los documentos de diseño
8.29 "Security testing in development and acceptance"	Probar la seguridad antes de publicar	Un control de política que bloquea un build ante un hallazgo de vulnerabilidad es una prueba registrada con resultado	Pruebas funcionales de seguridad, pruebas de penetración
8.30 "Outsourced development"	Dirigir y supervisar el desarrollo que externaliza	El código externalizado compilado en su pipeline recibe la misma SBOM y los mismos controles que el suyo	El contrato, las prácticas propias del proveedor

Sea honesto con 8.25 a 8.30: la mayor parte de lo que piden esos controles queda fuera de una SBOM. Atribuirle más es la forma más rápida de perder la confianza de un auditor en todo lo demás.

Ejemplo práctico: un auditor pregunta por el 8.8

«¿Cómo sabe cuándo una vulnerabilidad nueva afecta a un producto que ya ha entregado?» Esta es la cadena de evidencias para un aviso, y quién aporta cada eslabón.

Paso	Evidencia	Procede de
1. El contenido de la versión	La SBOM de la versión 4.2, registrada por el build que la produjo	Sus herramientas de build
2. La coincidencia con el aviso	Una CVE nueva publicada para una biblioteca de esa SBOM, cruzada por su package URL	Su vigilancia de vulnerabilidades
3. La ventana de exposición	Cada build que contenía la versión vulnerable, y la fecha del primero	Su historial de builds
4. La decisión	Quién la evaluó, cuándo y con qué resultado: corregir, mitigar o no afectado, con el motivo	Su proceso y sus registros
5. La corrección	La versión 4.2.1, cuya SBOM ya no contiene la versión vulnerable	Sus herramientas de build

Las herramientas pueden aportar los pasos 1, 2, 3 y 5. El paso 4 es su proceso, y es el que los auditores leen con más atención.

SOC 2

Un informe SOC 2 indica si los controles cumplen los Trust Services Criteria del AICPA (2017, con puntos de enfoque revisados en 2022). Los criterios describen resultados. No mencionan las SBOM, y dos de ellos son donde las SBOM ayudan.

• CC7.1 pide que la entidad utilice procedimientos de detección y supervisión para identificar (1) los cambios de configuración que introducen nuevas vulnerabilidades y (2) la exposición a vulnerabilidades recién descubiertas. Evidencia: una SBOM por versión, reevaluada frente a los avisos nuevos, y un registro de cómo se trató cada hallazgo.
• CC8.1 cubre la gestión de cambios: cómo se autorizan, desarrollan o adquieren, prueban, aprueban e implantan los cambios en la infraestructura, los datos, el software y los procedimientos. Evidencia: cada versión compilada en un pipeline registrado, el cambio en sus dependencias visible de un build al siguiente y controles de política como control de lo que se puede entregar.

Los criterios están en revisión. En octubre de 2026, el AICPA publicó un borrador (exposure draft) de los Trust Services Criteria de 2027, con una reestructuración selectiva de los criterios, comentarios hasta el 15 de enero de 2027 y una fecha de entrada en vigor propuesta para los encargos que comiencen el 31 de diciembre de 2027 o después. Es un borrador y los números de los criterios pueden cambiar: consulte el texto definitivo antes de asignar evidencias a los números nuevos.

Si ya usa una plataforma de SOC 2, consérvela. La cuestión es qué muestra la SBOM que hay detrás de sus controles: comparativa de controles de SBOM de SOC 2.

NIS2

La Directiva (UE) 2022/2555 (Directiva SRI 2) se aplica a las entidades esenciales e importantes de los sectores que enumera. Si lee esto como proveedor de software o de dispositivos, normalmente usted no está en su ámbito. Su cliente sí, y sus obligaciones le llegan en forma de preguntas. El artículo 21 fija las medidas para la gestión de riesgos de ciberseguridad, y tres pasajes generan la mayoría de esas preguntas:

• Artículo 21, apartado 2, letra d): «la seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos».
• Artículo 21, apartado 2, letra e): «la seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas de redes y de información, incluida la gestión y divulgación de las vulnerabilidades».
• Artículo 21, apartado 3: las entidades deben tener en cuenta «las vulnerabilidades específicas de cada proveedor y prestador de servicios directo y la calidad general de los productos y las prácticas en materia de ciberseguridad de sus proveedores y prestadores de servicios, incluidos sus procedimientos de desarrollo seguro». Es la frase que se convierte en un cuestionario sobre su mesa.

Reglamento de Ejecución (UE) 2024/2690

El Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024, establece los requisitos técnicos y metodológicos de las medidas del artículo 21, apartado 2, para los proveedores de servicios de DNS, los registros de nombres de dominio de primer nivel, los proveedores de servicios de computación en nube, los proveedores de servicios de centros de datos, los proveedores de redes de distribución de contenidos, los proveedores de servicios gestionados, los proveedores de servicios de seguridad gestionados, los mercados en línea, los motores de búsqueda en línea, las plataformas de servicios de redes sociales y los prestadores de servicios de confianza. No vincula a los demás sectores de NIS2, pero es la descripción pública más detallada de lo que significa «seguridad de la cadena de suministro», y otros compradores la toman como referencia. Los puntos que llegan a los proveedores:

Punto del anexo	Qué dice	Qué se pregunta al proveedor
5.1.2, letra a)	Los criterios de selección de proveedores incluyen «las prácticas de ciberseguridad de sus proveedores y prestadores de servicios, incluidos sus procedimientos de desarrollo seguro»	¿Cómo desarrolla de forma segura y cómo sabe qué entra en su producto?
5.1.4, letras e) y f)	Los contratos especifican, cuando proceda, el derecho de auditoría o a recibir informes de auditoría, y «la obligación de los proveedores y prestadores de servicios de hacerse cargo de las vulnerabilidades que presenten un riesgo» para la entidad	¿Gestionará las vulnerabilidades de lo que entrega y podemos ver la evidencia?
5.2	Un registro de proveedores directos, con «una lista de productos TIC, servicios TIC y procesos TIC» que proporciona cada uno	¿Qué productos y versiones nos suministra?
6.1.2, letra c)	Para la adquisición de servicios o productos TIC: «información que describa los componentes de hardware y software utilizados en los servicios y productos TIC»	¿Qué componentes de hardware y software contiene su producto? Es el texto de esta página que más se acerca a una SBOM, y aun así no la nombra.
6.10	Gestión de vulnerabilidades: supervisar la información sobre vulnerabilidades por canales como los anuncios de los CSIRT o «la información facilitada por los proveedores o prestadores de servicios» (6.10.2, letra a)) y, cuando una vulnerabilidad no requiera reparación, documentar y justificar «el motivo por el que la vulnerabilidad no requiere reparación» (6.10.3)	¿Cómo nos informará de las vulnerabilidades y por qué esta no es un problema?

El último punto describe una declaración de no afectado con su motivo. Eso es lo que contiene un documento VEX, aunque el reglamento no menciona ningún formato.

Ejemplo práctico: un cuestionario de un cliente sujeto a NIS2

Cinco preguntas del tipo que un cliente deriva de esos puntos, con la evidencia que puede adjuntar un proveedor. Algunas respuestas salen de registros que conservan sus herramientas; otras son políticas que usted redacta.

Pregunta	Evidencia que adjuntar	Registro o política
«Enumere los componentes de software de la versión del producto que nos entrega.» (6.1.2, letra c))	La SBOM de esa versión, en CycloneDX o SPDX, con su completitud indicada	Registro
«Describa su gestión de vulnerabilidades y sus plazos.» (5.1.4, letra f))	Su procedimiento de gestión de vulnerabilidades, con niveles de gravedad y plazos objetivo	Política
«¿Cuáles de las versiones que usamos contenían la biblioteca vulnerable, y desde cuándo?» (6.10)	El historial de builds, que muestra cada build que contenía el componente, con fechas	Registro
«¿Por qué esta CVE no nos afecta?» (6.10)	Una declaración de no afectado con su justificación, como «el código vulnerable no está presente»	Registro, basado en su evaluación
«¿Cómo pueden los investigadores notificar vulnerabilidades en sus productos?» (5.1.2, letra a))	Su política de divulgación coordinada de vulnerabilidades	Política

Una distinción que conviene mantener: para los productos con elementos digitales que se venden en la UE, el Cyber Resilience Act (Reglamento de Ciberresiliencia) sí exige una SBOM. NIS2 no.

DORA, si vende a entidades financieras

El Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital (DORA) se aplica a las entidades financieras, no directamente a sus proveedores. Las entidades financieras deben identificar y documentar sus activos de TIC y sus interdependencias y mantener inventarios de ellos (artículo 8, apartados 1, 4 y 6), gestionar el riesgo relacionado con terceros proveedores de TIC como parte de su riesgo relacionado con las TIC (artículo 28, apartado 1), mantener un registro de información sobre todos sus contratos de servicios de TIC (artículo 28, apartado 3) e incluir disposiciones mínimas en esos contratos (artículo 30). DORA no menciona las SBOM. Para un proveedor de software de un banco, una lista de componentes por versión ayuda al cliente a cumplir el artículo 8.

Un único mapa de evidencias para todos

Las filas son evidencias; cada celda indica el control, criterio o punto que respaldan, o «no directamente».

Evidencia	ISO/IEC 27001:2022	SOC 2	NIS2 y 2024/2690	DORA
1. Una SBOM por versión, con su completitud indicada	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (el inventario del cliente)
2. Reevaluación continua frente a avisos nuevos	8.8	CC7.1	Art. 21(2)(e); 6.10	No directamente
3. Historial de builds: qué versiones contenían un componente, y desde cuándo	8.8	CC7.1, CC8.1	6.10	No directamente
4. Registros de triaje y asignación	8.8	CC7.1	Art. 21(2)(e); 6.10	No directamente
5. Declaraciones de no afectado con su motivo	8.8	CC7.1	6.10	No directamente
6. Controles de política que bloquean un build	8.25, 8.29	CC8.1	Art. 21(2)(e)	No directamente
7. SBOM de proveedores vigiladas junto con las suyas	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Política de egress y registros de red del build	8.25	CC8.1	Art. 21(2)(d)	No directamente

Lo que una SBOM no demostrará

• Su control de acceso, respuesta a incidentes, continuidad de negocio, seguridad de recursos humanos, criptografía o seguridad física.
• Que alguien haya corregido algo. Eso es su proceso, y sus registros.
• Que su propio código esté libre de fallos. La evidencia de eso son la revisión de código, el SAST y las pruebas.
• Qué hay dentro de los binarios que recibió sin SBOM.
• Que usted está certificado. Una SBOM no es un certificado, y un certificado que tenga su proveedor de herramientas certifica el sistema de gestión de ese proveedor, no a usted.

Qué papel tiene CRACI

CRACI sustituye a sus runners alojados en GitHub y registra lo que descargó cada build, de modo que la SBOM procede del propio build de la versión, con un estado de completitud para cada job.

• Las SBOM vigiladas se reevalúan de forma continua a medida que se publican vulnerabilidades nuevas (seguimiento de vulnerabilidades).
• El historial de builds muestra qué builds contenían una dependencia vulnerable y, por tanto, el periodo en que estuvo expuesto, dentro de su periodo de retención. Si su auditoría cubre un periodo más largo, exporte la SBOM de cada versión y consérvela con la versión.
• Los equipos de seguridad clasifican las vulnerabilidades encontradas y las envían a los equipos responsables de la corrección, y CRACI admite VEX para registrar qué productos no se ven afectados por una vulnerabilidad.
• Los controles de política pueden bloquear un build ante hallazgos, incluido un build que contenga una CVE concreta.
• Se pueden añadir SBOM de terceros, de modo que los componentes comprados se vigilan junto con sus propios builds.
• Las SBOM se exportan en CycloneDX o SPDX, y la API devuelve SBOM, trazas de red y datos de procedencia. La política de egress registra y limita a dónde puede conectarse cada build.

CRACI aporta evidencia para estos controles. No le hace cumplir ISO 27001 ni SOC 2 ni le prepara para NIS2, y no es una plataforma de automatización del cumplimiento. El certificado propio de CRACI es un hecho aparte: el sistema de gestión de la seguridad de la información de CRACI Corporation Oy para el desarrollo y la operación de la plataforma CRACI está certificado según ISO/IEC 27001, emitido por Into Certification. Cubre cómo opera CRACI su servicio, no su organización ni sus productos. Consulte la seguridad en CRACI, y cómo funciona CRACI para la plataforma completa.

Cuándo CRACI no es la respuesta

• Sus builds no se ejecutan en GitHub Actions. Es la única CI que CRACI admite hoy; otros sistemas de CI están en la hoja de ruta.
• Necesita una plataforma de automatización del cumplimiento para políticas, revisiones de acceso y el flujo de trabajo con los auditores. Conserve una o adquiérala; consulte comparativa de controles de SBOM de SOC 2.
• Sus carencias de evidencia son sobre todo organizativas: políticas, formación, respuesta a incidentes.
• Su principal riesgo de proveedores son los binarios que recibe sin SBOM. Eso lo resuelve el análisis binario.

¿Responde a la solicitud de un cliente? Consulte cómo responder a una solicitud de SBOM de un cliente, la guía para proveedores de componentes y la lista de comprobación que aplicará su cliente.

Las SBOM como evidencia de cumplimiento: preguntas frecuentes

¿Exige ISO 27001 una SBOM?

No. ISO/IEC 27001:2022 no menciona las SBOM. Los controles 5.9 (inventario), 5.21 (cadena de suministro TIC) y 8.8 (vulnerabilidades técnicas) del anexo A piden resultados que una SBOM respalda, y la organización y su auditor deciden qué evidencia es suficiente.

¿Exige SOC 2 una SBOM?

No. Los Trust Services Criteria describen resultados y no mencionan las SBOM. Una SBOM por versión, reevaluada frente a los avisos nuevos, es evidencia para CC7.1, y un pipeline de build registrado respalda CC8.1 sobre la gestión de cambios.

¿Exige NIS2 una SBOM?

No. El artículo 21, apartado 2, letra d), pide seguridad de la cadena de suministro y la letra e), gestión de vulnerabilidades, sin mencionar las SBOM. El Reglamento de Ejecución (UE) 2024/2690, que cubre a determinados proveedores de servicios digitales, pide información sobre los componentes de hardware y software de los productos TIC en el punto 6.1.2, letra c), también sin la palabra SBOM.

¿Qué controles del anexo A de ISO 27001 respalda una SBOM?

Sobre todo 5.9 (inventario de la información y otros activos asociados), 5.19 a 5.22 (proveedores y cadena de suministro TIC) y 8.8 (gestión de vulnerabilidades técnicas). Un registro de build toca en parte 8.25, 8.29 y 8.30. Los controles 8.26 a 8.28 tratan de requisitos, diseño y código, fuera del alcance de una SBOM.

¿Qué piden los clientes sujetos a NIS2 a sus proveedores de software?

Normalmente una descripción del desarrollo seguro, los componentes de la versión entregada, el compromiso de gestionar vulnerabilidades, una vía para recibir información sobre vulnerabilidades y los motivos cuando una vulnerabilidad no aplica. Esas preguntas proceden del artículo 21, apartado 3, y, en algunos sectores, de los puntos sobre proveedores del Reglamento de Ejecución 2024/2690.

¿Basta una SBOM como evidencia para el control 8.8 de ISO 27001?

No. Muestra qué contiene cada versión. El control 8.8 también necesita evidencia de que obtiene información sobre vulnerabilidades, evalúa su exposición y actúa. Combine la SBOM con una reevaluación continua, un registro de las versiones afectadas y las decisiones que tomó.

¿Qué diferencia hay entre cumplir y tener evidencia?

Cumplir significa que sus procesos satisfacen los requisitos del marco, según el juicio de un auditor o de un cliente. La evidencia es lo que demuestra que esos procesos funcionan. Una SBOM es evidencia para algunos controles. No le hace cumplir ningún marco.