Generar un SBOM para el CRA: herramientas, formatos, CI/CD

El CRA requiere una lista de componentes de software. Todos los artículos de la competencia te dicen esto. Ninguno te muestra cómo generar uno.

Esta guía cubre herramientas de código abierto, selección de formatos e integración CI/CD, sin dependencia de proveedores.

Lo que el CRA realmente requiere

Empecemos con lo que dice el Reglamento. El Anexo I, Parte II del CRA exige que los fabricantes:

«identificarán y documentarán las vulnerabilidades y los componentes presentes en el producto con elementos digitales, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos en un formato comúnmente utilizado y legible por máquina, que incluya, como mínimo, las dependencias de máximo nivel del producto»

Puntos clave:

• Formato legible por máquina: no un PDF, no una hoja de cálculo, sino datos estructurados
• Al menos dependencias de nivel superior: el alcance mínimo, aunque más es mejor
• No se requiere que sea público: se proporciona a las autoridades bajo petición
• Debe actualizarse: con cada lanzamiento, parche o cambio de componente

El CRA no exige un formato específico, pero los esfuerzos de estandarización apuntan claramente a CycloneDX y SPDX.

El SBOM forma parte de la documentación técnica del CRA bajo el Anexo VII. Los fabricantes deben elaborar esa documentación antes de introducir un producto en el mercado y mantenerla a disposición de las autoridades de vigilancia del mercado durante al menos 10 años, o durante el período de soporte, el plazo que sea mayor (Art. 13(13)). Un SBOM almacenado localmente sin vínculo con una versión específica del producto no satisface este requisito. Debe ser recuperable, versionado y vinculado a la versión del producto que describe.

Selección de formato: CycloneDX vs SPDX

Dos formatos dominan el panorama de SBOM. Ambos son aceptables para el cumplimiento del CRA.

CycloneDX

Origen: proyecto OWASP, orientado a la seguridad Versión actual: 1.6 (1.4+ recomendado para CRA) Mejor para: seguridad y gestión de vulnerabilidades

Puntos fuertes:

• Soporte nativo de VEX (Vulnerability Exploitability eXchange)
• Diseñado para casos de uso de seguridad
• Especificación más ligera, más fácil de implementar
• Ecosistema de herramientas sólido
• Vinculación directa con CVE/vulnerabilidades

Ejemplo JSON:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "cc6d..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ]
}

SPDX

Origen: Linux Foundation, orientado al cumplimiento de licencias Versión actual: 2.3; ISO/IEC 5962:2021 estandarizó SPDX 2.2.1 Mejor para: cumplimiento de licencias y revisión legal

Puntos fuertes:

• Estándar internacional ISO
• Sintaxis completa de expresión de licencias
• Sólido en contextos de cumplimiento de código abierto
• Mayor trayectoria
• Mejor para escenarios de licencias complejas

Ejemplo JSON:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "cc6d..."
        }
      ]
    }
  ]
}

¿Cuál elegir?

Para el cumplimiento del CRA, cualquier formato funciona. Elige uno y sé coherente.

Herramientas de generación de SBOM de código abierto

Sin dependencia de proveedores requerida. Estas herramientas son gratuitas, de código abierto y listas para producción.

Syft (Anchore)

Mejor para: imágenes de contenedores, sistemas de archivos, archivos comprimidos Licencia: Apache 2.0 Formatos de salida: CycloneDX, SPDX, Syft JSON

Instalación:

# Linux/macOS
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Homebrew
brew install syft

# Docker
docker pull anchore/syft

Ejemplos de uso:

# Escanear una imagen de contenedor
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

# Escanear un directorio
syft dir:/ruta/al/proyecto -o cyclonedx-json > sbom.cdx.json

# Escanear un archivo comprimido
syft /ruta/al/archivo.tar.gz -o spdx-json > sbom.spdx.json

# Escanear con catalogadores específicos (p. ej., solo Python)
syft dir:. -o cyclonedx-json --select-catalogers python

Ecosistemas soportados: Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET y más.

Trivy (Aqua Security)

Mejor para: imágenes de contenedores con contexto de vulnerabilidades integrado Licencia: Apache 2.0 Formatos de salida: CycloneDX, SPDX, más informes de vulnerabilidades

Instalación:

# Linux (Debian/Ubuntu)
sudo apt-get install trivy

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Ejemplos de uso:

# Generar SBOM desde imagen de contenedor
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# Generar SBOM desde sistema de archivos
trivy fs --format cyclonedx --output sbom.cdx.json /ruta/al/proyecto

# Generar SBOM con información de vulnerabilidades
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Ventaja: Trivy puede generar SBOMs y escanear vulnerabilidades en un solo paso.

cdxgen (CycloneDX)

Mejor para: análisis de código fuente en muchos lenguajes Licencia: Apache 2.0 Formato de salida: CycloneDX

Instalación:

# npm (requiere Node.js)
npm install -g @cyclonedx/cdxgen

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Ejemplos de uso:

# Escanear directorio actual
cdxgen -o sbom.json

# Escanear tipo de proyecto específico
cdxgen -t python -o sbom.json

# Escanear con resolución profunda de dependencias
cdxgen --deep -o sbom.json

# Escanear un directorio concreto
cdxgen -o sbom.json /ruta/al/proyecto

Lenguajes soportados: JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++ y más.

Comparativa de herramientas

Recomendación: empieza con Syft para la mayoría de los casos. Añade Trivy si necesitas escaneo de vulnerabilidades integrado. Usa cdxgen para proyectos de código fuente complejos.

Firmware y dispositivos embebidos

Las herramientas anteriores funcionan bien para contenedores y gestores de paquetes. Para firmware y dispositivos embebidos (el objetivo principal del CRA), el enfoque es distinto.

Las imágenes de firmware son blobs binarios, no registros de paquetes. El primer paso habitual es extraer el sistema de archivos:

# Extraer el sistema de archivos desde una imagen de firmware
binwalk -Me firmware.bin

# Ejecutar Syft sobre el sistema de archivos extraído
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Usa binwalk -Me (extracción recursiva) en lugar de -e para imágenes anidadas o comprimidas. La cobertura será menor que para imágenes de contenedor. Los binarios compilados sin símbolos pierden información, y Syft puede no identificar todos los componentes.

Para el análisis a nivel binario de componentes compilados, BLint, cve-bin-tool o EMBA ofrecen una inspección más profunda. Los SDK propietarios y las bibliotecas de código cerrado integradas en el firmware suelen requerir entradas manuales en el SBOM. Documenta el proveedor, la versión y la URL de origen.

Integración CI/CD

La generación manual de SBOM no escala. Intégrala en tu pipeline de compilación.

GitHub Actions

name: Generación de SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # necesario para la firma sin clave con Cosign
    steps:
      - name: Checkout código
        uses: actions/checkout@v4

      - name: Compilar imagen de contenedor
        run: |
          docker build -t myapp:${{ github.sha }} .

      - name: Instalar Syft
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Generar SBOM desde imagen compilada
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

      - name: Instalar Cosign
        uses: sigstore/cosign-installer@v3

      - name: Firmar SBOM (sin clave)
        run: |
          cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json --yes

      - name: Subir SBOM y firma como artefactos
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Opcional: subir a CRA Evidence para almacenamiento de cumplimiento a largo plazo
      - name: Subir a CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://api.craevidence.com/api/v1/ci/sbom \
            -H "Authorization: Bearer $CRA_EVIDENCE_TOKEN" \
            -F "file=@sbom.cdx.json" \
            -F "product_id=${{ vars.PRODUCT_ID }}" \
            -F "version=${{ github.ref_name }}"

GitLab CI

generate-sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.cdx.json
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 90 days
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_COMMIT_TAG

Jenkins

pipeline {
    agent any

    stages {
        stage('Generar SBOM') {
            steps {
                sh '''
                    curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b .
                    ./syft dir:. -o cyclonedx-json > sbom.cdx.json
                '''
            }
        }

        stage('Archivar SBOM') {
            steps {
                archiveArtifacts artifacts: 'sbom.cdx.json', fingerprint: true
            }
        }
    }
}

Integración en el proceso de Docker

Genera el SBOM durante la compilación de Docker:

# Compilación multietapa con generación de SBOM
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Generar SBOM en la etapa de compilación
FROM anchore/syft:latest AS sbom
COPY --from=builder /app /app
RUN syft dir:/app -o cyclonedx-json > /sbom.cdx.json

# Imagen final
FROM node:20-slim
COPY --from=builder /app/dist /app
COPY --from=sbom /sbom.cdx.json /app/sbom.cdx.json
CMD ["node", "/app/index.js"]

Firma del SBOM

El CRA no exige la firma del SBOM, pero la firma certifica que el SBOM no ha sido modificado desde su generación. Los equipos de aprovisionamiento empresarial y los organismos notificados esperan cada vez más una firma verificable junto al archivo SBOM.

Cosign (parte del proyecto Sigstore) es la herramienta estándar:

# Instalar Cosign
brew install cosign

# Firmar un archivo SBOM. Produce un bundle con la firma y el certificado
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Verificar más tarde
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <tu-identidad> \
  --certificate-oidc-issuer <tu-emisor>

Guarda sbom.cdx.json y sbom.cdx.json.sigstore.json juntos. El bundle contiene la firma, el certificado de firma y la entrada en el registro de transparencia Rekor. Cualquier persona con el bundle puede verificar el SBOM sin necesidad de contactarte.

Para CI/CD, Cosign soporta firma sin clave mediante la identidad OIDC del pipeline (GitHub Actions, GitLab CI). Sin claves que gestionar. El ejemplo de GitHub Actions anterior ya incluye esto: el job necesita el permiso id-token: write, y sign-blob admite --yes para ejecutarse sin interacción. Cosign 2.0 y posteriores hacen que la firma sin clave sea el comportamiento por defecto, así que el indicador COSIGN_EXPERIMENTAL ya no es necesario.

Monitorización continua

Un SBOM firmado y almacenado no es la meta final. Se detectan nuevas vulnerabilidades contra componentes que estaban limpios en el momento del lanzamiento. El SBOM almacenado debe reescanearse de forma periódica para que esas CVE salgan a la superficie.

Grype lee un SBOM existente directamente, por lo que el reescaneo no necesita el entorno de compilación original:

name: Reescaneo de SBOM

on:
  schedule:
    - cron: "0 6 * * 1"  # Semanal, lunes 06:00 UTC

jobs:
  rescan:
    runs-on: ubuntu-latest
    steps:
      - name: Obtener el SBOM almacenado
        env:
          SBOM_URL: ${{ vars.SBOM_URL }}
        run: |
          curl -sSfL -o sbom.cdx.json "$SBOM_URL"

      - name: Instalar Grype
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Escanear el SBOM en busca de nuevas CVE
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence ejecuta este reescaneo automáticamente para cada SBOM subido y te avisa cuando una nueva CVE coincide con un componente, lo que cubre la misma necesidad sin un job programado.

Calidad del SBOM: cumplir TR-03183

La guía técnica alemana BSI TR-03183 extiende los elementos mínimos de NTIA. Aunque no es legalmente exigible en toda la UE, seguir TR-03183 garantiza SBOMs de alta calidad.

Campos requeridos

Validar la calidad del SBOM

Usa estas herramientas para comprobar tu SBOM:

# Validar formato CycloneDX
npm install -g @cyclonedx/cyclonedx-cli
cyclonedx validate --input-file sbom.cdx.json

# Comprobar campos mínimos con jq
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Contar componentes con hashes
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

Mejorar la calidad del SBOM

Si tu SBOM carece de datos:

1. Usa archivos de bloqueo: package-lock.json, Pipfile.lock, go.sum contienen más metadatos
2. Escanea artefactos compilados: más completo que los escaneos solo del código fuente
3. Combina herramientas: distintas herramientas encuentran distintos componentes
4. Añade entradas manuales: para componentes comerciales o internos

Mantener los SBOMs actualizados

Un SBOM es una instantánea. Debe actualizarse para seguir siendo útil.

Cuándo regenerar

• En cada lanzamiento (mayor, menor, parche)
• Tras actualizaciones de dependencias
• Tras parches de seguridad
• Cuando cambia la configuración de compilación

Estrategia de versioning

producto-v1.0.0-sbom.cdx.json
producto-v1.0.1-sbom.cdx.json
producto-v1.1.0-sbom.cdx.json

O usando marcas de tiempo:

producto-sbom-2026-01-15T10-30-00Z.cdx.json

Retención

La retención del artefacto de CI (90 días en los ejemplos anteriores) es para comodidad del desarrollador, no para cumplimiento. El requisito de 10 años necesita un almacén dedicado de largo plazo. CRA Evidence está diseñado específicamente para ello: almacenamiento versionado de SBOMs con reescaneo de vulnerabilidades y exportación de archivos técnicos, vinculado a cada lanzamiento del producto.

Si prefieres alojarlo tú mismo, cualquier almacén de objetos principal funciona una vez que activas los controles adecuados:

Una política de ciclo de vida sola no basta. El almacén también debe soportar control de versiones, controles de acceso e idealmente inmutabilidad para satisfacer los requisitos de auditoría.

Errores comunes

Generación puntual del SBOM

Problema: crear un SBOM una sola vez y no actualizarlo.

Solución: automatiza la generación de SBOM en CI/CD. Cada compilación debe producir un SBOM nuevo.

Dependencias transitivas ausentes

Problema: el SBOM solo lista las dependencias directas, sin los paquetes anidados.

Solución: usa archivos de bloqueo, escanea artefactos compilados, activa las opciones de escaneo profundo.

Versión de formato incorrecta

Problema: usar CycloneDX 1.3 cuando TR-03183 recomienda 1.4+.

Solución: comprueba la versión de salida de tu herramienta. Actualiza las herramientas con regularidad.

Sin valores hash

Problema: los componentes sin hashes criptográficos no se pueden verificar.

Solución: asegúrate de que tu herramienta incluye hashes. Syft y Trivy añaden hashes SHA-256 cuando pueden leer los archivos del componente.

Creación manual

Problema: crear SBOMs a mano es propenso a errores e insostenible.

Solución: automatiza siempre. Las entradas manuales solo para componentes que las herramientas no detectan.

Ignorar los componentes internos

Problema: documentar solo las dependencias de código abierto, no el código propietario.

Solución: los componentes internos también necesitan documentación. Añádelos manualmente o configura las herramientas adecuadamente.

Lista de verificación de implementación de SBOM

Requisitos: comprende lo que el CRA requiere para SBOMs en nuestra guía de requisitos SBOM.

Calidad: valida tu SBOM contra el estándar BSI TR-03183.

VEX: añade contexto de vulnerabilidades a tu SBOM con documentos VEX.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica sobre cumplimiento, consulta con asesores legales cualificados familiarizados con las regulaciones de productos de la UE.