Een CRA-conforme SBOM genereren: tools, formaten, CI/CD

De CRA vereist een Software Bill of Materials. Elk concurrerend artikel vertelt u dit. Geen enkel laat u zien hoe u er een genereert.

Deze gids behandelt open-source tools, formaatkeuze en CI/CD-integratie zonder vendor lock-in.

Wat de CRA daadwerkelijk vereist

Begin met wat de verordening zegt. Bijlage I, Deel II van de CRA vereist dat fabrikanten:

"kwetsbaarheden en componenten in producten met digitale elementen vaststellen en documenteren, onder meer door een softwarestuklijst op te stellen in een algemeen gebruikt en machineleesbaar formaat waarin ten minste de afhankelijkheden van de producten op het hoogste niveau worden aangegeven"

Kernpunten:

• Machineleesbaar formaat: Geen PDF, geen spreadsheet, maar gestructureerde data
• Minimaal top-level dependencies: Het minimum, meer is beter
• Niet verplicht openbaar: Verstrekt aan autoriteiten op verzoek
• Moet worden bijgewerkt: Bij elke release, patch of componentwijziging

De CRA schrijft geen specifiek formaat voor, maar standaardiseringsinitiatieven wijzen duidelijk naar CycloneDX en SPDX.

De SBOM maakt deel uit van de CRA technische documentatie onder Bijlage VII. Fabrikanten moeten die documentatie opstellen voordat een product op de markt wordt gebracht en beschikbaar houden voor markttoezichtautoriteiten gedurende ten minste 10 jaar na het in de handel brengen, of voor de ondersteuningsperiode, afhankelijk van welke termijn langer is (Artikel 13, lid 13). Een SBOM die lokaal is opgeslagen zonder koppeling aan een specifieke productrelease voldoet daar niet aan. Deze moet opvraagbaar, geversioned en gekoppeld zijn aan de productversie die zij beschrijft.

Formaatkeuze: CycloneDX vs. SPDX

Twee formaten domineren het SBOM-landschap. Beide zijn acceptabel voor CRA-compliance.

CycloneDX

Oorsprong: OWASP-project, beveiligingsgericht Huidige versie: 1.6 (1.4+ aanbevolen voor CRA) Beste voor: Beveiligings- en kwetsbaarheidsbeheer

Sterke punten:

• Native VEX-ondersteuning (Vulnerability Exploitability eXchange)
• Ontworpen voor beveiligingsgebruiksscenario's
• Lichtere specificatie, eenvoudiger te implementeren
• Sterk tools-ecosysteem
• Directe CVE-/kwetsbaarheidskoppeling

JSON-voorbeeld:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "cc6d..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ]
}

SPDX

Oorsprong: Linux Foundation, licentie-compliance-gericht Huidige versie: 2.3 (ISO/IEC 5962:2021-norm) Beste voor: Licentie-compliance en juridische review

Sterke punten:

• ISO internationale norm
• Uitgebreide licentie-expressiesyntax
• Sterk in open-source compliance-contexten
• Langere staat van dienst
• Beter voor complexe licentiescenario's

JSON-voorbeeld:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "cc6d..."
        }
      ]
    }
  ]
}

Welk formaat kiezen?

Voor CRA-compliance werkt elk formaat. Kies er één en wees consistent.

Open-source SBOM-generatietools

Geen vendor lock-in vereist. Deze tools zijn gratis, open-source en productieklaar.

Syft (Anchore)

Beste voor: Containerimages, bestandssystemen, archieven Licentie: Apache 2.0 Uitvoerformaten: CycloneDX, SPDX, Syft JSON

Installatie:

# 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

Gebruiksvoorbeelden:

# Containerimage scannen
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

# Map scannen
syft dir:/pad/naar/project -o cyclonedx-json > sbom.cdx.json

# Archief scannen
syft /pad/naar/archief.tar.gz -o spdx-json > sbom.spdx.json

# Scannen met specifieke catalogiseerders (bijv. alleen Python)
syft dir:. -o cyclonedx-json --select-catalogers python

Ondersteunde ecosystemen: Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET en meer.

Trivy (Aqua Security)

Beste voor: Containerimages met ingebouwde kwetsbaarheidscontext Licentie: Apache 2.0 Uitvoerformaten: CycloneDX, SPDX plus kwetsbaarheidsrapporten

Installatie:

# Linux (Debian/Ubuntu)
sudo apt-get install trivy

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Gebruiksvoorbeelden:

# SBOM genereren vanuit containerimage
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# SBOM genereren vanuit bestandssysteem
trivy fs --format cyclonedx --output sbom.cdx.json /pad/naar/project

# SBOM genereren met kwetsbaarheidsinfo
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Voordeel: Trivy kan SBOM's genereren en kwetsbaarheden scannen in één stap.

cdxgen (CycloneDX)

Beste voor: Broncodeanalyse in veel talen Licentie: Apache 2.0 Uitvoerformaat: CycloneDX

Installatie:

# npm (vereist Node.js)
npm install -g @cyclonedx/cdxgen

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Gebruiksvoorbeelden:

# Huidige map scannen
cdxgen -o sbom.json

# Specifiek projecttype scannen
cdxgen -t python -o sbom.json

# Scannen met diepe afhankelijkheidsresolutie
cdxgen --deep -o sbom.json

# Specifieke map scannen
cdxgen -o sbom.json /pad/naar/project

Ondersteunde talen: JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++ en meer.

Toolsvergelijking

Aanbeveling: Begin met Syft voor de meeste gebruiksscenario's. Voeg Trivy toe als u geïntegreerde kwetsbaarheidsscanning nodig heeft. Gebruik cdxgen voor complexe broncodeprojecten.

Firmware en embedded apparaten

De bovenstaande tools werken goed voor containers en pakketbeheerders. Voor firmware en embedded apparaten (het primaire CRA-doelwit) is de aanpak anders.

Firmware-images zijn binaire bestanden, geen pakketregisters. De standaard eerste stap is het extraheren van het bestandssysteem:

# Bestandssysteem extraheren uit firmware-image
binwalk -Me firmware.bin

# Syft uitvoeren op het geëxtraheerde bestandssysteem
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Gebruik binwalk -Me (recursieve extractie) in plaats van -e voor geneste of gecomprimeerde images. De dekking is lager dan bij containerimages. Gestripte binaire bestanden verliezen symboolinformatie en Syft herkent mogelijk niet alle componenten.

Voor binaire analyse van gecompileerde componenten bieden BLint, cve-bin-tool of EMBA diepere inspectie. Proprietary SDK's en gesloten-source bibliotheken in firmware vereisen doorgaans handmatige SBOM-vermeldingen. Documenteer de leverancier, versie en bron-URL.

CI/CD-integratie

Handmatige SBOM-generatie schaalt niet. Integreer het in uw buildpipeline.

GitHub Actions

name: SBOM-generatie

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # vereist voor keyless ondertekening met Cosign
    steps:
      - name: Code uitchecken
        uses: actions/checkout@v4

      - name: Containerimage bouwen
        run: |
          docker build -t myapp:${{ github.sha }} .

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

      - name: SBOM genereren vanuit gebouwd image
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

      - name: Cosign installeren
        uses: sigstore/cosign-installer@v3

      - name: SBOM ondertekenen (keyless)
        run: |
          cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json --yes

      - name: SBOM en handtekening uploaden als artefacten
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Optioneel: uploaden naar CRA Evidence voor langdurige compliance-opslag
      - name: Uploaden naar CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://api.craevidence.com/api/v1/ci/sbom \
            -H "Authorization: Bearer $CRA_EVIDENCE_TOKEN" \
            -F "file=@sbom.cdx.json" \
            -F "product_id=${{ vars.PRODUCT_ID }}" \
            -F "version=${{ github.ref_name }}"

Let op: Het CI-artefact (retention-days: 90) is voor het gemak van ontwikkelaars, niet voor compliance. Voor CRA-conforme bewaring van 10 jaar uploadt u bij elke release naar een speciale langetermijnopslag. Zie de sectie Bewaring hieronder.

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

Jenkins

pipeline {
    agent any

    stages {
        stage('SBOM genereren') {
            steps {
                sh '''
                    curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b .
                    ./syft dir:. -o cyclonedx-json > sbom.cdx.json
                '''
            }
        }

        stage('SBOM archiveren') {
            steps {
                archiveArtifacts artifacts: 'sbom.cdx.json', fingerprint: true
            }
        }
    }
}

Docker Build-integratie

SBOM genereren tijdens Docker build:

# Multi-stage build met SBOM-generatie
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# SBOM genereren in buildstage
FROM anchore/syft:latest AS sbom
COPY --from=builder /app /app
RUN syft dir:/app -o cyclonedx-json > /sbom.cdx.json

# Eindimage
FROM node:20-slim
COPY --from=builder /app/dist /app
COPY --from=sbom /sbom.cdx.json /app/sbom.cdx.json
CMD ["node", "/app/index.js"]

SBOM ondertekenen

De CRA schrijft het ondertekenen van SBOM's niet voor, maar een handtekening bewijst dat de SBOM niet is gewijzigd na het genereren. Zakelijke inkoopteams en aangemelde instanties verwachten steeds vaker een verifieerbare handtekening naast het SBOM-bestand.

Cosign (onderdeel van het Sigstore-project) is de standaard tool:

# Cosign installeren
brew install cosign

# Een SBOM-bestand ondertekenen. Produceert een bundel met de handtekening en het certificaat
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Later verifiëren
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <uw-identiteit> \
  --certificate-oidc-issuer <uw-issuer>

Sla sbom.cdx.json en sbom.cdx.json.sigstore.json samen op. De bundel bevat de handtekening, het ondertekeningscertificaat en de Rekor-transparantielogvermelding. Iedereen met de bundel kan de SBOM verifiëren zonder u te contacteren.

Voor CI/CD ondersteunt Cosign keyless ondertekening via de OIDC-identiteit van de pipeline (GitHub Actions, GitLab CI). Geen sleutels om te beheren. Het GitHub Actions-voorbeeld hierboven bevat dit al: de job heeft de machtiging id-token: write nodig en sign-blob gebruikt --yes om zonder interactieve prompt te werken. Cosign 2.0 en later maakt keyless ondertekening de standaard, zodat de oude markering COSIGN_EXPERIMENTAL niet langer nodig is.

Doorlopende monitoring

Een ondertekende, opgeslagen SBOM is niet het eindpunt. Nieuwe kwetsbaarheden worden bekend voor componenten die bij de release schoon waren. De opgeslagen SBOM moet op schema opnieuw worden gescand zodat die CVE's zichtbaar worden.

Grype leest een bestaande SBOM direct, zodat de herscan de oorspronkelijke bouwomgeving niet nodig heeft:

name: SBOM-herscan

on:
  schedule:
    - cron: "0 6 * * 1"  # Wekelijks, maandag 06:00 UTC

jobs:
  rescan:
    runs-on: ubuntu-latest
    steps:
      - name: Opgeslagen SBOM ophalen
        env:
          SBOM_URL: ${{ vars.SBOM_URL }}
        run: |
          curl -sSfL -o sbom.cdx.json "$SBOM_URL"

      - name: Grype installeren
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

      - name: SBOM scannen op nieuwe CVE's
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence voert deze herscan automatisch uit voor elke geüploade SBOM en waarschuwt u wanneer een nieuwe CVE overeenkomt met een component. Dat dekt dezelfde behoefte zonder een geplande job.

SBOM-kwaliteit: voldoen aan TR-03183

De Duitse BSI Technische Richtlijn TR-03183 breidt de NTIA-minimumelementen uit. Hoewel niet wettelijk verplicht in de hele EU, garandeert het volgen van TR-03183 hoge SBOM-kwaliteit.

Vereiste velden

SBOM-kwaliteit valideren

Gebruik deze tools om uw SBOM te controleren:

# CycloneDX-formaat valideren
npm install -g @cyclonedx/cyclonedx-cli
cyclonedx validate --input-file sbom.cdx.json

# Controleren op minimumvelden met jq
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Componenten met hashes tellen
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

SBOM-kwaliteit verbeteren

Als uw SBOM gegevens mist:

1. Gebruik lockfiles: package-lock.json, Pipfile.lock, go.sum bevatten meer metadata
2. Scan gebouwde artefacten: Completer dan alleen broncodescans
3. Combineer tools: Verschillende tools vinden verschillende componenten
4. Handmatige vermeldingen toevoegen: Voor commerciële of interne componenten

SBOM's actueel houden

Een SBOM is een momentopname. Deze moet worden bijgewerkt om bruikbaar te blijven.

Wanneer opnieuw genereren

• Bij elke release (major, minor, patch)
• Na afhankelijkheidsupdates
• Na beveiligingspatches
• Als de buildconfiguratie verandert

Versioneringsstrategie

product-v1.0.0-sbom.cdx.json
product-v1.0.1-sbom.cdx.json
product-v1.1.0-sbom.cdx.json

Of gebruik tijdstempels:

product-sbom-2026-01-15T10-30-00Z.cdx.json

Bewaring

Het CI-artefact (90 dagen in de bovenstaande voorbeelden) is voor het gemak van ontwikkelaars, niet voor compliance. De eis van 10 jaar vereist een speciale langetermijnopslag. CRA Evidence is daarvoor ontwikkeld: geversioned SBOM-opslag met kwetsbaarheidsherscan en export van technische bestanden, gekoppeld aan elke productrelease.

Wie de opslag zelf wil beheren, kan elke grote objectopslag gebruiken mits de juiste instellingen zijn geconfigureerd:

Een levenscyclusbeleid alleen is niet voldoende. De opslag moet ook versiebeheer, toegangscontroles en bij voorkeur onveranderlijkheid ondersteunen om aan auditvereisten te voldoen.

Veelgemaakte fouten

Eenmalige SBOM-generatie

Probleem: Eenmalig een SBOM aanmaken en nooit bijwerken.

Oplossing: SBOM-generatie automatiseren in CI/CD. Elke build moet een verse SBOM produceren.

Ontbrekende transitive dependencies

Probleem: SBOM vermeldt alleen directe afhankelijkheden, niet geneste pakketten.

Oplossing: Gebruik lockfiles, scan gebouwde artefacten, schakel opties voor diep scannen in.

Onjuiste formaatversie

Probleem: CycloneDX 1.3 gebruiken terwijl TR-03183 1.4+ aanbeveelt.

Oplossing: Controleer de uitvoerversie van uw tool. Houd tools regelmatig up-to-date.

Geen hashwaarden

Probleem: Componenten zonder cryptografische hashes kunnen niet worden geverifieerd.

Oplossing: Zorg dat uw tool hashes opneemt. Syft en Trivy voegen SHA-256-hashes toe als ze de componentbestanden kunnen lezen.

Handmatig aanmaken

Probleem: Handmatig SBOM's opstellen is foutgevoelig en onhoudbaar.

Oplossing: Altijd automatiseren. Handmatige vermeldingen alleen voor componenten die tools niet kunnen detecteren.

Interne componenten negeren

Probleem: Alleen open-source afhankelijkheden documenteren, niet de eigen code.

Oplossing: Interne componenten moeten ook worden gedocumenteerd. Voeg ze handmatig toe of configureer tools op de juiste manier.

SBOM-implementatiechecklist

Vereisten: Begrijp wat de CRA vereist voor SBOM's in onze SBOM-vereistengids.

Kwaliteit: Valideer uw SBOM aan de hand van de BSI TR-03183-norm.

VEX: Voeg kwetsbaarheidscontext toe aan uw SBOM met VEX-documenten.

Dit artikel is uitsluitend bedoeld ter informatie en vormt geen juridisch advies. Raadpleeg voor specifieke compliancebegeleiding een gekwalificeerde juridisch adviseur met kennis van EU-productregelgeving.