"Supplier is a minimum element and must not be empty" oplossen in CycloneDX SBOM's

Als je ooit een CycloneDX SBOM hebt gecontroleerd met de FOSSA NTIA SBOM Validator of een vergelijkbare tool, heb je mogelijk fouten gezien zoals deze:

Deze fouten betekenen dat je SBOM technisch gezien een geldig CycloneDX-document is — het slaagt voor schemavalidatie — maar niet voldoet aan de NTIA-minimumelementen voor een Software Bill of Materials. Als je software verkoopt in de EU onder de Cyber Resilience Act (CRA), of levert aan een Amerikaanse federale instantie, is NTIA-compliance doorgaans niet optioneel.

Laten we analyseren wat er gebeurt en hoe je het oplost.

Wat de NTIA-minimumelementen vereisen

De NTIA publiceerde haar "Minimum Elements for a Software Bill of Materials" in 2021. Onder de verplichte gegevensvelden voor elk SBOM zijn:

De Leveranciersnaam is vereist op drie verschillende plaatsen in een CycloneDX SBOM:

1. metadata.supplier — de organisatie die de beschreven software levert
2. metadata.component.supplier — de leverancier van het hoofdcomponent
3. components[].supplier — de leverancier van elke vermelde afhankelijkheid

De meeste SBOM-generators, waaronder populaire tools zoals Syft en Trivy, lieten deze velden historisch gezien weg. CycloneDX-schemavalidatie vereist ze niet — ze zijn optioneel in de specificatie. Maar NTIA-validatie wel, en dat is wat telt voor compliance.

De oorzaak

Wanneer je npm install of pip install uitvoert, registreert het resulterende lockfile (package-lock.json, requirements.txt, enz.) pakketnamen, versies en afhankelijkheidsrelaties. Wat het niet registreert is wie elk pakket heeft gepubliceerd. Die metadata staat in het pakketregister (npmjs.org, PyPI, enz.), niet in je lockfile.

De meeste SBOM-generators parseren alleen het lockfile. Resultaat: elk component krijgt een naam en versie, maar geen leverancier. Het SBOM is schemavalide maar niet NTIA-compliant.

De oplossing: supplier-velden op elk niveau invullen

1. Supplier in metadata

De metadata-sectie van je SBOM heeft een supplier-object nodig met minstens een name:

{
  "metadata": {
    "supplier": {
      "name": "je-projectnaam"
    },
    "component": {
      "type": "application",
      "name": "je-projectnaam",
      "version": "1.0.0",
      "supplier": {
        "name": "je-projectnaam"
      }
    }
  }
}

De metadata.supplier vertegenwoordigt de organisatie die de software levert die door dit SBOM wordt beschreven. Voor de meeste teams is dit je project- of bedrijfsnaam.

2. Tool-supplier

Als je SBOM de genererende tool vermeldt onder metadata.tools, moet elke tool ook een supplier hebben:

{
  "tools": [
    {
      "name": "je-sbom-tool",
      "version": "1.0.0",
      "supplier": {
        "name": "Je Toolaanbieder"
      }
    }
  ]
}

3. Component-suppliers — het lastige deel

Elke vermelding in de components-array heeft een supplier.name nodig. Maar waar komen die gegevens vandaan als het lockfile ze niet heeft?

Er zijn twee benaderingen:

Optie A: Verrijking vanuit het register (ideaal, langzamer)

De npm-register-API (https://registry.npmjs.org/{package}) aanroepen voor elke afhankelijkheid, de auteur of uitgever extraheren en de supplier invullen. Dit geeft de meest nauwkeurige gegevens maar voegt netwerkverzoeken en latentie toe aan je SBOM-generatiepipeline.

Optie B: Heuristiek op basis van pakket-scope (praktisch, snel)

Voor npm-pakketten is de scope (het @org/-prefix) een redelijke proxy voor de leverancier. Bijvoorbeeld:

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

Dit is de benadering die tools zoals Syft en Trivy gebruiken. Het is niet perfect — een pakket zonder scope zoals express wordt aan zichzelf toegeschreven — maar het voldoet aan het NTIA-vereiste en is een verdedigbare keuze voor geautomatiseerde tooling. De scope vertegenwoordigt oprecht de organisatorische entiteit die het pakket heeft gepubliceerd.

Upgraden naar CycloneDX 1.7

Terwijl je supplier-velden corrigeert, is het de moeite waard om de specificatieversie te upgraden. CycloneDX 1.7 (uitgebracht in oktober 2025) is de nieuwste versie en is volledig achterwaarts compatibel. De wijzigingen zijn minimaal:

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

Na de correctie

Met supplier-velden ingevuld op elk niveau, zou je SBOM alle NTIA-minimumelementcontroles moeten doorstaan:

Hoe Verimu dit aanpakt

Elk SBOM gegenereerd door Verimu bevat al supplier-velden op alle drie niveaus — metadata.supplier, metadata.component.supplier en per component supplier — met scope-gebaseerde heuristieken voor npm-pakketten (met registerverrijking gepland voor een toekomstige release).

Onze SBOM's worden gegenereerd volgens de CycloneDX 1.7-specificatie en gevalideerd tegen NTIA-minimumelementen vóór levering. Als je werkt aan CRA-compliance voor toegang tot de Europese markt tegen september 2026, is dit één ding minder om je zorgen over te maken.

Start gratis → of boek een demo om te zien hoe Verimu SBOM-generatie aanpakt voor jouw stack.