Jak Wygenerować SBOM Zgodny z CRA: Narzędzia, Formaty i Integracja CI/CD

CRA wymaga Software Bill of Materials. Każdy artykuł konkurencji ci to powie. Żaden nie pokaże, 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:

"identyfikacji i dokumentowania podatności oraz komponentów zawartych w produkcie, w tym poprzez sporządzenie zestawienia materiałów oprogramowania w powszechnie używanym i czytelnym maszynowo formacie"

Kluczowe punkty:

• Format czytelny maszynowo: Nie PDF, nie arkusz kalkulacyjny , 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.

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 (standard ISO/IEC 5962:2021) 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.

Integracja CI/CD

Ręczne generowanie SBOM nie skaluje się. Zintegruj je z pipeline'em budowania.

GitHub Actions

name: SBOM Generation

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

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

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

      - name: Generate SBOM
        run: |
          syft dir:. -o cyclonedx-json > sbom.cdx.json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json
          retention-days: 90

      # Opcjonalnie: Prześlij do CRA Evidence
      - name: Upload to CRA Evidence
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://app.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"]

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 swojego 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 twój 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

CRA wymaga 10-letniego przechowywania. Przechowuj historyczne SBOM:

• W repozytorium artefaktów
• W S3/chmurze z politykami cyklu życia
• W CRA Evidence dla zintegrowanego śledzenia zgodności

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ą swojego 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 twoje narzędzie zawiera hashe. Skanuj zbudowane artefakty, a nie tylko źródło.

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

LISTA KONTROLNA IMPLEMENTACJI SBOM

WYBÓR FORMATU:
[ ] Wybrany CycloneDX 1.4+ lub SPDX 2.3+
[ ] Format JSON (czytelny maszynowo)
[ ] Decyzja udokumentowana

NARZĘDZIA:
[ ] Wybrane główne narzędzie (Syft/Trivy/cdxgen)
[ ] Narzędzie zainstalowane i przetestowane lokalnie
[ ] Wyjście zwalidowane względem schematu

INTEGRACJA CI/CD:
[ ] Generowanie SBOM dodane do pipeline'u budowania
[ ] Artefakty przechowywane z odpowiednim czasem retencji
[ ] Generowanie wyzwalane przy wydaniach

ZAPEWNIENIE JAKOŚCI:
[ ] Wszystkie komponenty mają: nazwę, wersję, dostawcę
[ ] Wartości hash obecne (SHA-256+)
[ ] Informacje o licencji zawarte
[ ] Zależności przechodnie przechwycone
[ ] Identyfikatory PURL użyte

OPERACJE:
[ ] SBOM wersjonowany wraz z wydaniami produktu
[ ] Historyczne SBOM zarchiwizowane (10-letnia retencja)
[ ] Proces udokumentowany dla zespołu

OPCJONALNIE - INTEGRACJA CRA EVIDENCE:
[ ] Token API skonfigurowany
[ ] Przesyłanie zautomatyzowane przy wydaniu
[ ] Scoring jakości włączony

Następne Kroki

Z zautomatyzowanym generowaniem SBOM jesteś gotowy na:

1. Skanowanie podatności: Połącz SBOM z bazami danych podatności
2. Zgodność licencyjna: Analizuj zobowiązania licencyjne
3. Integrację z dokumentacją techniczną: Włącz SBOM do dokumentacji CRA
4. Przygotowanie do raportowania ENISA: SBOM umożliwiają szybką identyfikację podatności

CRA Evidence automatyzuje cały ten workflow:

• Przesyłaj SBOM przez CLI lub CI/CD
• Automatyczne skanowanie podatności z Trivy
• Scoring jakości TR-03183
• Eksport dokumentacji technicznej ze zintegrowanymi SBOM

Zacznij generować zgodne SBOM na app.craevidence.com.

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

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

VEX: Dodaj kontekst podatności do swojego 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, skonsultuj się z wykwalifikowanym prawnikiem zaznajomionym z przepisami UE dotyczącymi produktów.