SBOM
Automatyzacja SBOM
Automatyzacja SBOM oznacza, że każdy build wytwarza własne zestawienie komponentów oprogramowania, a nikt nie przepisuje wersji do arkusza kalkulacyjnego. Jeśli Państwa zespół ręcznie mapuje komponenty w kilku produktach, lista dezaktualizuje się do następnego wydania, a pracy przybywa z każdym nowym produktem.
Zaktualizowano
Dlaczego ręczne SBOM-y przestają działać
- Dezaktualizują się przy następnym buildzie. Zależności zmieniają się z każdym wydaniem, a arkusz zmienia się tylko wtedy, gdy ktoś pamięta, by go zaktualizować.
- Kończą się na tym, co widać. Zależności bezpośrednie łatwo wypisać. Znajdujących się pod nimi zależności przechodnich już nie i nikt nie jest w stanie śledzić ich ręcznie.
- Mnożą się. Kilka produktów, każdy w kilku wspieranych wersjach, to dziesiątki plików, a każdy ma własnego właściciela i własną wersję prawdy.
- Nie odpowiadają na najważniejsze pytanie. Gdy pojawia się nowa podatność, trzeba wiedzieć, które wydania zawierają dany pakiet. Przeszukiwanie folderu z arkuszami trwa długo, a odpowiedzi nie można ufać.
- Nie są tym, czego oczekują inni. Klienci i narzędzia oczekują formatu czytelnego maszynowo, takiego jak CycloneDX lub SPDX. Zob. jak odpowiedzieć na prośbę klienta o SBOM.
Co robi dobra automatyzacja SBOM
- Wytwarza SBOM dla każdego buildu, tak że nikt nie musi niczego uruchamiać ani o niczym pamiętać.
- Obejmuje całe drzewo, łącznie z zależnościami przechodnimi, na każdym poziomie.
- Wiąże każdy SBOM z jednym buildem, dzięki czemu wiadomo, który plik opisuje które wydanie.
- Podaje, czego nie udało się zobaczyć, zamiast przedstawiać częściową listę jako pełną.
- Eksportuje standardowy format, dzięki czemu SBOM działa z kolejnym narzędziem i u kolejnego klienta.
- Nadal obserwuje to, co dostarczono, ponieważ wydanie, które w poniedziałek było czyste, we wtorek może być już narażone.
Trzy sposoby prowadzenia SBOM-ów w porównaniu
| Pytanie | Arkusz kalkulacyjny | Skaner w CI | Rejestrowanie w trakcie buildu |
|---|---|---|---|
| Kiedy jest aktualizowany? | Gdy ktoś sobie przypomni | Gdy uruchomi się krok skanowania | Przy każdym buildzie |
| Skąd pochodzą dane? | Od ludzi | Z lockfile lub gotowego wyniku buildu | Z tego, co build faktycznie pobrał |
| Zależności przechodnie? | Rzadko | Te, które potrafi ustalić | Na każdym poziomie |
| Ukryte zależności, np. pobierane przez skrypty instalacyjne? | Nie | Pomijane | Rejestrowane |
| Pakiety przywrócone z cache CI? | Nie | Zależy od narzędzia | Rejestrowane i oznaczane jako pochodzące z cache |
| Monitorowanie podatności? | Ręczne | Zwykle osobne narzędzie | Wbudowane w CRACI |
Automatyzacja za pomocą skanera to realna poprawa w stosunku do arkusza, ale skaner nadal zgaduje, co trafiło do buildu. Uzasadnienie przedstawia tekst dlaczego build jest źródłem prawdy.
Co dzieje się z Państwa arkuszami
Dane o komponentach przestają być w nich potrzebne: wersje i pakiety pochodzą z buildu, więc nikt nie musi ich wpisywać. Zostaje wiedza, którą ma tylko Państwa zespół, na przykład jakie produkty istnieją, kto jest ich właścicielem i które wersje są nadal wspierane. Właśnie tej części warto poświęcać czas ludzi.
Jak robi to CRACI
CRACI zastępuje runnery hostowane przez GitHub szybszymi i tańszymi oraz rejestruje SBOM w trakcie każdego buildu.
Ustawiają Państwo runs-on: craci, a uruchomienia nadal widać w GitHub. Standardowe buildy otrzymują
kompletny SBOM bez konfiguracji. Buildy z własnymi rejestrami pakietów lub nietypowymi konfiguracjami kontenerów mogą
wymagać pewnej konfiguracji.
- Rejestrowany, a nie skanowany. CRACI widzi ruch wchodzący do każdego buildu, w tym ukryte zależności, które pomijają narzędzia oparte na lockfile. Każdy komponent w SBOM rzeczywiście był w buildzie.
- Stan kompletności dla każdego zadania, dzięki czemu wiadomo, kiedy buildu nie udało się w pełni zarejestrować i dlaczego.
- Eksport do CycloneDX i SPDX, łącznie z zależnościami przechodnimi i podatnościami znalezionymi w komponentach.
- Jeden widok wszystkich produktów. Widok inwentarza pokazuje, które wersje oprogramowania są wdrożone w których produktach, a CRACI na bieżąco ponownie ocenia monitorowane SBOM-y.
Jak wdrożyć to w zespołach z różnymi pipeline'ami, zob. generowanie SBOM w zespołach inżynierskich.
Automatyzacja SBOM: najczęściej zadawane pytania
Czym jest automatyzacja SBOM?
To wytwarzanie zestawienia komponentów oprogramowania jako części buildu, tak aby każde wydanie miało je bez ręcznego tworzenia. Lepsze rozwiązania monitorują też każdy SBOM pod kątem nowych podatności po wydaniu.
Czy możemy prowadzić SBOM-y w Excelu?
Arkusz może posłużyć jako pierwszy inwentarz, ale trudno utrzymać go w aktualności i nie obejmuje zależności przechodnich. Nie jest też standardowym formatem SBOM. Klienci i narzędzia bezpieczeństwa zazwyczaj oczekują CycloneDX lub SPDX, a Cyber Resilience Act wymaga powszechnie stosowanego formatu czytelnego maszynowo.
Czy automatyzacja SBOM wymaga nowego kroku w każdym pipeline?
W przypadku większości generatorów tak: trzeba dodać krok do każdego workflow i utrzymywać go w aktualności. CRACI rejestruje SBOM w runnerze, więc do zadań nie trzeba dodawać żadnego kroku.
Jakie ekosystemy rejestruje CRACI?
npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, pakiety Debiana i Ubuntu (apt), pakiety Alpine (apk) i źródła Git, a także pobrania Yocto i OpenEmbedded. Obsługa Maven i Javy jest w planach rozwoju.
Jakie systemy CI i platformy obsługuje CRACI?
Dziś GitHub Actions; inne systemy CI są w planach rozwoju. Runnery działają dziś na Linuksie x86-64 i ARM64, a Windows i macOS są w planach rozwoju.
Co z komponentami kupowanymi od dostawców?
Do CRACI można dodawać SBOM-y dostawców, dzięki czemu kupowane komponenty są monitorowane razem z Państwa własnymi buildami.
Ile to kosztuje?
CRACI pobiera opłaty wyłącznie za minuty buildu: $0.002 za vCPU-minutę ($0.004 za domyślny runner z 2 vCPU), naliczane co sekundę, bez opłaty miesięcznej i bez opłat za SBOM.
Następny build zamiast arkusza
Proszę zobaczyć zarejestrowany SBOM ze stanem kompletności dla buildu, który Państwo już uruchamiają. Proszę umówić demo, a przeprowadzimy Państwa przez niego.
Umów demo