Narzędzia i platformy bezpieczeństwa łańcucha dostaw oprogramowania (2026)

Dla kogo jest ta strona

Odpowiadają Państwo za zadanie „zabezpieczyć nasz łańcuch dostaw oprogramowania” i muszą zdecydować, na co przeznaczyć budżet. Poniższe narzędzia działają w różnych punktach: w repozytoriach i pipeline'ach, na runnerze buildu, w rejestrze pakietów lub na gotowym artefakcie. Tworzymy CRACI, który bezpośrednio konkuruje w tej kategorii, dlatego proszę wziąć to pod uwagę. Każde narzędzie opisujemy na podstawie jego własnej dokumentacji i mówimy, gdzie inne narzędzie sprawdza się lepiej.

Czym jest bezpieczeństwo łańcucha dostaw oprogramowania?

Pełny przewodnik znajdą Państwo na stronie czym jest bezpieczeństwo łańcucha dostaw oprogramowania, a także w checkliście dobrych praktyk.

Państwa oprogramowanie to Państwa własny kod i wszystko, od czego zależy: pakiety open source, obrazy bazowe, narzędzia buildu, zewnętrzne akcje CI i pipeline, który zamienia je w wydanie. Bezpieczeństwo łańcucha dostaw oprogramowania to praca polegająca na tym, by wiedzieć, czym są te części, kontrolować, skąd pochodzą, i udowadniać, co trafiło do każdego wydania. Bezpieczeństwo aplikacji szuka błędów w pisanym przez Państwa kodzie; bezpieczeństwo łańcucha dostaw obejmuje to, co go otacza.

Napastnicy atakują każde ogniwo. Trzy niedawne incydenty pokazują, gdzie uderzają:

• Zależność. W marcu 2024 r. znaleziono złośliwy kod w wersjach 5.6.0 i 5.6.1 xz utils, biblioteki kompresji dostarczanej w dystrybucjach Linuksa (CVE-2024-3094).
• Pipeline CI. W marcu 2025 r. przejęto akcję GitHub tj-actions/changed-files (CVE-2025-30066), co ujawniło sekrety, takie jak klucze dostępu, osobiste tokeny dostępu GitHub i tokeny npm, z korzystających z niej workflow.
• Rejestr pakietów. We wrześniu 2025 r. samoreplikujący się robak Shai-Hulud przejął ponad 500 pakietów npm. Kradł poświadczenia programistów, w tym tokeny GitHub i klucze chmurowe, i używał ich do publikowania kolejnych zainfekowanych pakietów.

1:53

Jakie są rodzaje narzędzi bezpieczeństwa łańcucha dostaw oprogramowania?

Żaden pojedynczy produkt nie obejmuje każdego ogniwa, a wymienieni niżej dostawcy rozumieją przez „bezpieczeństwo łańcucha dostaw” różne rzeczy. Większość rozwiązań należy do jednego z siedmiu typów, określonych przez miejsce działania.

Jak wybrać platformę bezpieczeństwa łańcucha dostaw oprogramowania?

Należy zacząć od pytania, na które dziś nie potrafią Państwo odpowiedzieć, a następnie wybrać narzędzie działające tam, gdzie ta odpowiedź się znajduje. Sześć pytań pozwala szybko rozróżnić opcje.

• Czy potrzebują Państwo szerokości, czy głębokości? Platforma zarządzania stanem bezpieczeństwa aplikacji (ASPM) łączy się z repozytoriami, pipeline'ami i skanerami oraz priorytetyzuje ryzyko we wszystkich z nich. Narzędzie na poziomie buildu sięga głębiej w jednym punkcie: co wydarzyło się podczas budowania oprogramowania.
• Czy chcą Państwo zachować swoje runnery? Agenty, takie jak StepSecurity Harden-Runner i Cimon firmy Cycode, dodają monitorowanie do używanych już runnerów. CRACI zastępuje runner dla GitHub Actions.
• Czy ryzyko leży we wejściach? Jeśli najbardziej niepokoją Państwa złośliwe pakiety lub obrazy bazowe pełne CVE, narzędzia weryfikujące lub utwardzające wejścia trafiają w sedno.
• Czy dostarczają Państwo oprogramowanie, którego nie zbudowali? Tylko analiza binarna może zajrzeć do pakietu bez jego buildu.
• Jakich systemów CI Państwo używają? Większość opisanych tu narzędzi obejmuje kilka. CRACI obsługuje dziś tylko GitHub Actions, a GitLab CI i Jenkins są w planach rozwoju.
• Co i komu będą Państwo musieli udowodnić? Klienci, audytorzy i regulacje, takie jak unijny Cyber Resilience Act, coraz częściej wymagają SBOM dla każdego wydania i zapisu tego, jak obsłużono podatności. Panel znalezisk to nie to samo co dowód tego, co dostarczono.

Następnie każdemu dostawcy z krótkiej listy warto zadać te same pytania:

• Skąd pochodzi lista komponentów: z manifestów, analizy kodu źródłowego, buildu czy gotowego pliku binarnego?
• Czy SBOM informuje, gdy jest niekompletny, i czy eksportuje się jako CycloneDX lub SPDX?
• Czy można powstrzymać build przed połączeniem z nieoczekiwanym hostem, czy tylko zgłosić to później?
• Czy mogę później zweryfikować, że wdrażany artefakt to ten, który zbudowano?
• Jakie systemy kontroli wersji i CI są obsługiwane dziś, a jakie są w planach rozwoju?
• Jaka jest jednostka cenowa: programiści, współtwórcy, obrazy, buildy czy wycena indywidualna?

Jak wypadają narzędzia w porównaniu?

Narzędzia dzielą się na dwie grupy, dlatego są dwie tabele. Pierwsza porównuje platformy i narzędzia bezpieczeństwa buildu pod kątem tego, jak widzą i kontrolują pipeline. Druga porównuje narzędzia działające na wejściach i wyjściach. „Nie podano” oznacza, że cytowane przez nas strony dostawców nie rozstrzygają tej kwestii.

Platformy i bezpieczeństwo buildu

Wejścia i wyjścia

Ile kosztują narzędzia bezpieczeństwa łańcucha dostaw oprogramowania?

Pięć z dziewięciu poniższych narzędzi wycenia się za programistę, a większość sprzedaje płatne plany przez dział sprzedaży. CRACI pobiera natomiast opłaty tylko za minuty buildu, więc koszt zależy od tego, ile Państwo budują, a nie od liczby osób wykonujących commity. Ceny podano tak, jak opublikowali je dostawcy we wrześniu 2026; Apiiro i Legit Security pominięto, ponieważ ich strony nie podają cen.

Ceny za programistę rosną wraz z zespołem; ceny za minutę buildu rosną wraz z pipeline'ami. Cena CRACI obejmuje minuty runnerów, które zastępują to, co Państwo płacą za runnery hostowane przez GitHub. Zob. cennik CRACI oraz porównanie cen runnerów. Wykresy opublikowanych cen według wielkości zespołu, z uwzględnieniem runnera, przedstawia strona porównanie cen bezpieczeństwa łańcucha dostaw oprogramowania.

CRACI

CRACI to runner dla GitHub Actions. Wystarczy zmienić runs-on na craci, a podczas działania każdego zadania proxy rozpoznające pakiety rejestruje to, co zadanie pobrało, łącznie z pakietami przywróconymi z cache CI. Każdy SBOM ma stan kompletności dla zadania i cache, polityka ruchu wychodzącego jest walidowana przed uruchomieniem zadania i w razie błędu blokuje ruch, a CRACI na bieżąco ponownie ocenia SBOM-y dostarczonego oprogramowania. Najlepsze dla zespołów, które dostarczają oprogramowanie i muszą pokazać, co trafiło do każdego wydania. Uwaga: brak SAST, skanowania sekretów i IaC, kontroli stanu bezpieczeństwa oraz analizy binarnej, a dziś tylko GitHub Actions (GitLab CI i Jenkins są w planach rozwoju). Generowanie SBOM w czasie buildu

Platformy i ASPM

Apiiro

Apiiro to platforma ASPM. Deep Code Analysis mapuje Państwa architekturę od kodu po środowisko uruchomieniowe, a Risk Graph koreluje znaleziska z własnych skanerów Apiiro i narzędzi zewnętrznych w „toxic combinations”. Moduł łańcucha dostaw inwentaryzuje repozytoria i pipeline'y, w tym tzw. shadow pipelines, oraz oznacza słabą ochronę gałęzi i nietypowe commity. Łączy się przez API i nie wymaga zmian w CI. Najlepsze dla dużych programów AppSec, które chcą kontekstu architektury w wielu systemach kontroli wersji. Uwaga: jego inwentarz pochodzi z analizy kodu, a nie z obserwacji buildów, i nie kontroluje on, do czego build ma dostęp. CRACI vs Apiiro

Cycode

Cycode to platforma ASPM ze skanowaniem SAST, SCA, sekretów, kontenerów i IaC, kontrolą stanu bezpieczeństwa CI/CD i ponad 100 konektorami. Jej element dotyczący buildu, Cimon, to agent eBPF działający w Państwa zadaniach CI. Monitoruje procesy, ruch wychodzący i dostęp do plików, uczy się normalnego zachowania pipeline'u przed rozpoczęciem egzekwowania, tworzy SBOM obserwowany w czasie działania i podpisuje dane o pochodzeniu SLSA. Cycode twierdzi, że Cimon jest bezpłatny i open source. Najlepsze dla jednej platformy obejmującej kod i wiele systemów CI, z ochroną buildu w czasie działania na zachowanych runnerach. Uwaga: Cimon to agent dodawany do Państwa runnerów, a nie sam runner. CRACI vs Cycode

OX Security

OX Security to platforma ASPM z własnymi skanerami, agregacją znalezisk z narzędzi zewnętrznych, takich jak Checkmarx, Snyk i Black Duck, oraz politykami stanu bezpieczeństwa CI/CD, które oznaczają nieprzypięte akcje, nadmierne uprawnienia workflow i ryzykowne webhooki. Jej Pipeline Bill of Materials (PBOM) to podpisany zapis dla każdego buildu, obejmujący definicje pipeline'u, tożsamość runnera, argumenty buildu i podpisy artefaktów. Najlepsze dla polityk stanu bezpieczeństwa i bramek pull requestów w GitHub Actions, GitLab, Jenkins, Azure Pipelines i CircleCI. Uwaga: jej SBOM jest zbierany z podłączonych źródeł, a polityki sprawdzają konfigurację pipeline'u, zamiast ograniczać, do czego ma dostęp działające zadanie. CRACI vs OX Security oraz alternatywy dla OX Security

Legit Security

Legit Security mapuje cały cykl wytwarzania: stale aktualizowany inwentarz systemów SDLC, pipeline'ów i obejmujących je kontroli bezpieczeństwa, z setkami polityk dla kontroli wersji, CI i rejestrów. Orkiestruje skanery, takie jak Snyk, Checkmarx i GitHub Advanced Security, dodaje natywne SAST i SCA, znajduje sekrety w logach buildu, Slacku i Confluence, a także w kodzie, oraz tworzy SBOM-y i podpisane poświadczenia. Najlepsze dla zespołu bezpieczeństwa, który odziedziczył wiele repozytoriów i kilka systemów CI i potrzebuje jednej warstwy nadzoru. Uwaga: odczytuje konfigurację i wyniki skanerów przez API, więc nie widzi ruchu sieciowego zadania podczas jego działania. CRACI vs Legit Security oraz alternatywy dla Legit Security

Kusari

Kusari pochodzi od zespołu, który współtworzył GUAC, graf OpenSSF dla metadanych łańcucha dostaw. Jego platforma buduje graf wiedzy z Państwa SBOM-ów, dokumentów VEX i wyników skanerów, pokazuje zasięg skutków nowej podatności, analizuje osiągalność i otwiera pull requesty AutoFix, które najpierw waliduje. Kusari Inspector przegląda pull requesty pod kątem złośliwych pakietów, sekretów i niebezpiecznych workflow, a Kusari twierdzi, że jego instalacja jest bezpłatna. Najlepsze dla jednego grafu obejmującego wiele źródeł SBOM i skanerów. Uwaga: graf odzwierciedla SBOM-y, którymi jest zasilany, a SBOM-y Kusari pochodzą z generatora (jego zestawu narzędzi waybill lub Państwa własnego narzędzia), a nie z buildu. CRACI vs Kusari oraz alternatywy dla Kusari

Endor Labs

Endor Labs koncentruje się na osiągalności na poziomie funkcji: statyczna analiza programu śledzi, czy Państwa kod może wywołać podatną funkcję w zależności bezpośredniej lub przechodniej, co według Endor Labs ogranicza znaleziska SCA o 92%. Analiza wpływu aktualizacji, automatyczne pull requesty i Endor Patches, przenoszące poprawki do używanej wersji, obsługują naprawę. Obejmuje też AI SAST, sekrety, kontenery, Package Firewall przed Państwa rejestrami oraz SBOM Hub z VEX opartym na osiągalności. Najlepsze dla zespołów, których głównym problemem jest liczba alertów. Uwaga: jego inwentarz pochodzi z analizy kodu źródłowego i nie uruchamia on ani nie ogranicza Państwa buildów. CRACI vs Endor Labs

Bezpieczeństwo buildu i runnerów

StepSecurity

StepSecurity Harden-Runner to produkt, z którym CRACI pokrywa się najbardziej spośród wszystkich dostawców bezpieczeństwa. To agent na używanych już przez Państwa runnerach GitHub Actions, także hostowanych przez GitHub, który wiąże każde połączenie wychodzące, proces i zapis pliku z krokiem workflow, który je spowodował. Może najpierw prowadzić audyt, budując punkt odniesienia dla każdego zadania, a następnie blokować ruch wychodzący do wszystkiego spoza listy dozwolonych celów. StepSecurity sprzedaje też Secure Registry, pull requesty utwardzające repozytoria i Dev Machine Guard. Najlepsze dla zespołów, które chcą zachować runnery hostowane przez GitHub lub self-hosted albo używają GitLab CI lub Azure DevOps. Uwaga: jego lista dozwolonych celów to lista punktów końcowych, a rejestruje on miejsca docelowe, nie SBOM na poziomie pakietów. CRACI vs StepSecurity

Bezpieczeństwo pakietów i wejść

Socket

Socket analizuje zachowanie pakietów open source: skrypty instalacyjne, dostęp do sieci i systemu plików, zaciemniony kod, znane złośliwe oprogramowanie i typosquaty. Oznacza ryzykowne dodatki w pull requestach, a Socket Firewall blokuje złośliwe pakiety w czasie instalacji, z bezpłatną wersją dla npm, yarn, pnpm, pip, uv i cargo. Oferuje też analizę osiągalności. Najlepsze do zatrzymywania złych pakietów, zanim trafią do projektu, także tych, które nie mają jeszcze biuletynu bezpieczeństwa. Uwaga: odczytuje manifest i lockfile zadeklarowane przez projekt, a jego firewall filtruje instalacje pakietów, a nie resztę ruchu sieciowego zadania. CRACI vs Socket

Chainguard

Chainguard buduje oprogramowanie open source ze źródeł i dostarcza je w utwardzonej postaci: obrazy kontenerów, które nazywa zero-CVE, biblioteki Java, Python i JavaScript przebudowane ze zweryfikowanych źródeł, obrazy VM i utwardzone GitHub Actions, każde z podpisanym SBOM i danymi o pochodzeniu SLSA. Wobec klientów z zamówieniem zobowiązuje się do naprawy krytycznych CVE w ciągu 7 dni, a CVE o innej ważności w ciągu 14 dni od kwalifikującej się poprawki. Najlepsze dla zespołów, których skanery wciąż oznaczają CVE w obrazach bazowych. Uwaga: jego SBOM-y i dane o pochodzeniu opisują artefakty Chainguard. Państwa własny build nadal potrzebuje własnego zapisu, dlatego dobrze łączy się z narzędziem na poziomie buildu. CRACI i Chainguard

Analiza binarna

ReversingLabs

ReversingLabs Spectra Assure analizuje gotowe pakiety oprogramowania bez kodu źródłowego, stosując statyczną analizę binarną, 16 silników wykrywania złośliwego oprogramowania i analizę różnicową, która oznacza podejrzane zmiany między wersjami. Eksportuje SBOM-y CycloneDX i SPDX z pliku binarnego i może oceniać oprogramowanie komercyjne i zewnętrzne przed wdrożeniem. Najlepsze jako bramka wydania chroniąca przed złośliwym oprogramowaniem i manipulacją oraz dla oprogramowania, którego Państwo nie zbudowali. Uwaga: działa wstecz od wyniku, więc nie widzi narzędzi buildu ani zależności testowych, które build pobrał, ale nie dostarczył. CRACI vs ReversingLabs

Frameworki i regulacje stojące za tą kategorią

Duża część popytu na te narzędzia wynika z frameworków i przepisów, które wymagają inwentarza komponentów, zapisu sposobu zbudowania oprogramowania i procesu obsługi podatności.

• SLSA (Supply-chain Levels for Software Artifacts) to zestaw wytycznych, które można wdrażać stopniowo, utrzymywany jako współpraca międzybranżowa pod egidą Linux Foundation. Jego ścieżka Build ocenia wiarygodność danych o pochodzeniu buildu.
• NIST SSDF (SP 800-218, wersja 1.1, luty 2022) określa praktyki bezpiecznego wytwarzania oprogramowania, ograniczające podatności w wydanym oprogramowaniu.
• Amerykańskie rozporządzenie wykonawcze 14028, sekcja 4(e), nakazało opracowanie wytycznych dla łańcucha dostaw oprogramowania, które obejmują przekazanie nabywcy SBOM każdego produktu. Kształtuje federalne wytyczne zakupowe, a nie wiąże bezpośrednio każdego dostawcy.
• CISA, NSA i ODNI opublikowały w 2023 r. „Securing the Software Supply Chain: Recommended Practices Guide for Customers”, obejmujący zakupy, testowanie, wdrażanie, łatanie i SBOM-y.
• Unijny Cyber Resilience Act (rozporządzenie (UE) 2024/2847) wprowadza obowiązki raportowania w życie 11 września 2026 r. i obowiązuje w pełni od 11 grudnia 2027 r.
• NIS2 w art. 21 ust. 2 wymienia bezpieczeństwo łańcucha dostaw i obsługę podatności wśród wymaganych środków, a amerykańska FDA wymaga SBOM od producentów wyrobów cybernetycznych.

Żaden z tych frameworków nie wymienia kategorii produktu. Łączy je dowód: dokładna lista komponentów dla każdego wydania, zapis sposobu zbudowania i potwierdzenie, że podatności były śledzone.

Gdzie pasuje CRACI?

CRACI to runner dla GitHub Actions. Wystarczy zmienić runs-on na craci, a podczas działania każdego zadania proxy rozpoznające pakiety rejestruje to, co zadanie pobrało, łącznie z pakietami przywróconymi z cache CI. Każdy SBOM ma stan kompletności dla zadania i cache. Polityka ruchu wychodzącego, z domyślną odmową lub domyślnym zezwoleniem, jest walidowana przed uruchomieniem zadania i w razie błędu blokuje ruch. CRACI na bieżąco ponownie ocenia SBOM-y dostarczonego oprogramowania. Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Wynikiem jest SBOM dla każdego buildu, zapis tego, z czym łączył się każdy build, oraz dane o pochodzeniu z API, co automatyzuje znaczną część widoczności łańcucha dostaw i dowodów potrzebnych w Państwa procesie CRA.

CRACI nie jest właściwym wyborem, jeśli potrzebują Państwo SAST, skanowania sekretów lub IaC, kontroli stanu bezpieczeństwa w repozytoriach, trybu audytu przed blokowaniem, list blokowanych pakietów (w planach rozwoju), analizy binarnej lub, już dziś, systemów CI innych niż GitHub Actions (GitLab CI i Jenkins są w planach rozwoju). Wiele zespołów łączy go z jednym z powyższych narzędzi: platformą ASPM dla kodu i stanu zabezpieczeń, Socket lub Chainguard dla wejść, ReversingLabs dla wyjścia. Więcej o generowaniu SBOM w czasie buildu, integracji CI/CD i cenach. Mogą Państwo też umówić demo, aby zobaczyć zarejestrowany build od początku do końca.

Porównanie narzędzi dla każdej części łańcucha dostaw

Ta strona to przegląd. Każdy obszar ma własne, bardziej szczegółowe porównanie i przewodniki.

• SBOM-y: porównanie narzędzi SBOM, generowanie SBOM w czasie buildu, dlaczego SBOM-y z czasu buildu oraz jak wygenerować SBOM w GitHub Actions.
• Runnery i bezpieczeństwo CI/CD: dostawcy runnerów GitHub Actions, narzędzia bezpieczeństwa runnerów, checklista bezpieczeństwa pipeline'u CI/CD oraz polityka ruchu wychodzącego dla GitHub Actions.
• Zależności: porównanie narzędzi SCA, wyjaśnienie zależności przechodnich oraz czym jest analiza składu oprogramowania.
• Regulacje: narzędzia do zgodności z CRA.
• Dlaczego build: dlaczego bezpieczeństwo łańcucha dostaw należy do CI, bezpieczeństwo łańcucha dostaw oprogramowania z CRACI oraz dlaczego potrzebuje go także oprogramowanie wewnętrzne i niskiego ryzyka.

CRACI w porównaniu z każdym narzędziem

• CRACI kontra Apiiro Graf ryzyka z kodu kontra dowody z buildu.
• CRACI kontra Cycode ASPM z agentem buildu kontra sam runner buildu.
• CRACI kontra OX Security PBOM z podłączonych narzędzi kontra zapis z runnera.
• CRACI kontra Legit Security Zabezpieczanie SDLC kontra rejestrowanie buildu.
• CRACI kontra Kusari Graf łańcucha dostaw kontra SBOM-y z buildu z monitorowaniem.
• CRACI kontra ReversingLabs Analiza binarna wyniku kontra dowody z buildu.
• CRACI kontra Socket Analiza zachowania pakietów kontra obserwacja buildu.
• CRACI kontra Chainguard Bezpieczne dane wejściowe kontra bezpieczny, zarejestrowany build.
• CRACI kontra Xygeni Platforma AppSec z atestacjami buildu kontra bycie runnerem buildu.
• CRACI kontra Wiz Znaleziska dotyczące konfiguracji workflow kontra egzekwowanie wewnątrz zadania.
• CRACI kontra Safeguard Skanowanie i automatyczne poprawki AI kontra rejestrowanie samego buildu.

Bezpieczeństwo łańcucha dostaw oprogramowania: FAQ

Krótkie odpowiedzi na pytania, które kupujący zadają najczęściej

Czym są rozwiązania bezpieczeństwa łańcucha dostaw oprogramowania?

To narzędzia chroniące wszystko, co trafia do Państwa oprogramowania między pierwszym commitem a wydaniem: zależności open source, obrazy bazowe, narzędzia buildu, pipeline'y CI i dostarczane artefakty. Główne typy to platformy ASPM mapujące ryzyko w całym cyklu wytwarzania, analiza składu oprogramowania dla zależności, bezpieczeństwo buildu i runnerów, firewalle pakietów, utwardzone obrazy, analiza binarna oraz narzędzia SBOM i pochodzenia.

Jaka jest najlepsza platforma bezpieczeństwa łańcucha dostaw oprogramowania?

Nie ma jednej najlepszej, ponieważ każda obejmuje inne ogniwo. Platformy ASPM, takie jak Apiiro, Cycode, OX Security i Legit Security, są najmocniejsze pod względem szerokości pokrycia repozytoriów i systemów CI. Endor Labs koncentruje się na osiągalności znalezisk w zależnościach, Socket na złośliwych pakietach, Chainguard na utwardzonych wejściach, a ReversingLabs na gotowych plikach binarnych. CRACI to wybór, gdy potrzebują Państwo zapisu tego, co każdy build GitHub Actions faktycznie pobrał, z kontrolą ruchu wychodzącego i danymi o pochodzeniu.

Czym bezpieczeństwo łańcucha dostaw oprogramowania różni się od bezpieczeństwa aplikacji?

Bezpieczeństwo aplikacji szuka błędów w kodzie pisanym przez Państwa zespół, za pomocą narzędzi takich jak SAST i DAST. Bezpieczeństwo łańcucha dostaw oprogramowania obejmuje to, co otacza ten kod: komponenty zewnętrzne, system buildu, pipeline CI i drogę od buildu do wydania. Tylna furtka w xz utils, przejęcie tj-actions/changed-files i robak npm Shai-Hulud weszły przez łańcuch dostaw, a nie przez błąd we własnym kodzie ofiar.

Od jakiego narzędzia bezpieczeństwa łańcucha dostaw oprogramowania zacząć?

Należy zacząć od pytania, na które dziś nie potrafią Państwo odpowiedzieć. Jeśli nie wiedzą Państwo, jakie podatne zależności dostarczają, należy zacząć od SCA. Jeśli najbardziej niepokoją Państwa złośliwe pakiety, warto przyjrzeć się firewallowi pakietów. Jeśli muszą Państwo udowodnić, co trafiło do każdego wydania, klientom lub na potrzeby unijnego Cyber Resilience Act, potrzebny jest zapis wykonany podczas buildu. Duże programy z wieloma repozytoriami i systemami CI często dodają do tego platformę ASPM.

Czy SBOM jest potrzebny do bezpieczeństwa łańcucha dostaw oprogramowania?

Coraz częściej tak. Unijny Cyber Resilience Act wymaga od producentów identyfikowania komponentów w ich produktach, w tym przez sporządzenie SBOM, oraz obsługi ich podatności. Amerykańska FDA wymaga SBOM dla wyrobów cybernetycznych, a amerykańskie rozporządzenie wykonawcze 14028 ukształtowało federalne wytyczne, które wymagają go od dostawców. SBOM jest użyteczny tylko w takim stopniu, w jakim jest kompletny, dlatego każdego dostawcę należy zapytać, skąd pochodzi jego lista komponentów i czy informuje on, gdy lista jest niekompletna.

Czym CRACI różni się od skanera bezpieczeństwa łańcucha dostaw?

Skanery odczytują pliki po fakcie: manifest, lockfile, kod źródłowy lub gotowy plik binarny. CRACI rejestruje. Jest runnerem Państwa zadań GitHub Actions i podczas działania każdego zadania zapisuje pakiety faktycznie przez nie pobrane, łącznie z pakietami przywróconymi z cache CI. Każdy SBOM określa własną kompletność, polityka ruchu wychodzącego kontroluje, do czego build ma dostęp, a API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu.

Jakie systemy CI obsługuje CRACI?

Dziś GitHub Actions; inne systemy CI są w planach rozwoju, w tym GitLab CI i Jenkins. Runnery działają na Linuksie na x86-64 i ARM64, a Windows i macOS są w planach rozwoju. Większość platform na tej stronie obejmuje kilka systemów CI, dlatego warto to uwzględnić, jeśli używają Państwo także Jenkinsa lub Azure Pipelines.

Ile kosztują narzędzia bezpieczeństwa łańcucha dostaw oprogramowania?

Większość pobiera opłaty za programistę. Według stanu na wrzesień 2026 StepSecurity Enterprise kosztuje $16 za programistę wnoszącego wkład miesięcznie, a Socket Team $25 za programistę miesięcznie, natomiast Cycode, OX Security i Endor Labs sprzedają płatne plany przez dział sprzedaży. ReversingLabs Community+ to stała opłata $500 miesięcznie, Chainguard oferuje do pięciu obrazów bezpłatnie, a CRACI pobiera opłaty tylko za minuty buildu, $0.002 za minutę vCPU ($0.004 za domyślny runner 2 vCPU), bez opłaty miesięcznej.