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 articulos de la competencia te dicen esto. Ninguno te muestra Cómo generar uno.

Esta Guía cubre herramientas de codigo abierto, seleccion de formatos e Integración CI/CD, sin dependencia de proveedores.

Lo Qué el CRA Realmente Requiere

Empecemos con lo Qué dice el reglamento. El Anexo I, Parte II del CRA requiere Qué los fabricantes:

"identifiquen y documenten las vulnerabilidades y componentes contenidos en el producto, incluyendo la elaboracion de una lista de materiales de software en un formato de uso comun y legible por maquina"

Puntos clave:

• Formato legible por maquina: No un PDF, no una hoja de calculo, datos estructurados
• Al menos dependencias de nivel superior: El alcance mínimo, aunque mas es mejor
• No se requiere Qué sea publico: Proporcionado a las autoridades bajo peticion
• Debe actualizarse: Con cada lanzamiento, parche o cambio de componente

El CRA no exige un formato especifico, pero los esfuerzos de estandarizacion apuntan claramente a CycloneDX y SPDX.

Seleccion 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 Version actual: 1.6 (1.4+ recomendado para CRA) Mejor para: Seguridad y gestion de vulnerabilidades

Fortalezas:

• Soporte nativo de VEX (Vulnerability Exploitability eXchange)
• Disenado para casos de uso de seguridad
• Especificacion mas ligera, mas facil de implementar
• Ecosistema de herramientas solido
• Vinculacion directa con CVE/vulnerabilidades

SPDX

Origen: Linux Foundation, enfocado en cumplimiento de licencias Version actual: 2.3 (estandar ISO/IEC 5962:2021) Mejor para: Cumplimiento de licencias y revision legal

Fortalezas:

• Estandar internacional ISO
• Sintaxis completa de expresion de licencias
• Fuerte en contextos de cumplimiento de codigo abierto
• Mayor trayectoria
• Mejor para escenarios de licencias complejas

¿Cual Elegir?

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

Herramientas de Generacion de SBOM de Codigo Abierto

Sin dependencia de proveedores requerida. Estas herramientas son gratuitas, de codigo abierto y listas para produccion.

Syft (Anchore)

Mejor para: Imagenes de contenedores, sistemas de archivos, archivos Licencia: Apache 2.0 Formatos de salida: CycloneDX, SPDX, Syft JSON

Instalacion:

# 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: Imagenes de contenedores con contexto de vulnerabilidades integrado Licencia: Apache 2.0 Formatos de salida: CycloneDX, SPDX, mas informes de vulnerabilidades

Instalacion:

# 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: Analisis de codigo fuente en muchos lenguajes Licencia: Apache 2.0 Formato de salida: CycloneDX

Instalacion:

# 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 especifico
cdxgen -t python -o sbom.json

Integración CI/CD

La generacion manual de SBOM no escala. Integralo en tu pipeline de construccion.

GitHub Actions

name: Generacion de SBOM

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout codigo
        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 Cómo 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 Tecnica alemana BSI TR-03183 extiende los elementos minimos de NTIA. Aunque no es legalmente requerido en toda la UE, seguir TR-03183 asegura SBOMs de alta calidad.

Campos Requeridos

Manteniendo los SBOMs Actualizados

Un SBOM es una instantanea. Debe actualizarse para seguir siendo util.

Cuando Regenerar:

• Cada lanzamiento (mayor, menor, parche)
• Despues de actualizaciones de dependencias
• Despues de parches de seguridad
• Cuando cambia la Configuración de construccion

Retencion: El CRA requiere retencion de 10 años. Almacena SBOMs historicos:

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

Lista de Verificación de Implementacion de SBOM

LISTA DE Verificación DE IMPLEMENTACION DE SBOM

SELECCION DE FORMATO:
[ ] CycloneDX 1.4+ o SPDX 2.3+ elegido
[ ] Formato JSON (legible por maquina)
[ ] Decisión documentada

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

Integración CI/CD:
[ ] Generacion de SBOM anadida al pipeline de construccion
[ ] Artefactos almacenados con retencion apropiada
[ ] Generacion activada en lanzamientos

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

OPERACIONES:
[ ] SBOM versionado junto con lanzamientos de producto
[ ] SBOMs historicos archivados (retencion de 10 años)
[ ] Proceso documentado para el equipo

Proximos Pasos

Con la generacion de SBOM automatizada, estas 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 tecnico: Incluir SBOMs en Documentación CRA
4. Preparacion para Notificación a ENISA: SBOMs permiten identificacion rapida de vulnerabilidades

CRA Evidence automatiza todo este flujo de trabajo:

• Subir SBOMs via CLI o CI/CD
• Escaneo automatico de vulnerabilidades con Trivy
• Puntuacion de calidad TR-03183
• Exportacion de expediente tecnico con SBOMs integrados

Comienza a generar SBOMs conformes en app.craevidence.com.

Requisitos: Comprende lo que el CRA requiere para SBOMs en nuestra guia de requisitos SBOM.

Calidad: Valida tu SBOM contra el estandar BSI TR-03183.

VEX: Agrega contexto de vulnerabilidades a tu SBOM con documentos VEX.

Este articulo es solo para fines informativos y no constituye asesoramiento legal. Para orientacion especifica sobre cumplimiento, consulta con asesores legales cualificados familiarizados con las regulaciones de productos de la UE.