"Supplier is a minimum element and must not be empty" in CycloneDX SBOMs beheben

Wenn Sie jemals ein CycloneDX SBOM durch den FOSSA NTIA SBOM Validator oder ein ähnliches Tool haben laufen lassen, haben Sie möglicherweise Fehler wie diese gesehen:

Diese Fehler bedeuten, dass Ihr SBOM technisch gültiges CycloneDX ist — es besteht die Schema-Validierung — aber die NTIA-Mindestanforderungen für eine Software Bill of Materials nicht erfüllt. Wenn Sie Software in der EU unter dem Cyber Resilience Act (CRA) verkaufen oder an eine US-Bundesbehörde liefern, ist NTIA-Konformität in der Regel nicht optional.

Schauen wir uns an, was passiert und wie man es behebt.

Was die NTIA-Mindestanforderungen verlangen

Die NTIA hat ihre „Minimum Elements for a Software Bill of Materials" 2021 veröffentlicht. Zu den erforderlichen Datenfeldern für jedes SBOM gehören:

Der Supplier Name ist an drei verschiedenen Stellen in einem CycloneDX SBOM erforderlich:

1. metadata.supplier — die Organisation, die die beschriebene Software bereitstellt
2. metadata.component.supplier — der Supplier der Top-Level-Komponente
3. components[].supplier — der Supplier jeder aufgeführten Abhängigkeit

Die meisten SBOM-Generatoren, einschließlich beliebter Tools wie Syft und Trivy, haben diese Felder historisch weggelassen. Die CycloneDX-Schema-Validierung verlangt sie nicht — sie sind in der Spezifikation optional. Aber die NTIA-Validierung schon, und das ist für die Compliance entscheidend.

Die Ursache

Wenn Sie npm install oder pip install ausführen, zeichnet die resultierende Lockfile (package-lock.json, requirements.txt usw.) Paketnamen, Versionen und Abhängigkeitsbeziehungen auf. Was sie nicht aufzeichnet, ist, wer jedes Paket veröffentlicht hat. Diese Metadaten befinden sich in der Package-Registry (npmjs.org, PyPI usw.), nicht in Ihrer Lockfile.

Die meisten SBOM-Generatoren parsen die Lockfile und nichts anderes. Ergebnis: Jede Komponente bekommt einen Namen und eine Version, aber keinen Supplier. Das SBOM ist schema-valide, aber nicht NTIA-konform.

Die Lösung: Supplier-Felder auf jeder Ebene befüllen

1. Metadata Supplier

Der metadata-Bereich Ihres SBOMs benötigt ein supplier-Objekt mit mindestens einem name:

{
  "metadata": {
    "supplier": {
      "name": "your-project-name"
    },
    "component": {
      "type": "application",
      "name": "your-project-name",
      "version": "1.0.0",
      "supplier": {
        "name": "your-project-name"
      }
    }
  }
}

Der metadata.supplier repräsentiert die Organisation, die die in diesem SBOM beschriebene Software bereitstellt. Für die meisten Teams ist dies Ihr Projekt- oder Firmenname.

2. Tool Supplier

Wenn Ihr SBOM das generierende Tool unter metadata.tools aufführt, sollte jedes Tool ebenfalls einen supplier tragen:

{
  "tools": [
    {
      "name": "your-sbom-tool",
      "version": "1.0.0",
      "supplier": {
        "name": "Your Tool Vendor"
      }
    }
  ]
}

3. Component Suppliers — der knifflige Teil

Jeder Eintrag im components-Array benötigt einen supplier.name. Aber woher kommen diese Daten, wenn die Lockfile sie nicht hat?

Es gibt zwei Ansätze:

Option A: Registry-Anreicherung (ideal, langsamer)

Rufen Sie die npm-Registry-API (https://registry.npmjs.org/{package}) für jede Abhängigkeit auf, extrahieren Sie den Autor oder Publisher und füllen Sie den Supplier. Das liefert die genauesten Daten, fügt aber Netzwerkaufrufe und Latenz zu Ihrer SBOM-Generierungspipeline hinzu.

Option B: Heuristik aus dem Package Scope (praktisch, schnell)

Bei npm-Paketen ist der Scope (das @org/-Präfix) ein vernünftiger Proxy für den Supplier. Zum Beispiel:

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

Dies ist der Ansatz, den Tools wie Syft und Trivy verwenden. Er ist nicht perfekt — ein unscoped Paket wie express wird sich selbst zugeordnet — aber er erfüllt die NTIA-Anforderung und ist eine vertretbare Wahl für automatisierte Werkzeuge. Der Scope repräsentiert tatsächlich die organisatorische Entität, die das Paket veröffentlicht hat.

Upgrade auf CycloneDX 1.7

Während Sie die Supplier-Felder korrigieren, lohnt sich ein Upgrade Ihrer Spec-Version. CycloneDX 1.7 (veröffentlicht Oktober 2025) ist die neueste Version und vollständig abwärtskompatibel. Die Änderungen sind minimal:

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

Nach der Korrektur

Mit befüllten Supplier-Feldern auf jeder Ebene sollte Ihr SBOM alle NTIA-Mindestanforderungsprüfungen bestehen:

Wie Verimu das handhabt

Jedes von Verimu generierte SBOM enthält bereits Supplier-Felder auf allen drei Ebenen — metadata.supplier, metadata.component.supplier und pro Komponente supplier — unter Verwendung von Scope-basierten Heuristiken für npm-Pakete (mit geplanter Registry-Anreicherung in einem zukünftigen Release).

Unsere SBOMs werden gegen die CycloneDX 1.7 Spezifikation generiert und vor der Auslieferung gegen NTIA-Mindestanforderungen validiert. Wenn Sie auf CRA-Compliance für den EU-Marktzugang bis September 2026 hinarbeiten, ist das eine Sorge weniger.

Kostenlos starten → oder Demo buchen, um zu sehen, wie Verimu die SBOM-Generierung für Ihren Stack handhabt.