Cómo corregir "Supplier is a minimum element and must not be empty" en SBOMs CycloneDX

Si alguna vez has verificado un SBOM CycloneDX con el FOSSA NTIA SBOM Validator o una herramienta similar, es posible que hayas visto errores como estos:

Estos errores significan que tu SBOM es técnicamente un CycloneDX válido — supera la validación del esquema — pero no cumple con los elementos mínimos NTIA para un Software Bill of Materials. Si vendes software en la UE bajo el Cyber Resilience Act (CRA), o lo entregas a una agencia federal de EE.UU., el cumplimiento NTIA generalmente no es opcional.

Analicemos qué ocurre y cómo solucionarlo.

Qué requieren los elementos mínimos NTIA

El NTIA publicó sus "Minimum Elements for a Software Bill of Materials" en 2021. Entre los campos obligatorios para cada SBOM están:

El Nombre del Supplier se requiere en tres lugares distintos en un SBOM CycloneDX:

1. metadata.supplier — la organización que suministra el software descrito
2. metadata.component.supplier — el supplier del componente de nivel superior
3. components[].supplier — el supplier de cada dependencia listada

La mayoría de los generadores de SBOM, incluidas herramientas populares como Syft y Trivy, históricamente omitían estos campos. La validación del esquema CycloneDX no los requiere — son opcionales en la especificación. Pero la validación NTIA sí, y eso es lo que importa para el cumplimiento.

La causa raíz

Cuando ejecutas npm install o pip install, el lockfile resultante (package-lock.json, requirements.txt, etc.) registra nombres de paquetes, versiones y relaciones de dependencia. Lo que no registra es quién publicó cada paquete. Esos metadatos residen en el registro de paquetes (npmjs.org, PyPI, etc.), no en tu lockfile.

La mayoría de los generadores de SBOM analizan solo el lockfile. Resultado: cada componente obtiene un nombre y una versión, pero ningún supplier. El SBOM es válido según el esquema pero no cumple con NTIA.

La solución: completar los campos supplier en cada nivel

1. Supplier en metadata

La sección metadata de tu SBOM necesita un objeto supplier con al menos un name:

{
  "metadata": {
    "supplier": {
      "name": "nombre-de-tu-proyecto"
    },
    "component": {
      "type": "application",
      "name": "nombre-de-tu-proyecto",
      "version": "1.0.0",
      "supplier": {
        "name": "nombre-de-tu-proyecto"
      }
    }
  }
}

El metadata.supplier representa la organización que suministra el software descrito por este SBOM. Para la mayoría de los equipos, es el nombre de tu proyecto o empresa.

2. Supplier de la herramienta

Si tu SBOM lista la herramienta generadora bajo metadata.tools, cada herramienta debería llevar también un supplier:

{
  "tools": [
    {
      "name": "tu-herramienta-sbom",
      "version": "1.0.0",
      "supplier": {
        "name": "Tu Proveedor de Herramientas"
      }
    }
  ]
}

3. Supplier de los componentes — la parte complicada

Cada entrada en el array components necesita un supplier.name. Pero, ¿de dónde vienen esos datos si el lockfile no los tiene?

Hay dos enfoques:

Opción A: Enriquecimiento desde el registro (ideal, más lento)

Llamar a la API del registro npm (https://registry.npmjs.org/{package}) para cada dependencia, extraer el autor o publicador y completar el supplier. Esto proporciona los datos más precisos pero añade llamadas de red y latencia a tu pipeline de generación de SBOM.

Opción B: Heurística desde el scope del paquete (práctica, rápida)

Para los paquetes npm, el scope (el prefijo @org/) es un proxy razonable para el supplier. Por ejemplo:

• @angular/core → supplier: @angular
• @types/node → supplier: @types
• express → supplier: express

Este es el enfoque utilizado por herramientas como Syft y Trivy. No es perfecto — un paquete sin scope como express se atribuye a sí mismo — pero satisface el requisito NTIA y es una elección defendible para herramientas automatizadas. El scope genuinamente representa la entidad organizativa que publicó el paquete.

Actualización a CycloneDX 1.7

Mientras corriges los campos supplier, vale la pena actualizar la versión de la especificación. CycloneDX 1.7 (publicado en octubre de 2025) es la versión más reciente y es completamente retrocompatible. Los cambios son mínimos:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json"
}

Después de la corrección

Con los campos supplier completados en cada nivel, tu SBOM debería superar todas las verificaciones de elementos mínimos NTIA:

Cómo Verimu gestiona esto

Cada SBOM generado por Verimu ya incluye campos supplier en los tres niveles — metadata.supplier, metadata.component.supplier y supplier por componente — utilizando heurísticas basadas en scope para paquetes npm (con enriquecimiento desde el registro planificado para una versión futura).

Nuestros SBOMs se generan según la especificación CycloneDX 1.7 y se validan contra los elementos mínimos NTIA antes de la entrega. Si estás trabajando en el cumplimiento CRA para acceder al mercado europeo antes de septiembre de 2026, es un problema menos del que preocuparte.

Empieza gratis → o reserva una demo para ver cómo Verimu gestiona la generación de SBOM para tu stack.