Si el Cyber Resilience Act tuviera una palabra clave técnica, sería SBOM. Detrás de esas siglas hay un concepto simple pero transformador: no puedes proteger lo que no sabes que tienes. El Anexo I del CRA convierte el inventario de componentes de software en una obligación, y entender qué es y cómo se genera es el primer paso práctico hacia la conformidad.
Qué es un SBOM
Un SBOM (Software Bill of Materials, o lista de materiales de software) es el inventario formal de todos los componentes que forman un producto: bibliotecas, dependencias, paquetes, versiones y, cuando es posible, sus relaciones y licencias. La analogía habitual es la etiqueta de ingredientes de un alimento: igual que sabes qué contiene lo que comes, un SBOM te dice exactamente de qué está hecho tu software.
Esto, que parece obvio, casi nunca existía de forma rigurosa. El software moderno se construye sobre cientos de dependencias de terceros, muchas de ellas transitivas (dependencias de tus dependencias). Sin un inventario, cuando aparece una vulnerabilidad crítica en una biblioteca muy usada, la pregunta "¿me afecta?" puede tardar días en responderse. Con un SBOM, es una consulta.
Los formatos: CycloneDX y SPDX
Para que un SBOM sea útil tiene que ser legible por máquinas, no un documento suelto. Existen dos formatos estándar dominantes:
- CycloneDX (proyecto de OWASP): orientado a seguridad y gestión de vulnerabilidades, muy extendido en el mundo de las aplicaciones y los contenedores.
- SPDX (Linux Foundation, norma ISO/IEC 5962): con fuerte tradición en el cumplimiento de licencias, además de la seguridad.
Ambos permiten describir componentes, versiones e identificadores (como los PURL o los CPE) que luego se cruzan con las bases de vulnerabilidades. Una herramienta de conformidad debe aceptar los dos y normalizarlos a un modelo común.
Por qué el CRA lo hace obligatorio
El SBOM aparece de forma explícita en el Anexo I, Parte II del CRA, dedicado a la gestión de vulnerabilidades. El fabricante debe identificar y documentar los componentes del producto, incluido mediante una lista de materiales de software en un formato legible por máquina, y mantenerla. La razón es directa: sin inventario no hay gestión de vulnerabilidades posible, y sin gestión de vulnerabilidades no hay conformidad. El SBOM es la base sobre la que se apoyan casi todas las demás obligaciones técnicas del reglamento.
Cómo se genera un SBOM
Un SBOM se puede obtener de varias fuentes, según el tipo de producto:
- Manifiestos y lockfiles del código fuente (package-lock.json, requirements.txt, go.sum, cargo.lock, pom.xml…): la vía más limpia, porque describen versiones exactas.
- Imágenes de contenedor: herramientas como Syft o Trivy extraen el inventario de una imagen Docker/OCI.
- Firmware y binarios: el caso más difícil. Requiere desempaquetar el firmware y detectar componentes (bibliotecas, versiones) dentro de binarios, sistemas de ficheros embebidos incluidos.
- Declaración manual: cuando no hay artefacto analizable, el fabricante declara los componentes conocidos.
Lo ideal es que el SBOM se genere de forma automática y reproducible en cada versión del producto, y que quede sellado (por ejemplo, con el hash de la imagen y las versiones de las herramientas usadas) para que sirva como evidencia auditable durante los años de retención que exige el CRA.
Del SBOM a la gestión de vulnerabilidades
El SBOM no es un fin en sí mismo: es el punto de partida. Una vez tienes el inventario, cada componente y versión se cruza contra bases como OSV (Open Source Vulnerabilities), la NVD, la lista CISA KEV de vulnerabilidades explotadas y la europea EUVD de ENISA. Con eso sabes no solo qué vulnerabilidades te afectan, sino cuáles son explotables o ya explotadas —la señal que, bajo el CRA, puede arrancar el reloj de notificación del Artículo 14—. La probabilidad de explotación se puede estimar además con métricas como EPSS. Ese cruce continuo es la esencia de la Parte II del Anexo I.
Errores comunes
- SBOM de una sola vez: generarlo al lanzar y no volver a actualizarlo. Debe regenerarse en cada versión.
- Ignorar las dependencias transitivas: son la mayoría del código y donde más se esconden las vulnerabilidades.
- Confundir tener el SBOM con estar conforme: el inventario es el principio del trabajo, no el final.
En CRAtrustNorth, el SBOM es el módulo M1 y alimenta todo lo demás: se ingiere desde CycloneDX, SPDX, manifiesto, contenedor, repositorio o firmware, se normaliza y se cruza automáticamente contra OSV, KEV, EPSS y EUVD. Porque un buen SBOM no es papeleo: es la diferencia entre responder "¿me afecta esta vulnerabilidad?" en segundos o en días.
El caso difícil: SBOM de firmware
Generar un SBOM desde código fuente es relativamente sencillo; hacerlo desde un firmware ya compilado es otra historia, y es justo donde están muchos de los productos que el CRA quiere cubrir (cámaras, routers, equipos industriales). Requiere desempaquetar la imagen —a menudo con sistemas de ficheros embebidos y anidados—, identificar bibliotecas y versiones dentro de binarios, y deduplicar. El resultado casi nunca es perfecto: aparecen componentes con versión "desconocida" y falsos positivos que hay que revisar. Por eso, para firmware, el SBOM se trata como una evidencia con nivel de confianza, no como una verdad absoluta, y se complementa con la declaración del fabricante sobre los componentes que sí conoce con certeza. Reconocer esa limitación con honestidad es parte de hacerlo bien: un SBOM de firmware útil dice tanto lo que sabe como lo que no.