Generera en CRA-kompatibel SBOM: verktyg och CI/CD

CRA kräver en Software Bill of Materials. Varje konkurrentartikel berättar detta för dig. Ingen visar hur du genererar en.

Den här guiden täcker verktyg med öppen källkod, formatval och CI/CD-integration utan krav på leverantörslåsning.

Vad CRA faktiskt kräver

Börja med vad förordningen säger. Bilaga I, Del II av CRA kräver att tillverkare:

"identifiera och dokumentera sårbarheter och komponenter i produkter med digitala element, bland annat genom att upprätta en programvaruförteckning för material i ett allmänt använt och maskinläsbart format som åtminstone täcker produktens viktigaste (top-level) beroenden"

Nyckelpoänger:

• Maskinläsbart format: Inte en PDF, inte ett kalkylblad, utan strukturerad data
• Minst beroenden på toppnivå: Minimomfånget, men mer är bättre
• Behöver inte vara offentlig: Tillhandahålls till myndigheter på begäran
• Måste uppdateras: Med varje utgåva, patch eller komponentändring

CRA föreskriver inte ett specifikt format, men standardiseringsarbete pekar tydligt mot CycloneDX och SPDX.

SBOM:en är en del av CRA:s tekniska dokumentation enligt Bilaga VII. Tillverkare måste upprätta denna dokumentation innan en produkt släpps på marknaden och hålla den tillgänglig för marknadskontrollmyndigheter i minst 10 år, eller under supportperioden, beroende på vilket som är längst (Artikel 13(13)). En SBOM lagrad lokalt utan koppling till en specifik produktversion uppfyller inte kravet. Den måste vara åtkomlig, versionerad och kopplad till den produktversion den beskriver.

Formatval: CycloneDX kontra SPDX

Två format dominerar SBOM-landskapet. Båda är acceptabla för CRA-efterlevnad.

CycloneDX

Ursprung: OWASP-projekt, säkerhetsfokuserat Aktuell version: 1.6 (1.4+ rekommenderas för CRA) Bäst för: Säkerhet och sårbarhethantering

Styrkor:

• Inbyggt VEX-stöd (Vulnerability Exploitability eXchange)
• Designat för säkerhetsändamål
• Lättare specifikation, enklare att implementera
• Starkt verktygsekosystem
• Direkt CVE/sårbarhetslänkning

JSON-exempel:

{
  "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

Ursprung: Linux Foundation, licensefterlevnadsfokuserat Aktuell version: 2.3 (ISO/IEC 5962:2021-standard) Bäst för: Licensefterlevnad och juridisk granskning

Styrkor:

• ISO internationell standard
• Uttömmande licensuttryckssyntax
• Stark i öppen källkod-efterlevnadssammanhang
• Längre meritlista
• Bättre för komplexa licensscenarier

JSON-exempel:

{
  "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..."
        }
      ]
    }
  ]
}

Vilket ska du välja?

För CRA-efterlevnad fungerar båda formaten. Välj ett och var konsekvent.

SBOM-genereringsverktyg med öppen källkod

Ingen leverantörslåsning krävs. Dessa verktyg är gratis, öppen källkod och produktionsklara.

Syft (Anchore)

Bäst för: Containeravbildningar, filsystem, arkiv Licens: Apache 2.0 Utdataformat: CycloneDX, SPDX, Syft JSON

Installation:

# 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

Användningsexempel:

# Skanna en containeravbildning
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

# Skanna en katalog
syft dir:/path/to/project -o cyclonedx-json > sbom.cdx.json

# Skanna ett arkiv
syft /path/to/archive.tar.gz -o spdx-json > sbom.spdx.json

# Skanna med specifika katalogisatorer (t.ex. bara Python)
syft dir:. -o cyclonedx-json --select-catalogers python

Stödda ekosystem: Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET och mer.

Trivy (Aqua Security)

Bäst för: Containeravbildningar med inbyggt sårbarhetsammanhang Licens: Apache 2.0 Utdataformat: CycloneDX, SPDX, plus sårbarhetrapporter

Installation:

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

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Användningsexempel:

# Generera SBOM från containeravbildning
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# Generera SBOM från filsystem
trivy fs --format cyclonedx --output sbom.cdx.json /path/to/project

# Generera SBOM med sårbarhetsinformation
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Fördel: Trivy kan generera SBOM:er och skanna efter sårbarheter i ett svep.

cdxgen (CycloneDX)

Bäst för: Källkodsanalys för många språk Licens: Apache 2.0 Utdataformat: CycloneDX

Installation:

# npm (kräver Node.js)
npm install -g @cyclonedx/cdxgen

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Användningsexempel:

# Skanna aktuell katalog
cdxgen -o sbom.json

# Skanna specifik projekttyp
cdxgen -t python -o sbom.json

# Skanna med djup beroendeupplösning
cdxgen --deep -o sbom.json

# Skanna en specifik katalog
cdxgen -o sbom.json /path/to/project

Stödda språk: JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++ och mer.

Verktygsjämförelse

Rekommendation: Börja med Syft för de flesta användningsfall. Lägg till Trivy om du behöver integrerad sårbarhetsskanning. Använd cdxgen för komplexa källkodsprojekt.

Inbyggd programvara och inbyggda enheter

Verktygen ovan fungerar bra för containrar och pakethanterare. För inbyggd programvara och inbyggda enheter (det primära CRA-målet) ser metoden annorlunda ut.

Firmware-avbildningar är binära blobar, inte paketregister. Det vanliga första steget är att extrahera filsystemet:

# Extrahera filsystem från firmware-avbildning
binwalk -Me firmware.bin

# Kör Syft på det extraherade filsystemet
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Använd binwalk -Me (rekursiv extraktion) snarare än -e för kapslade eller komprimerade avbildningar. Täckningen är lägre än för containeravbildningar. Strippade binärfiler förlorar symbolinformation och Syft kanske inte identifierar alla komponenter.

För binärnivåanalys av kompilerade komponenter ger BLint, cve-bin-tool och EMBA djupare inspektion. Proprietära SDK:er och proprietär källkod inbäddad i firmware kräver vanligen manuella SBOM-poster. Dokumentera leverantör, version och käll-URL.

CI/CD-integration

Manuell SBOM-generering skalar inte. Integrera det i din byggpipeline.

GitHub Actions

name: SBOM Generation

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # krävs för nyckellös Cosign-signering
    steps:
      - name: Hämta källkod
        uses: actions/checkout@v4

      - name: Bygg containeravbildning
        run: |
          docker build -t myapp:${{ github.sha }} .

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

      - name: Generera SBOM från byggd avbildning
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

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

      - name: Signera SBOM (nyckellös)
        run: |
          cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json --yes

      - name: Ladda upp SBOM och signatur som artefakter
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Valfritt: Ladda upp till CRA Evidence för långtidslagring
      - name: Ladda upp till 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 }}"

Obs: CI-artefakten (retention-days: 90) är för utvecklarnas bekvämlighet, inte för efterlevnad. För CRA-kompatibel 10-årslagring, ladda upp till ett dedikerat långtidslager vid varje version. Se avsnittet Lagring nedan.

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('Generate SBOM') {
            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('Archive SBOM') {
            steps {
                archiveArtifacts artifacts: 'sbom.cdx.json', fingerprint: true
            }
        }
    }
}

Docker Build-integration

Generera SBOM under Docker-bygget:

# Flerstegsbygge med SBOM-generering
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

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

# Slutlig avbildning
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-signering

CRA föreskriver inte SBOM-signering, men signering säkerställer att SBOM:en inte har modifierats sedan den genererades. Företagsinköpsteam och anmälda organ förväntar sig i allt högre grad en verifierbar signatur tillsammans med SBOM-filen.

Cosign (del av Sigstore-projektet) är standardverktyget:

# Installera Cosign
brew install cosign

# Signera en SBOM-fil. Producerar ett paket med signaturen och certifikatet
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Verifiera senare
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <din-identitet> \
  --certificate-oidc-issuer <din-utfärdare>

Spara sbom.cdx.json och sbom.cdx.json.sigstore.json tillsammans. Paketet innehåller signaturen, signeringscertifikatet och Rekor-transparensloggens post. Vem som helst med paketet kan verifiera SBOM:en utan att kontakta dig.

För CI/CD stöder Cosign nyckellös signering med hjälp av pipelinens OIDC-identitet (GitHub Actions, GitLab CI). Inga nycklar att hantera. GitHub Actions-exemplet ovan inkluderar redan detta: jobbet behöver behörigheten id-token: write, och sign-blob tar --yes för att köra utan interaktiv prompt. Cosign 2.0 och senare gör nyckellös signering till standard, så den gamla COSIGN_EXPERIMENTAL-flaggan behövs inte längre.

Kontinuerlig övervakning

En signerad, lagrad SBOM är inte slutmålet. Nya sårbarheter avslöjas mot komponenter som var rena vid utgåvan. Den lagrade SBOM:en måste skannas om regelbundet så att dessa CVE:er kommer fram i ljuset.

Grype läser en befintlig SBOM direkt, så omsökningen behöver inte den ursprungliga byggmiljön:

name: SBOM Rescan

on:
  schedule:
    - cron: "0 6 * * 1"  # Veckovis, måndag 06:00 UTC

jobs:
  rescan:
    runs-on: ubuntu-latest
    steps:
      - name: Hämta den lagrade SBOM:en
        env:
          SBOM_URL: ${{ vars.SBOM_URL }}
        run: |
          curl -sSfL -o sbom.cdx.json "$SBOM_URL"

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

      - name: Skanna SBOM:en efter nya CVE:er
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence kör denna omsökning automatiskt för varje uppladdad SBOM och varnar dig när en ny CVE matchar en komponent, vilket täcker samma behov utan ett schemalagt jobb.

SBOM-kvalitet: Uppfylla TR-03183

Tyska BSIs tekniska riktlinje TR-03183 utökar NTIA:s minimielement. Även om det inte är juridiskt obligatoriskt i hela EU, säkerställer följande av TR-03183 högkvalitativa SBOM:er.

Obligatoriska fält

Validera SBOM-kvalitet

Använd dessa verktyg för att kontrollera din SBOM:

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

# Kontrollera för minimifält med jq
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Räkna komponenter med hashar
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

Förbättra SBOM-kvalitet

Om din SBOM saknar data:

1. Använd låsfiler: package-lock.json, Pipfile.lock, go.sum innehåller mer metadata
2. Skanna byggda artefakter: Mer kompletta än enbart källkodskanningar
3. Kombinera verktyg: Olika verktyg hittar olika komponenter
4. Lägg till manuella poster: För kommersiella eller interna komponenter

Hålla SBOM:er aktuella

En SBOM är en ögonblicksbild. Den måste uppdateras för att förbli användbar.

När du ska regenerera

• Varje utgåva (major, minor, patch)
• Efter beroendeuppdateringar
• Efter säkerhetspatchar
• När byggkonfigurationen ändras

Versionsstrategi

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

Eller använd tidsstämplar:

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

Lagring

CI-artefakters lagringstid (90 dagar i exemplen ovan) är för utvecklarnas bekvämlighet, inte för efterlevnad. 10-årskravet kräver ett dedikerat långtidslager. CRA Evidence är byggt just för detta: versionerad SBOM-lagring med sårbarhetsomsökning och teknisk filexport, kopplad till varje produktversion.

Om du föredrar att lagra det själv fungerar alla större objektlager när du aktiverar rätt kontroller:

En livscykelpolicy ensam räcker inte. Lagret måste också stödja versionering, åtkomstkontroller och helst oföränderlighetspolicy för att uppfylla revisionskraven.

Vanliga fallgropar

Engångsgenerering av SBOM

Problem: Skapa en SBOM en gång och aldrig uppdatera den.

Lösning: Automatisera SBOM-generering i CI/CD. Varje bygg bör producera en färsk SBOM.

Saknade transitiva beroenden

Problem: SBOM listar bara direkta beroenden, missar kapslade paket.

Lösning: Använd låsfiler, skanna byggda artefakter, aktivera djupskanningsalternativ.

Fel formatversion

Problem: Använder CycloneDX 1.3 när TR-03183 rekommenderar 1.4+.

Lösning: Kontrollera din utdataversion. Uppdatera verktyg regelbundet.

Inga hashvärden

Problem: Komponenter utan kryptografiska hashar kan inte verifieras.

Lösning: Säkerställ att ditt verktyg inkluderar hashar. Syft och Trivy lägger till SHA-256-hashar när de kan läsa komponentfilerna.

Manuell skapande

Problem: Manuellt utformade SBOM:er är felbenägna och ohållbara.

Lösning: Automatisera alltid. Manuella poster bara för komponenter som verktyg inte kan detektera.

Ignorera interna komponenter

Problem: Dokumentera bara öppen källkod-beroenden, inte proprietär kod.

Lösning: Interna komponenter behöver dokumentation också. Lägg till dem manuellt eller konfigurera verktyg på lämpligt sätt.

Checklista för SBOM-implementering

Krav: Förstå vad CRA kräver för SBOM:er i vår guide för SBOM-krav.

Kvalitet: Validera din SBOM mot BSI TR-03183-standarden.

VEX: Lägg till sårbarhetsammanhang i din SBOM med VEX-dokument.

Den här artikeln är endast avsedd för informationsändamål och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, konsultera kvalificerade juridiska rådgivare med erfarenhet av EU-produktreglering.