SBOM

Nazwa biblioteki lub modułu (np. log4j-core)

Dokładna wersja komponentu (np. 2.14.1)

Package URL (purl) — globalnie unikalny identyfikator

Licencja komponentu (Apache-2.0, MIT, GPL-3.0)

Dostawca / maintainer komponentu

SHA-256 lub SHA-512 dla weryfikacji integralności

Powiązania między komponentami (dependency graph)

Exploitability status dla znanych CVE

Co to jest SBOM (Software Bill of Materials)?

SBOM (Software Bill of Materials) to formalny, ustrukturyzowany zapis wszystkich komponentów oprogramowania — bibliotek, dependencji, modułów i ich relacji — które składają się na dany produkt software. Analogia: SBOM dla software to to samo co lista składników na opakowaniu żywności — wiesz dokładnie co jest w środku. Dlaczego SBOM jest kluczowy: incydent Log4Shell (CVE-2021-44228) pokazał że firmy nie wiedziały czy używają Log4j (często była 10+ poziomów głębiej w dependency tree). Bez SBOM — response na krytyczny CVE trwa tygodnie (musisz ręcznie sprawdzić każdy projekt). Z SBOM — w godzinę wiesz które produkty są dotknięte. Regulacje wymagające SBOM: US Executive Order 14028 (2021) — wymaga SBOM dla software dostarczanego do rządu US. EU Cyber Resilience Act — wymaga SBOM dla produktów z elementami cyfrowymi. FDA — wymaga SBOM dla medical devices. PCI DSS 4.0 — zaleca SBOM. Formaty SBOM: CycloneDX (OWASP) — bogaty w security context, popularny. SPDX (Linux Foundation) — standard ISO 5962. SWID Tags — starszy standard. CycloneDX i SPDX są dziś dominujące.

Jak generować SBOM i jakie narzędzia wybrać?

Generowanie SBOM — narzędzia: Syft (Anchore): open-source, generuje CycloneDX i SPDX z container images, filesystems, code directories. Wbudowany w Grype (vulnerability scanner). Komenda: syft alpine:latest -o cyclonedx-json. Trivy: open-source (Aqua Security), scanner który generuje SBOM jako efekt uboczny skanowania. Trivy sbom --format cyclonedx image:tag. cdxgen (OWASP): generuje CycloneDX dla wielu języków i package managers (npm, pip, Maven, Gradle, Go modules, Cargo). Microsoft SBOM Tool: open-source, cross-platform. Snyk: komercyjne, generuje SBOM jako część security analysis. Grype: vulnerability scanner który konsumuje SBOM (Syft output) i mapuje do CVE. Gdzie generować SBOM: W CI/CD pipeline po każdym build. Przy każdym container image build. Przechowuj w OCI Registry (OCI artifacts) lub dedykowanym SBOM store. Attestation: podpisuj SBOM kryptograficznie (cosign + Sigstore). Udostępnij klientom lub regulatorom jako artefakt. SBOM Consumption: gdy pojawi się nowy CVE — query SBOM store żeby znaleźć które produkty mają vulnerable component. Automatyczne alerting per product owner.

Software Supply Chain Security — co to jest i jak chronić?

Software Supply Chain Security: Ataki na software supply chain rosną — atakujący kompromitują nie produkt end-to-end ale jedno z narzędzi w łańcuchu budowania. Słynne ataki: SolarWinds (2020) — backdoor wstrzyknięty podczas build process. XZ Utils (2024) — backdoor wstrzyknięty do popularnej biblioteki kompresji Linux. event-stream npm (2018) — malicious code w popularnym npm package. Kategorie zagrożeń: Compromised dependencies (złośliwy kod w bibliotece). Typosquatting (złośliwe pakiety z podobnymi nazwami np. requsts zamiast requests). Account takeover developera (przejęcie konta maintainera npm/PyPI). Build system compromise (backdoor w CI/CD). Framework SLSA (Supply-chain Levels for Software Artifacts): L1: Build process jest scriptable i logged. L2: Signed provenance. L3: Source i build integrity. L4: Two-party review, hermetic build. Sigstore/cosign: bezpłatne narzędzie do podpisywania software artifacts. cosign sign my-image:tag → tworzy kryptograficzny podpis w OCI registry. cosign verify my-image:tag → weryfikuje podpis. Rekor: transparency log (public ledger) dla software signatures. SLSA + Sigstore + SBOM = kompletna supply chain security posture. Dependency pinning: pin wersje (nie latest), używaj lock files, weryfikuj checksums.

Vulnerability Management w Software Supply Chain?

Vulnerability Management: VEX (Vulnerability Exploitability eXchange): dokument towarzyszący SBOM który wyjaśnia czy CVE w komponencie jest exploitable w danym kontekście. Nie każdy CVE w SBOM jest rzeczywistym zagrożeniem. VEX stany: Affected, Not Affected (z uzasadnieniem), Fixed, Under Investigation. CVE Lifecycle: CVE Discovery → CVE Assignment (CNA) → NVD Publication → CVSS Score → Patch release → Deployment. SLAs dla vulnerability remediation: Critical (CVSS 9.0+): patch w 24-48h. High (7.0-8.9): patch w 7 dni. Medium (4.0-6.9): patch w 30 dni. Low (0.1-3.9): patch w 90 dni. Narzędzia do vulnerability scanning: Trivy — container i filesystem scan, szybki, open-source. Grype — SBOM-based scanner. Snyk — developer-friendly, IDE integration, komercyjne. OWASP Dependency-Check — Java/Maven/Gradle focus, open-source. Renovate / Dependabot: automatyczne PR-y gdy pojawiają się nowe wersje dependencies. Dependabot (GitHub native), Renovate (bardziej konfigurowalne). Policy Engine: OPA do definiowania polityki: 'nie możesz deployować jeśli masz CVE Critical nienaprawione'. Admission Controllers w Kubernetes blokują deployment.

Jak wdrożyć SBOM w organizacji — krok po kroku?

Wdrożenie SBOM w organizacji: Krok 1 — Wybierz format: CycloneDX (zalecany dla security use cases) lub SPDX (jeśli potrzebujesz ISO compliance). Krok 2 — Wdrożenie generowania: dodaj Syft lub cdxgen do CI/CD pipeline. Generuj SBOM dla każdego build (application + container image). Krok 3 — Przechowywanie: SBOM jako OCI artifact w registry (attach do image przez cosign attach sbom). SBOM w dedykowanym store (Dependency-Track, SW360). Krok 4 — Vulnerability scanning: Grype konsumuje SBOM → mapuje CVE → alerty. Dependency-Track — platforma do zarządzania SBOM i vulnerability tracking. Krok 5 — VEX workflow: analityk security ocenia CVE → tworzy VEX document → produkty oznaczone właściwie. Krok 6 — Attestation i signing: cosign + Sigstore podpisuje SBOM i image. Weryfikacja w deployment pipeline. Krok 7 — Customer distribution: udostępnij SBOM klientom (enterprise B2B wymaga tego coraz częściej). Dependency-Track jako SBOM management platforma: open-source (OWASP), przyjmuje CycloneDX i SPDX, zarządza CVE per komponent, dashboard per project, REST API do integracji. Maturity: Level 1 — SBOM generowany per build. Level 2 — SBOM signed i stored. Level 3 — SBOM used for vulnerability management. Level 4 — VEX + customer distribution.

Wyślij zapytanie