Wygeneruj SBOM zgodny z CRA: narzędzia, formaty i CI/CD

CRA wymaga SBOM. Każdy artykuł konkurencji to powie. Żaden nie pokazuje, jak go wygenerować.

Ten przewodnik obejmuje narzędzia open-source, wybór formatu i integrację CI/CD bez uzależnienia od dostawcy.

Co Faktycznie Wymaga CRA

Zacznijmy od tego, co mówi rozporządzenie. Załącznik I, Część II CRA wymaga od producentów:

„identyfikowania i dokumentowania podatności i komponentów zawartych w produkcie z elementami cyfrowymi, w tym przez sporządzenie zestawienia podstawowych materiałów do produkcji oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu produktów"

Kluczowe punkty:

• Format czytelny maszynowo: Nie PDF, nie arkusz kalkulacyjny, lecz dane strukturalne
• Co najmniej zależności najwyższego poziomu: Minimalny zakres, choć więcej jest lepsze
• Nie musi być publiczny: Dostarczany organom na żądanie
• Musi być aktualizowany: Z każdym wydaniem, poprawką lub zmianą komponentu

CRA nie wymaga konkretnego formatu, ale wysiłki standaryzacyjne wyraźnie wskazują na CycloneDX i SPDX.

SBOM jest częścią dokumentacji technicznej CRA zgodnie z Załącznikiem VII. Producent ma przygotować tę dokumentację przed wprowadzeniem produktu do obrotu i udostępniać ją organom nadzoru rynku przez co najmniej 10 lat od wprowadzenia produktu do obrotu lub przez okres wsparcia, w zależności od tego, który jest dłuższy (art. 13 ust. 13). SBOM przechowywany lokalnie bez powiązania z konkretnym wydaniem produktu nie spełnia tego wymogu. Musi być możliwy do pobrania, wersjonowany i powiązany z wersją produktu, którą opisuje.

Wybór Formatu: CycloneDX vs SPDX

Dwa formaty dominują krajobraz SBOM. Oba są akceptowalne dla zgodności z CRA.

CycloneDX

Pochodzenie: Projekt OWASP, zorientowany na bezpieczeństwo Aktualna wersja: 1.6 (1.4+ zalecane dla CRA) Najlepszy dla: Zarządzania bezpieczeństwem i podatnościami

Mocne strony:

• Natywne wsparcie VEX (Vulnerability Exploitability eXchange)
• Zaprojektowany dla przypadków użycia związanych z bezpieczeństwem
• Lżejsza specyfikacja, łatwiejsza implementacja
• Silny ekosystem narzędzi
• Bezpośrednie linkowanie CVE/podatności

Przykład JSON:

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

Pochodzenie: Linux Foundation, zorientowany na zgodność licencyjną Aktualna wersja: 2.3. ISO/IEC 5962:2021 znormalizował SPDX 2.2.1 Najlepszy dla: Zgodności licencyjnej i przeglądu prawnego

Mocne strony:

• Międzynarodowy standard ISO
• Kompleksowa składnia wyrażeń licencyjnych
• Silny w kontekstach zgodności open source
• Dłuższa historia
• Lepszy dla złożonych scenariuszy licencyjnych

Przykład JSON:

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

Który Wybrać?

Dla zgodności z CRA oba formaty działają. Wybierz jeden i bądź konsekwentny.

Narzędzia Open-Source do Generowania SBOM

Bez uzależnienia od dostawcy. Te narzędzia są darmowe, open-source i gotowe do produkcji.

Syft (Anchore)

Najlepszy dla: Obrazów kontenerów, systemów plików, archiwów Licencja: Apache 2.0 Formaty wyjściowe: CycloneDX, SPDX, Syft JSON

Instalacja:

# 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

Przykłady użycia:

# Skanuj obraz kontenera
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

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

# Skanuj archiwum
syft /path/to/archive.tar.gz -o spdx-json > sbom.spdx.json

# Skanuj z konkretnymi katalogerami (np. tylko Python)
syft dir:. -o cyclonedx-json --select-catalogers python

Wspierane ekosystemy: Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET i więcej.

Trivy (Aqua Security)

Najlepszy dla: Obrazów kontenerów z wbudowanym kontekstem podatności Licencja: Apache 2.0 Formaty wyjściowe: CycloneDX, SPDX, plus raporty o podatnościach

Instalacja:

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

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Przykłady użycia:

# Generuj SBOM z obrazu kontenera
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# Generuj SBOM z systemu plików
trivy fs --format cyclonedx --output sbom.cdx.json /path/to/project

# Generuj SBOM z informacjami o podatnościach
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Zaleta: Trivy może generować SBOM i skanować pod kątem podatności w jednym przebiegu.

cdxgen (CycloneDX)

Najlepszy dla: Analizy kodu źródłowego w wielu językach Licencja: Apache 2.0 Format wyjściowy: CycloneDX

Instalacja:

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

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Przykłady użycia:

# Skanuj bieżący katalog
cdxgen -o sbom.json

# Skanuj konkretny typ projektu
cdxgen -t python -o sbom.json

# Skanuj z głębokim rozwiązywaniem zależności
cdxgen --deep -o sbom.json

# Skanuj konkretny katalog
cdxgen -o sbom.json /path/to/project

Wspierane języki: JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++ i więcej.

Porównanie Narzędzi

Rekomendacja: Zacznij od Syft dla większości przypadków użycia. Dodaj Trivy, jeśli potrzebujesz zintegrowanego skanowania podatności. Użyj cdxgen dla złożonych projektów kodu źródłowego.

Firmware i Urządzenia Wbudowane

Powyższe narzędzia sprawdzają się przy kontenerach i menedżerach pakietów. Dla firmware i urządzeń wbudowanych (główny cel CRA) podejście jest inne.

Obrazy firmware to binarne bloki danych, nie rejestry pakietów. Standardowym pierwszym krokiem jest wyodrębnienie systemu plików:

# Wyodrębnij system plików z obrazu firmware
binwalk -Me firmware.bin

# Uruchom Syft na wyodrębnionym systemie plików
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Użyj binwalk -Me (rekurencyjne wyodrębnianie) zamiast -e dla zagnieżdżonych lub skompresowanych obrazów. Pokrycie będzie niższe niż dla obrazów kontenerów. Pozbawione symboli pliki binarne tracą informacje i Syft może nie zidentyfikować wszystkich komponentów.

Do analizy binarnej skompilowanych komponentów, BLint, cve-bin-tool lub EMBA zapewniają głębszą inspekcję. Własnościowe SDK i zamknięte biblioteki osadzone w firmware zazwyczaj wymagają ręcznych wpisów SBOM. Udokumentuj dostawcę, wersję i URL źródłowy.

Integracja CI/CD

Ręczne generowanie SBOM nie skaluje się. Zintegruj je z potokiem budowania.

GitHub Actions

name: SBOM Generation

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # required for Cosign keyless signing
    steps:
      - name: Pobierz kod
        uses: actions/checkout@v4

      - name: Zbuduj obraz kontenera
        run: |
          docker build -t myapp:${{ github.sha }} .

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

      - name: Wygeneruj SBOM ze zbudowanego obrazu
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

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

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

      - name: Prześlij SBOM i podpis jako artefakty
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Opcjonalnie: Prześlij do CRA Evidence dla długoterminowego przechowywania
      - name: Prześlij do 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 }}"

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
            }
        }
    }
}

Integracja z Budowaniem Docker

Generuj SBOM podczas budowania Docker:

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

# Generuj SBOM w etapie budowania
FROM anchore/syft:latest AS sbom
COPY --from=builder /app /app
RUN syft dir:/app -o cyclonedx-json > /sbom.cdx.json

# Finalny obraz
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"]

Podpisywanie SBOM

CRA nie wymaga podpisywania SBOM, ale podpis potwierdza, że plik nie był modyfikowany od czasu wygenerowania. Zespoły zakupowe w przedsiębiorstwach i jednostki notyfikowane coraz częściej oczekują weryfikowalnego podpisu obok pliku SBOM.

Cosign (część projektu Sigstore) to standardowe narzędzie:

# Zainstaluj Cosign
brew install cosign

# Podpisz plik SBOM. Tworzy pakiet z podpisem i certyfikatem
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Zweryfikuj później
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <your-identity> \
  --certificate-oidc-issuer <your-issuer>

Przechowuj sbom.cdx.json i sbom.cdx.json.sigstore.json razem. Pakiet zawiera podpis, certyfikat podpisywania i wpis w dzienniku przejrzystości Rekor. Każdy posiadający pakiet może zweryfikować SBOM bez kontaktowania się z producentem.

W CI/CD Cosign obsługuje podpisywanie bezkluczowe przy użyciu tożsamości OIDC potoku (GitHub Actions, GitLab CI). Brak kluczy do zarządzania. Przykład GitHub Actions powyżej zawiera już to: zadanie wymaga uprawnienia id-token: write, a sign-blob przyjmuje --yes, by działać bez interaktywnego monitu. Cosign 2.0 i nowsze domyślnie używają podpisywania bezkluczowego, więc stara flaga COSIGN_EXPERIMENTAL nie jest już potrzebna.

Ciągły Monitoring

Podpisany, przechowywany SBOM to nie koniec. Nowe podatności są ujawniane dla komponentów, które były czyste w momencie wydania. Przechowywany SBOM musi być regularnie ponownie skanowany, by te CVE zostały wykryte.

Grype odczytuje istniejący SBOM bezpośrednio, więc ponowne skanowanie nie wymaga oryginalnego środowiska budowania:

name: SBOM Rescan

on:
  schedule:
    - cron: "0 6 * * 1"  # Tygodniowo, poniedziałek 06:00 UTC

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

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

      - name: Skanuj SBOM w poszukiwaniu nowych CVE
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence uruchamia to ponowne skanowanie automatycznie dla każdego przesłanego SBOM i powiadamia, gdy nowe CVE dotyczy komponentu, co spełnia tę potrzebę bez zaplanowanego zadania.

Jakość SBOM: Spełnianie TR-03183

Niemiecka wytyczna techniczna BSI TR-03183 rozszerza minimalne elementy NTIA. Chociaż nie jest prawnie wymagana w całej UE, przestrzeganie TR-03183 zapewnia wysoką jakość SBOM.

Wymagane Pola

Walidacja Jakości SBOM

Użyj tych narzędzi do sprawdzenia SBOM:

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

# Sprawdź minimalne pola za pomocą jq
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Zlicz komponenty z hashami
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

Poprawa Jakości SBOM

Jeśli SBOM ma braki w danych:

1. Używaj plików blokady: package-lock.json, Pipfile.lock, go.sum zawierają więcej metadanych
2. Skanuj zbudowane artefakty: Bardziej kompletne niż skanowanie samego źródła
3. Łącz narzędzia: Różne narzędzia znajdują różne komponenty
4. Dodawaj ręczne wpisy: Dla komponentów komercyjnych lub wewnętrznych

Utrzymywanie Aktualności SBOM

SBOM to migawka. Musi być aktualizowany, aby pozostać użyteczny.

Kiedy Regenerować

• Każde wydanie (major, minor, patch)
• Po aktualizacjach zależności
• Po poprawkach bezpieczeństwa
• Gdy zmienia się konfiguracja budowania

Strategia Wersjonowania

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

Lub używaj znaczników czasowych:

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

Przechowywanie

Retencja artefaktów CI (90 dni w powyższych przykładach) służy wygodzie programistów, nie zgodności. Wymóg 10 lat wymaga dedykowanego długoterminowego przechowywania. CRA Evidence jest do tego przeznaczony: wersjonowane przechowywanie SBOM ze skanowaniem podatności i eksportem dokumentacji technicznej, powiązanym z każdym wydaniem produktu.

W przypadku przechowywania we własnej infrastrukturze, każdy z głównych magazynów obiektów działa po włączeniu odpowiednich kontroli:

Sama polityka cyklu życia nie wystarczy. Magazyn musi obsługiwać wersjonowanie, kontrolę dostępu i najlepiej niezmienność, by spełnić wymagania audytowe.

Częste Pułapki

Jednorazowe generowanie SBOM

Problem: Utworzenie SBOM raz i nigdy go nie aktualizowanie.

Rozwiązanie: Zautomatyzuj generowanie SBOM w CI/CD. Każde budowanie powinno produkować świeży SBOM.

Brakujące zależności przechodnie

Problem: SBOM wymienia tylko bezpośrednie zależności, pomijając zagnieżdżone pakiety.

Rozwiązanie: Używaj plików blokady, skanuj zbudowane artefakty, włączaj opcje głębokiego skanowania.

Zła wersja formatu

Problem: Używanie CycloneDX 1.3, gdy TR-03183 zaleca 1.4+.

Rozwiązanie: Sprawdź wersję wyjściową narzędzia. Regularnie aktualizuj narzędzia.

Brak wartości hash

Problem: Komponenty bez hashów kryptograficznych nie mogą być zweryfikowane.

Rozwiązanie: Upewnij się, że narzędzie zawiera hashe. Syft i Trivy dodają hashe SHA-256, gdy mogą odczytać pliki komponentów.

Ręczne tworzenie

Problem: Ręczne tworzenie SBOM jest podatne na błędy i niemożliwe do utrzymania.

Rozwiązanie: Zawsze automatyzuj. Ręczne wpisy tylko dla komponentów, których narzędzia nie mogą wykryć.

Ignorowanie komponentów wewnętrznych

Problem: Dokumentowanie tylko zależności open-source, nie kodu własnościowego.

Rozwiązanie: Komponenty wewnętrzne też wymagają dokumentacji. Dodaj je ręcznie lub skonfiguruj odpowiednio narzędzia.

Lista Kontrolna Implementacji SBOM

Wymagania: Dowiedz się, czego CRA wymaga od SBOM w naszym przewodniku po wymaganiach SBOM.

Jakość: Zwaliduj SBOM zgodnie ze standardem BSI TR-03183.

VEX: Dodaj kontekst podatności do SBOM za pomocą dokumentów VEX.

Ten artykuł służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. W celu uzyskania konkretnych wskazówek dotyczących zgodności należy skonsultować się z wykwalifikowanym prawnikiem zaznajomionym z przepisami UE dotyczącymi produktów.