El SBOM —software bill of materials, el inventario de todo lo que compone una aplicación— deja de ser una práctica de equipos de ciberseguridad grandes y pasa a ser una exigencia legal para quien construye o encarga software en la Unión Europea. La Cyber Resilience Act fija el calendario, y para quien contrata desarrollo a medida en Barcelona la pregunta no es si le afecta, sino cuándo y con qué matices. Esto es lo que cambia, a quién obliga de verdad y qué debe exigir tu empresa al proveedor que le escribe el código.
Un SBOM es obligatorio para todo producto con elementos digitales que se coloque en el mercado de la UE desde el 11 de diciembre de 2027. Si tu desarrollo es exclusivamente a medida para un único cliente y no se reutiliza en otro proyecto, la Cyber Resilience Act no te lo exige — pero en cuanto ese mismo código llega a un segundo cliente, sí te lo exige.
Qué es un SBOM y qué datos reúne
Un SBOM —en español, lista de materiales de software— es el inventario técnico de todo lo que entra en una aplicación: cada librería, cada versión, cada dependencia de terceros y cada pieza de código abierto que el proveedor no ha escrito él mismo. No es un documento comercial ni un listado de funcionalidades: es la ficha técnica que permite saber, el día que aparece una vulnerabilidad en una librería concreta, qué productos la usan y con qué urgencia hay que actualizarlos.
Para ser útil de verdad, un SBOM reúne como mínimo:
- Nombre del componente y versión exacta instalada.
- Proveedor o mantenedor de esa pieza de código.
- Relación de dependencias: qué librería depende de cuál.
- Licencia bajo la que se distribuye.
- Vulnerabilidades conocidas asociadas a esa versión en el momento de generarlo.
Sin ese nivel de detalle, un aviso de seguridad obliga a revisar producto por producto a mano; con él, basta con buscar la versión afectada en el inventario.
La Cyber Resilience Act marca dos plazos distintos
La Cyber Resilience Act, el reglamento europeo que obliga a todo esto, no entra en vigor de golpe: reparte sus exigencias en varias fechas, y confundirlas hace que una empresa se crea a salvo cuando ya está dentro de una obligación activa.
Un producto con elementos digitales es, según la Cyber Resilience Act, cualquier software o hardware que se conecta a otro dispositivo o a una red, directa o indirectamente. Entran una tienda online con pasarela de pago, una app de gestión de turnos y un ERP a medida; no entra el software desarrollado solo para uso interno de quien lo programa.
El reglamento entró en vigor el 10 de diciembre de 2024, pero sus obligaciones se activan por fases, tal y como explica la Comisión Europea. Desde el 11 de septiembre de 2026 ya corre la obligación de notificar vulnerabilidades explotadas activamente y, en España, el canal pasa por INCIBE-CERT como CSIRT nacional. El grueso del reglamento, con el SBOM incluido, se aplica desde el 11 de diciembre de 2027: esa es la fecha que de verdad importa para quien encarga o vende software.
Cuándo tu software a medida queda fuera del SBOM
Aquí está el matiz que más confunde a quien contrata un desarrollo propio: la obligación nace de colocar un producto en el mercado, y un encargo exclusivo de desarrollo a medida para un único cliente no siempre cuenta como tal.
Qué pasa si el mismo desarrollo llega a un segundo cliente
Mientras ese ERP, esa tienda online o esa app de reservas se queden dentro de un único contrato, con un cliente que la usa para su propio negocio, la Cyber Resilience Act la trata como desarrollo exclusivo y no exige SBOM. El punto de inflexión llega el día en que la agencia reutiliza esa misma base de código para un segundo cliente o la convierte en producto propio: ahí pasa a ser un producto colocado en el mercado, con todas las obligaciones que eso implica. Suele ocurrir sin que nadie lo decida: un desarrollador reaprovecha un módulo que funcionó bien y, sin darse cuenta, extiende el reglamento a otra empresa.
Qué debe quedar por escrito si el encargo es exclusivo
Si el acuerdo con la agencia es realmente un encargo exclusivo, conviene dejarlo escrito y no asumirlo por sentado. El contrato debe recoger que el desarrollo se entrega en exclusiva para ese cliente y que no se reutilizará como base de otro proyecto sin acuerdo expreso. La Cyber Resilience Act da flexibilidad contractual a los encargos verdaderamente a medida —incluso para pactar condiciones distintas en las actualizaciones de seguridad—, pero solo si ese carácter exclusivo queda documentado en la documentación técnica del proyecto, no solo en el correo donde se acordó el precio.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
El inventario de dependencias que debe entregar tu proveedor
Si tu empresa encarga el desarrollo fuera, el SBOM no lo escribes tú: lo entrega quien programa. Pero conviene pedirlo por contrato antes de firmar, no después de un incidente, porque es entonces cuando se nota si el proveedor lo tiene de verdad o lo promete sobre la marcha.
- Formato machine-readable del inventario: SPDX, CycloneDX o SWID, no un PDF ni un Excel.
- Compromiso de actualizarlo con cada versión que se publique, no solo en la entrega inicial.
- Un canal de aviso si aparece una vulnerabilidad en alguna dependencia que use tu proyecto.
- Quién lo conserva y durante cuánto tiempo, porque la autoridad puede pedirlo años después del encargo.
Un proveedor serio no debería tener problema en comprometerse a esto por escrito: quien ya automatiza su propio desarrollo lo genera como parte del pipeline, no como un trámite aparte.
CycloneDX y SPDX, los formatos que ya se usan
CycloneDX, impulsado por OWASP, y SPDX, de Linux Foundation, son los dos formatos que de verdad se usan hoy para generar un SBOM. Ambos son machine-readable, ambos los acepta la Cyber Resilience Act y ambos tienen herramientas gratuitas que los generan automáticamente a partir del gestor de paquetes del proyecto.
La diferencia práctica está en el ecosistema: CycloneDX nació pensando en seguridad y es el más extendido entre herramientas de análisis de dependencias; SPDX viene del mundo de las licencias de software y lo usan sobre todo quienes necesitan auditar también qué licencias arrastra cada componente. Para una pyme que encarga su primer SBOM a una agencia, lo relevante no es cuál de los dos exige, sino que el proveedor lo integre en su pipeline de CI/CD: generarlo a mano en cada versión es exactamente el tipo de tarea que se olvida la primera vez que hay prisa por publicar.
Preguntas frecuentes sobre el SBOM
Antes de cerrar el tema con tu proveedor o con tu equipo técnico, estas son las dudas que más se repiten sobre el SBOM.
¿Qué pasa si no entrego el SBOM cuando lo pide la autoridad?
La autoridad de vigilancia del mercado puede exigir la retirada del producto y sancionar al fabricante: hasta 15 millones de euros o el 2,5% de la facturación mundial anual, lo que sea mayor, en las infracciones más graves. No hace falta que haya habido un incidente: basta con no poder demostrar el inventario cuando se pide.
¿El SBOM hay que publicarlo en mi web?
No. La Cyber Resilience Act no exige hacerlo público: debe formar parte de la documentación técnica del producto y entregarse a la autoridad de vigilancia del mercado cuando lo solicite, no colgarlo en abierto para cualquier visitante.
¿Las pymes están exentas de la Cyber Resilience Act?
No por tamaño. La única excepción real es que las microempresas y pequeñas empresas no pueden ser sancionadas por incumplir el plazo de aviso temprano de 24 horas, pero sí deben cumplir la notificación a las 72 horas y el resto de obligaciones del reglamento.
¿Qué formato de SBOM debo exigir a mi proveedor?
CycloneDX o SPDX, los dos machine-readable que acepta la Cyber Resilience Act. Rechaza un listado en PDF o en una hoja de cálculo: no lo pueden cruzar automáticamente ni tu proveedor ni la autoridad que lo revise.
Fuente: INCIBE-CERT
