Cómo generar un SBOM conforme al CRA: herramientas, formatos e integración CI/CD

El CRA requiere una Lista de Materiales 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 requiere 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, datos estructurados
• Al menos dependencias de nivel superior: El alcance mínimo, aunque más es mejor
• No se requiere que sea público: Proporcionado 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.

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, enfocado en seguridad Versión actual: 1.6 (1.4+ recomendado para CRA) Mejor para: Seguridad y gestión de vulnerabilidades

Fortalezas:

• 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

SPDX

Origen: Linux Foundation, enfocado en cumplimiento de licencias Versión actual: 2.3 (estándar ISO/IEC 5962:2021) Mejor para: Cumplimiento de licencias y revisión legal

Fortalezas:

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

¿Cuál elegir?

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

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 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
syft /ruta/al/archivo.tar.gz -o spdx-json > sbom.spdx.json

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

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

Integración CI/CD

La generación manual de SBOM no escala. Intégralo en tu pipeline de construcción.

GitHub Actions

name: Generación de SBOM

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout código
        uses: actions/checkout@v4

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

      - name: Generar SBOM
        run: |
          syft dir:. -o cyclonedx-json > sbom.cdx.json

      - name: Subir SBOM como artefacto
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json
          retention-days: 90

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

Calidad del SBOM: cumpliendo TR-03183

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

Campos requeridos

Manteniendo los SBOMs actualizados

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

Cuándo regenerar:

• Cada lanzamiento (mayor, menor, parche)
• Después de actualizaciones de dependencias
• Después de parches de seguridad
• Cuando cambia la configuración de construcción

Retención: El CRA requiere retención de 10 años. Almacena SBOMs históricos:

• En tu repositorio de artefactos
• En S3/almacenamiento en la nube con políticas de ciclo de vida
• En CRA Evidence para seguimiento de cumplimiento integrado

Lista de verificación de implementación de SBOM

LISTA DE VERIFICACIÓN DE IMPLEMENTACIÓN DE SBOM

SELECCIÓN DE FORMATO:
[ ] CycloneDX 1.4+ o SPDX 2.3+ elegido
[ ] Formato JSON (legible por máquina)
[ ] Decisión documentada

HERRAMIENTAS:
[ ] Herramienta principal seleccionada (Syft/Trivy/cdxgen)
[ ] Herramienta instalada y probada localmente
[ ] Salida validada contra esquema

INTEGRACIÓN CI/CD:
[ ] Generación de SBOM añadida al pipeline de construcción
[ ] Artefactos almacenados con retención apropiada
[ ] Generación activada en lanzamientos

ASEGURAMIENTO DE CALIDAD:
[ ] Todos los componentes tienen: nombre, versión, proveedor
[ ] Valores hash presentes (SHA-256+)
[ ] Información de licencia incluida
[ ] Dependencias transitivas capturadas
[ ] Identificadores PURL usados

OPERACIONES:
[ ] SBOM versionado junto con lanzamientos de producto
[ ] SBOMs históricos archivados (retención de 10 años)
[ ] Proceso documentado para el equipo

Próximos pasos

Con la generación de SBOM automatizada, estás listo para:

1. Escaneo de vulnerabilidades: Conectar SBOMs a bases de datos de vulnerabilidades
2. Cumplimiento de licencias: Analizar obligaciones de licencia
3. Integración del expediente técnico: Incluir SBOMs en documentación CRA
4. Preparación para notificación a ENISA: Los SBOMs permiten identificación rápida de vulnerabilidades

CRA Evidence automatiza todo este flujo de trabajo:

• Subir SBOMs vía CLI o CI/CD
• Escaneo automático de vulnerabilidades con Trivy
• Puntuación de calidad TR-03183
• Exportación de expediente técnico con SBOMs integrados

Comienza a generar SBOMs conformes en craevidence.com.

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: Agrega 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.