Nástroje a platformy pro bezpečnost softwarového dodavatelského řetězce (2026)

Pro koho je tato stránka

Máte za úkol „zabezpečit náš softwarový dodavatelský řetězec“ a potřebujete rozhodnout, kam půjde rozpočet. Níže uvedené nástroje fungují v různých bodech: napříč vašimi repozitáři a pipeline, na runneru buildu, v registru balíčků nebo na hotovém artefaktu. CRACI vyvíjíme my a v této kategorii přímo soutěžíme, berte to proto v úvahu. Každý nástroj popisujeme podle jeho vlastní dokumentace a říkáme, kde se lépe hodí jiný nástroj.

Co je bezpečnost softwarového dodavatelského řetězce?

Úplného průvodce najdete na stránce co je bezpečnost softwarového dodavatelského řetězce a v kontrolním seznamu osvědčených postupů.

Váš software je váš vlastní kód plus vše, na čem závisí: open source balíčky, základní image, nástroje pro build, actions CI od třetích stran a pipeline, která z nich vytvoří vydání. Bezpečnost softwarového dodavatelského řetězce znamená vědět, co tyto části jsou, kontrolovat, odkud pocházejí, a prokázat, co vstoupilo do každého vydání. Bezpečnost aplikací hledá chyby v kódu, který píšete; bezpečnost dodavatelského řetězce pokrývá to, co jej obklopuje.

Útočníci jdou po každém článku. Kde, ukazují tři nedávné incidenty:

• Závislost. V březnu 2024 byl nalezen škodlivý kód ve verzích 5.6.0 a 5.6.1 xz utils, kompresní knihovny dodávané v linuxových distribucích (CVE-2024-3094).
• Pipeline CI. V březnu 2025 byla kompromitována GitHub Action tj-actions/changed-files (CVE-2025-30066), čímž se odhalily tajné klíče, jako jsou přístupové klíče, osobní přístupové tokeny GitHubu a tokeny npm z workflow, která ji používala.
• Registr balíčků. V září 2025 sebereplikující červ Shai-Hulud kompromitoval více než 500 balíčků npm. Kradl přihlašovací údaje vývojářů, včetně tokenů GitHubu a cloudových klíčů, a používal je k publikování dalších infikovaných balíčků.

1:53

Jaké typy nástrojů pro bezpečnost softwarového dodavatelského řetězce existují?

Žádný jednotlivý produkt nepokryje každý článek a níže uvedení dodavatelé myslí „bezpečností dodavatelského řetězce“ různé věci. Většina řešení spadá do jednoho ze sedmi typů, které určuje to, kde fungují.

Jak vybrat platformu pro bezpečnost softwarového dodavatelského řetězce?

Začněte otázkou, na kterou dnes neumíte odpovědět, a pak vyberte nástroj, který funguje tam, kde odpověď leží. Šest otázek možnosti rychle rozliší.

• Potřebujete šíři, nebo hloubku? Platforma pro řízení stavu zabezpečení aplikací (ASPM) se připojí k vašim repozitářům, pipeline a skenerům a stanovuje priority rizik napříč nimi všemi. Nástroj na úrovni buildu jde hlouběji v jednom bodě: co se stalo během sestavování softwaru.
• Chcete si ponechat své runnery? Agenti jako StepSecurity Harden-Runner a Cimon od Cycode přidávají monitorování na runnery, které už používáte. CRACI runner pro GitHub Actions nahrazuje.
• Je riziko ve vašich vstupech? Pokud se nejvíc obáváte škodlivých balíčků nebo základních image plných CVE, nástroje, které vstupy prověřují nebo zabezpečují, míří přímo na to.
• Dodáváte software, který jste nesestavili? Pouze binární analýza dokáže nahlédnout do balíčku bez jeho buildu.
• Které systémy CI provozujete? Většina nástrojů zde jich pokrývá několik. CRACI dnes podporuje pouze GitHub Actions, GitLab CI a Jenkins jsou v plánu vývoje.
• Co budete muset prokázat a komu? Zákazníci, auditoři a předpisy, jako je EU Cyber Resilience Act, stále častěji žádají SBOM pro každé vydání a záznam o tom, jak byly zranitelnosti řešeny. Dashboard s nálezy není totéž co důkaz o tom, co bylo dodáno.

Pak položte každému dodavateli z užšího výběru stejné otázky:

• Odkud pochází váš seznam komponent: z manifestů, z analýzy zdrojového kódu, z buildu, nebo z hotové binárky?
• Řekne mi SBOM, když je neúplná, a exportuje se jako CycloneDX nebo SPDX?
• Dokážete buildu zabránit v přístupu k neočekávanému hostiteli, nebo to jen dodatečně nahlásíte?
• Mohu později ověřit, že artefakt, který nasazuji, je ten, který byl sestaven?
• Které systémy správy zdrojového kódu a CI podporujete dnes a které jsou v plánu vývoje?
• Jaká je jednotka ceny: vývojáři, přispěvatelé, image, buildy, nebo nabídka?

Jak si nástroje stojí ve srovnání?

Nástroje mají dvě podoby, proto jsou zde dvě tabulky. První srovnává platformy a nástroje pro bezpečnost buildů podle toho, jak vidí a řídí pipeline. Druhá srovnává nástroje, které pracují se vstupy a výstupy. „Neuvedeno“ znamená, že stránky dodavatelů, které citujeme, to neuvádějí ani v jednom smyslu.

Platformy a bezpečnost buildů

Vstupy a výstupy

Kolik stojí nástroje pro bezpečnost softwarového dodavatelského řetězce?

Pět z devíti níže uvedených nástrojů účtuje za vývojáře a většina prodává své placené plány přes obchodní oddělení. CRACI místo toho účtuje jen minuty buildu, takže cena se řídí tím, kolik sestavujete, ne tím, kolik lidí commituje. Ceny jsou uvedeny tak, jak je jednotliví dodavatelé zveřejnili v září 2026; Apiiro a Legit Security jsou vynechány, protože jejich stránky žádné ceny neuvádějí.

Cena za vývojáře roste s vaším týmem; cena za minuty buildu roste s vašimi pipeline. Cena CRACI zahrnuje minuty runneru, které nahrazují to, co platíte za runnery hostované na GitHubu. Viz ceník CRACI a srovnání cen runnerů. Grafy zveřejněných cen podle velikosti týmu, včetně runneru, najdete ve srovnání cen bezpečnosti softwarového dodavatelského řetězce.

CRACI

CRACI je runner pro GitHub Actions. Změníte runs-on na craci a během běhu každého jobu proxy, která rozumí balíčkům, zaznamenává, co job stáhl, včetně balíčků obnovených z cache CI. Každá SBOM nese stav úplnosti pro každý job a každou cache, egress policy se ověřuje před startem jobu a při selhání vše zablokuje a CRACI průběžně znovu vyhodnocuje SBOM toho, co bylo dodáno. Nejlépe se hodí pro týmy, které dodávají software a musí ukázat, co vstoupilo do každého vydání. Pozor: žádné skenování SAST, tajných klíčů ani IaC, kontroly zabezpečení ani binární analýza a dnes pouze GitHub Actions (GitLab CI a Jenkins jsou v plánu vývoje). Generování SBOM během buildu

Platformy a ASPM

Apiiro

Apiiro je platforma ASPM. Deep Code Analysis mapuje vaši architekturu od kódu až po runtime a Risk Graph koreluje nálezy z vlastních skenerů Apiiro a nástrojů třetích stran do „toxických kombinací“. Jeho modul pro dodavatelský řetězec inventarizuje repozitáře a pipeline, včetně stínových pipeline, a upozorňuje na slabou ochranu větví a neobvyklé commity. Připojuje se přes API a nevyžaduje žádné změny v CI. Nejlépe se hodí pro velké programy AppSec, které chtějí kontext architektury napříč mnoha systémy správy zdrojového kódu. Pozor: jeho inventář vychází z analýzy kódu, ne z pozorování buildů, a neřídí, kam se build dostane. CRACI vs Apiiro

Cycode

Cycode je platforma ASPM se skenováním SAST, SCA, tajných klíčů, kontejnerů a IaC, se stavem zabezpečení CI/CD a více než 100 konektory. Jeho část pro build, Cimon, je agent eBPF, který běží uvnitř vašich jobů CI. Monitoruje procesy, odchozí síťový provoz a přístup k souborům, naučí se běžné chování pipeline, než je začne vynucovat, vytváří SBOM pozorovanou za běhu a podepisuje původ SLSA. Cycode uvádí, že Cimon je zdarma a open source. Nejlépe se hodí pro jednu platformu napříč kódem a mnoha systémy CI s ochranou buildu za běhu na runnerech, které si ponecháte. Pozor: Cimon je agent přidaný na vaše runnery, ne samotný runner. CRACI vs Cycode

OX Security

OX Security je platforma ASPM s vlastními skenery, agregací nálezů třetích stran z nástrojů, jako jsou Checkmarx, Snyk a Black Duck, a politikami stavu zabezpečení CI/CD, které upozorňují na nepřipnuté actions, nadměrná oprávnění workflow a rizikové webhooky. Její Pipeline Bill of Materials (PBOM) je podepsaný záznam každého buildu s definicemi pipeline, identitou runneru, argumenty buildu a podpisy artefaktů. Nejlépe se hodí pro politiky stavu zabezpečení a blokování pull requestů napříč GitHub Actions, GitLabem, Jenkinsem, Azure Pipelines a CircleCI. Pozor: její SBOM se sbírá z připojených zdrojů a její politiky kontrolují konfiguraci pipeline, místo aby omezovaly, kam se běžící job dostane. CRACI vs OX Security a alternativy k OX Security

Legit Security

Legit Security mapuje celý váš životní cyklus vývoje: průběžně aktualizovaný inventář systémů SDLC, pipeline a bezpečnostních kontrol na nich, se stovkami politik napříč správou zdrojového kódu, CI a registry. Orchestruje skenery jako Snyk, Checkmarx a GitHub Advanced Security, přidává vlastní SAST a SCA, hledá tajné klíče v logách buildů, Slacku a Confluence i v kódu a vytváří SBOM a podepsané atestace. Nejlépe se hodí pro bezpečnostní tým, který zdědil mnoho repozitářů a několik systémů CI a potřebuje jednu vrstvu governance. Pozor: konfiguraci a výstupy skenerů čte přes API, takže nevidí síťový provoz jobu během jeho běhu. CRACI vs Legit Security a alternativy k Legit Security

Kusari

Kusari pochází od týmu, který spoluvytvořil GUAC, graf OpenSSF pro metadata dodavatelského řetězce. Jeho platforma staví ze SBOM, dokumentů VEX a výstupů skenerů znalostní graf, ukazuje dosah dopadu nové zranitelnosti, analyzuje dosažitelnost a otevírá pull requesty AutoFix, které nejprve ověří. Kusari Inspector reviduje pull requesty z hlediska škodlivých balíčků, tajných klíčů a nezabezpečených workflow a Kusari uvádí, že jeho instalace je zdarma. Nejlépe se hodí pro jeden graf napříč mnoha zdroji SBOM a skenery. Pozor: graf odráží SBOM, kterými je krmen, a ty u Kusari pocházejí z generátoru (jeho sady nástrojů waybill nebo vašeho vlastního nástroje), ne z buildu. CRACI vs Kusari a alternativy ke Kusari

Endor Labs

Endor Labs je postaven na dosažitelnosti na úrovni funkcí: statická analýza programu sleduje, zda váš kód může volat zranitelnou funkci v přímé nebo tranzitivní závislosti, což podle Endor Labs snižuje počet nálezů SCA o 92 %. Nápravu obstarávají analýza dopadu upgradu, automatizované pull requesty a Endor Patches, které backportují opravy do verze, kterou provozujete. Pokrývá také AI SAST, tajné klíče, kontejnery, Package Firewall před vašimi registry a SBOM Hub s VEX založeným na dosažitelnosti. Nejlépe se hodí pro týmy, jejichž hlavním problémem je množství upozornění. Pozor: jeho inventář vychází z analýzy zdrojového kódu a vaše buildy nespouští ani neomezuje. CRACI vs Endor Labs

Bezpečnost buildů a runnerů

StepSecurity

StepSecurity Harden-Runner se s CRACI překrývá nejvíc ze všech bezpečnostních dodavatelů. Je to agent na runnerech GitHub Actions, které už používáte, včetně runnerů hostovaných na GitHubu, a každé odchozí spojení, proces a zápis souboru přiřadí kroku workflow, který jej způsobil. Umí nejprve auditovat a vytvořit výchozí stav pro každý job a pak blokovat odchozí provoz ke všemu mimo allowlist. StepSecurity prodává také Secure Registry, pull requesty pro zabezpečení repozitářů a Dev Machine Guard. Nejlépe se hodí pro týmy, které si chtějí ponechat runnery hostované na GitHubu nebo vlastní (self-hosted) runnery, nebo které provozují GitLab CI či Azure DevOps. Pozor: jeho allowlist je seznam koncových bodů a zaznamenává cíle spojení, ne SBOM na úrovni balíčků. CRACI vs StepSecurity

Bezpečnost balíčků a vstupů

Socket

Socket analyzuje, jak se open source balíčky chovají: instalační skripty, přístup k síti a souborovému systému, obfuskovaný kód, známý malware a typosquatting. Upozorňuje na rizikové přírůstky v pull requestech a Socket Firewall blokuje škodlivé balíčky při instalaci, s bezplatnou verzí pro npm, yarn, pnpm, pip, uv a cargo. Nabízí také analýzu dosažitelnosti. Nejlépe se hodí pro zastavení špatných balíčků dříve, než se dostanou dovnitř, včetně těch, k nimž zatím neexistuje bezpečnostní upozornění. Pozor: čte manifesty a lockfily, které projekt deklaruje, a jeho firewall filtruje instalace balíčků, ne zbytek síťového provozu jobu. CRACI vs Socket

Chainguard

Chainguard sestavuje open source software ze zdrojového kódu a dodává jej zabezpečený: image kontejnerů, které označuje jako zero-CVE, knihovny pro Javu, Python a JavaScript znovu sestavené z ověřeného zdrojového kódu, image virtuálních strojů a zabezpečené GitHub Actions, každé s podepsanou SBOM a původem SLSA. Zákazníkům s objednávkou se zavazuje opravit kritické CVE do 7 dnů a ostatní závažnosti do 14 dnů od vydání kvalifikující opravy. Nejlépe se hodí pro týmy, jejichž skenery stále hlásí CVE v základních image. Pozor: jeho SBOM a původ popisují artefakty Chainguardu. Váš vlastní build stále potřebuje vlastní záznam, a proto se dobře kombinuje s nástrojem na úrovni buildu. CRACI a Chainguard

Binární analýza

ReversingLabs

ReversingLabs Spectra Assure analyzuje hotové softwarové balíčky bez zdrojového kódu pomocí statické binární analýzy, 16 enginů pro detekci malwaru a diferenciální analýzy, která upozorňuje na podezřelé změny mezi verzemi. Z binárky exportuje SBOM v CycloneDX a SPDX a dokáže posoudit komerční software a software třetích stran ještě před nasazením. Nejlépe se hodí pro kontrolu vydání proti malwaru a manipulaci a pro software, který jste nesestavili. Pozor: postupuje zpětně od výstupu, takže nevidí nástroje pro build ani testovací závislosti, které build stáhl, ale nedodal. CRACI vs ReversingLabs

Rámce a předpisy, které za kategorií stojí

Velká část poptávky po těchto nástrojích pochází z rámců a pravidel, která žádají inventář komponent, záznam o tom, jak byl software sestaven, a proces řešení zranitelností.

• SLSA (Supply-chain Levels for Software Artifacts) je sada postupně zaváděných pokynů, spravovaná jako mezioborová spolupráce pod Linux Foundation. Její Build track hodnotí, jak důvěryhodný je původ buildu.
• NIST SSDF (SP 800-218, verze 1.1, únor 2022) stanoví postupy bezpečného vývoje softwaru, které snižují zranitelnosti ve vydaném softwaru.
• US Executive Order 14028, oddíl 4(e), nařídil pokyny pro softwarový dodavatelský řetězec, které zahrnují předání SBOM kupujícímu ke každému produktu. Formuje pokyny pro federální zadávání zakázek, místo aby přímo zavazoval každého dodavatele.
• CISA, NSA a ODNI zveřejnily v roce 2023 dokument „Securing the Software Supply Chain: Recommended Practices Guide for Customers“, který pokrývá nákup, testování, nasazení, záplatování a SBOM.
• EU Cyber Resilience Act (nařízení (EU) 2024/2847) uvádí své oznamovací povinnosti v účinnost 11. září 2026 a plně se použije od 11. prosince 2027.
• NIS2 v článku 21(2) uvádí bezpečnost dodavatelského řetězce a řešení zranitelností mezi opatřeními, která vyžaduje, a americký FDA vyžaduje SBOM od výrobců kybernetických zařízení (cyber devices).

Žádný z těchto rámců nejmenuje kategorii produktů. Společné mají důkazy: přesný seznam komponent pro každé vydání, záznam o tom, jak bylo sestaveno, a doklad, že zranitelnosti byly sledovány.

Kam zapadá CRACI?

CRACI je runner pro GitHub Actions. Změníte runs-on na craci a během běhu každého jobu proxy, která rozumí balíčkům, zaznamenává, co job stáhl, včetně balíčků obnovených z cache CI. Každá SBOM nese stav úplnosti pro každý job a každou cache. Egress policy, s výchozím zákazem nebo výchozím povolením, se ověřuje před startem jobu a při selhání vše zablokuje. CRACI průběžně znovu vyhodnocuje SBOM toho, co bylo dodáno. Pohled inventáře v CRACI přesně ukazuje, které verze softwaru jsou nasazeny ve kterých produktech, a to globálně. Výsledkem je SBOM pro každý build, záznam toho, kam se každý build dostal, a data o původu z API, což automatizuje významnou část přehledu o dodavatelském řetězci a důkazů, které váš proces pro CRA potřebuje.

CRACI není správnou volbou, pokud potřebujete skenování SAST, tajných klíčů nebo IaC, kontroly zabezpečení napříč repozitáři, režim auditu před blokováním, blocklisty balíčků (v plánu vývoje), binární analýzu nebo dnes jiné systémy CI než GitHub Actions (GitLab CI a Jenkins jsou v plánu vývoje). Mnoho týmů jej kombinuje s některým z nástrojů výše: s platformou ASPM pro kód a stav zabezpečení, se Socketem nebo Chainguardem pro vstupy, s ReversingLabs pro výstup. Přečtěte si více o generování SBOM během buildu, integraci CI/CD a cenách, nebo si rezervujte demo a podívejte se na zaznamenaný build od začátku do konce.

Srovnání nástrojů pro jednotlivé části dodavatelského řetězce

Tato stránka je přehledem. Každá oblast má vlastní podrobnější srovnání a průvodce.

• SBOM: srovnání nástrojů SBOM, generování SBOM během buildu, proč SBOM z doby buildu a jak vygenerovat SBOM v GitHub Actions.
• Runnery a bezpečnost CI/CD: poskytovatelé runnerů GitHub Actions, nástroje pro bezpečnost runnerů, kontrolní seznam bezpečnosti CI/CD pipeline a egress policy pro GitHub Actions.
• Závislosti: srovnání nástrojů SCA, vysvětlení tranzitivních závislostí a co je analýza softwarového složení.
• Regulace: nástroje pro soulad s CRA.
• Proč build: proč bezpečnost dodavatelského řetězce patří do CI, bezpečnost softwarového dodavatelského řetězce s CRACI a proč ji potřebuje i interní a málo rizikový software.

CRACI ve srovnání s jednotlivými nástroji

• CRACI vs Apiiro Graf rizik z kódu vs důkazy z buildu.
• CRACI vs Cycode ASPM a agent buildu vs samotný runner buildu.
• CRACI vs OX Security PBOM z připojených nástrojů vs záznam z runneru.
• CRACI vs Legit Security Zabezpečení SDLC vs zaznamenání buildu.
• CRACI vs Kusari Graf dodavatelského řetězce vs SBOM z buildu s monitorováním.
• CRACI vs ReversingLabs Binární analýza výstupu vs důkazy z buildu.
• CRACI vs Socket Analýza chování balíčků vs pozorování buildu.
• CRACI vs Chainguard Bezpečné vstupy vs bezpečný, zaznamenaný build.
• CRACI vs Xygeni Platforma AppSec s atestacemi buildu vs být samotným runnerem buildu.
• CRACI vs Wiz Nálezy o stavu workflow vs vynucování přímo v jobu.
• CRACI vs Safeguard Skenování a automatické opravy pomocí AI vs zaznamenání samotného buildu.

Časté dotazy k bezpečnosti softwarového dodavatelského řetězce

Stručné odpovědi na otázky, které kupující kladou nejčastěji

Co jsou řešení pro bezpečnost softwarového dodavatelského řetězce?

Nástroje, které chrání vše, co do vašeho softwaru vstupuje mezi prvním commitem a vydáním: open source závislosti, základní image, nástroje pro build, pipeline CI a artefakty, které dodáváte. Hlavními typy jsou platformy ASPM, které mapují riziko napříč životním cyklem vývoje, analýza softwarového složení pro závislosti, bezpečnost buildů a runnerů, firewally balíčků, zabezpečené image, binární analýza a nástroje pro SBOM a původ.

Jaká je nejlepší platforma pro bezpečnost softwarového dodavatelského řetězce?

Jediná nejlepší neexistuje, protože každá pokrývá jiný článek. Platformy ASPM, jako jsou Apiiro, Cycode, OX Security a Legit Security, jsou nejsilnější v šíři napříč repozitáři a systémy CI. Endor Labs se zaměřuje na dosažitelnost u nálezů v závislostech, Socket na škodlivé balíčky, Chainguard na zabezpečené vstupy a ReversingLabs na hotové binárky. CRACI je volbou, když potřebujete záznam toho, co každý build v GitHub Actions skutečně stáhl, s kontrolou odchozího provozu a daty o původu.

Jak se bezpečnost softwarového dodavatelského řetězce liší od bezpečnosti aplikací?

Bezpečnost aplikací hledá chyby v kódu, který píše váš tým, pomocí nástrojů jako SAST a DAST. Bezpečnost softwarového dodavatelského řetězce pokrývá to, co tento kód obklopuje: komponenty třetích stran, build systém, pipeline CI a cestu od buildu k vydání. Backdoor v xz utils, kompromitace tj-actions/changed-files i npm červ Shai-Hulud přišly dodavatelským řetězcem, ne chybou ve vlastním kódu obětí.

Kterým nástrojem pro bezpečnost softwarového dodavatelského řetězce začít?

Začněte otázkou, na kterou dnes neumíte odpovědět. Pokud nevíte, které zranitelné závislosti dodáváte, začněte s SCA. Pokud vás nejvíc trápí škodlivé balíčky, podívejte se na firewall balíčků. Pokud musíte prokázat, co vstoupilo do každého vydání, zákazníkům nebo podle EU Cyber Resilience Act, potřebujete záznam pořízený během buildu. Velké programy s mnoha repozitáři a systémy CI k tomu často přidávají platformu ASPM.

Potřebuji pro bezpečnost softwarového dodavatelského řetězce SBOM?

Čím dál častěji ano. EU Cyber Resilience Act žádá po výrobcích, aby identifikovali komponenty ve svých produktech, mimo jiné vypracováním SBOM, a aby řešili jejich zranitelnosti. Americký FDA vyžaduje SBOM pro kybernetická zařízení (cyber devices) a americký Executive Order 14028 formoval federální pokyny, které ji po dodavatelích žádají. SBOM je užitečná jen natolik, nakolik je úplná, proto se každého dodavatele zeptejte, odkud pochází jeho seznam komponent a zda vám řekne, když je seznam neúplný.

Jak se CRACI liší od skeneru bezpečnosti dodavatelského řetězce?

Skenery čtou soubory dodatečně: manifest, lockfile, zdrojový kód nebo hotovou binárku. CRACI je záznamník. Je runnerem pro vaše joby GitHub Actions a během běhu každého jobu zaznamenává balíčky, které job skutečně stáhl, včetně balíčků obnovených z cache CI. Každá SBOM uvádí vlastní úplnost, egress policy řídí, kam se build dostane, a API vrací SBOM, síťové záznamy a data o původu.

Které systémy CI CRACI podporuje?

Dnes GitHub Actions; další systémy CI jsou v plánu vývoje, mezi nimi GitLab CI a Jenkins. Runnery běží na Linuxu na x86-64 a ARM64, Windows a macOS jsou v plánu vývoje. Většina platforem na této stránce pokrývá několik systémů CI, takže to zvažte, pokud provozujete také Jenkins nebo Azure Pipelines.

Kolik stojí nástroje pro bezpečnost softwarového dodavatelského řetězce?

Většina účtuje za vývojáře. K září 2026 stojí StepSecurity Enterprise $16 za přispívajícího vývojáře měsíčně a Socket Team $25 za vývojáře měsíčně, zatímco Cycode, OX Security a Endor Labs prodávají placené plány přes obchodní oddělení. ReversingLabs Community+ stojí paušálně $500 měsíčně, Chainguard nabízí až pět image zdarma a CRACI účtuje jen minuty buildu, $0.002 za vCPU-minutu ($0.004 za výchozí runner se 2 vCPU), bez měsíčního poplatku.