V roce 2026 o 131% více nahlášených CVE denně než loni.

Platforma

Jak CRACI funguje

CRACI spouští vaše buildy v GitHub Actions a zaznamenává, co každý z nich stáhne. Vše ostatní, od sledování zranitelností po důkazy pro CRA, stojí na tomto záznamu.

Aktualizováno

Přehled platformy CRACI. Zdrojový kód na GitHubu proudí přes GitHub Actions do CRACI Secure Build Service. Build zásobuje CRACI Package Analytics, dále Vulnerability Analysis (která přijímá i vstupy od externích dodavatelů), Digital Inventory a Compliance Reporting, který podává zprávy třetím stranám, jako jsou zákazníci, dodavatelé a ENISA. Build zásobuje také CRACI Attack Prevention. Attack Prevention i Digital Inventory vedou k nasazení do stagingu a produkce. Vulnerability Analysis navíc předává nálezy po triáži vašim týmům, které připraví opravu; opravené vydání se vrací přes GitHub, znovu se sestaví a je sledováno.
Platforma CRACI zleva doprava. Otevřít diagram v plné velikosti.

Ve zkratce

Většina bezpečnostních nástrojů zkoumá váš kód nebo manifesty dodatečně a odvozuje, co build pravděpodobně obsahoval. CRACI je build runner, takže vidí, co build skutečně stáhl, a to přesně v okamžiku stažení. Tento záznam je vstupem pro vše v diagramu: analytiku balíčků, prevenci útoků, analýzu zranitelností, dohledatelnost i reporting souladu.

GitHub i GitHub Actions vám zůstávají. Změna je jeden řádek v každém workflow:

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Krok za krokem

1. Zdrojový kód a CI/CD: GitHub a GitHub Actions

Váš kód zůstává na GitHubu. Organizaci připojíte instalací aplikace CRACI GitHub App, a to pro všechny repozitáře, nebo jen pro ty, které vyberete. Workflow se dál spouštějí z GitHub Actions a jejich běhy se dál zobrazují v GitHubu. GitHub Actions je dnes podporovanou integrací CI; podpora dalších systémů CI/CD je v plánu vývoje.

2. Build: CRACI Secure Build Service

Joby běží na runnerech CRACI v izolovaných virtuálních strojích. Runnery se škálují od 1 do 32 výpočetních jednotek (každá má 1 vCPU a 3 GB RAM), nativně na x86-64 i ARM64, s image Ubuntu kompatibilní s GitHubem nebo s odlehčenými image CRACI. Využití se účtuje po sekundách.

Buildy na CRACI běží přibližně dvakrát rychleji než na standardních runnerech hostovaných na GitHubu. Každá minuta navíc stojí méně: standardní runner Linux se 2 vCPU stojí $0.004 za minutu oproti $0.006 u GitHubu (asi o 33 % méně). Dohromady build, který na GitHubu trvá 10 minut, doběhne na CRACI zhruba za 5 minut a stojí asi o 67 % méně. CRACI navíc účtuje po sekundách, místo aby zaokrouhlovalo každý job nahoru na celou minutu, takže pipeline složené z mnoha krátkých jobů ušetří ještě víc. Prohlédněte si úplné srovnání s runnery hostovanými na GitHubu.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Odhalení dodavatelského řetězce: CRACI Package Analytics

Zatímco job běží, proxy, která rozumí balíčkům, sleduje provoz ke zdrojům balíčků a zaznamenává každou externí závislost, kterou build stáhne, napříč zdroji npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk a Git a také presety stahování pro Yocto a OpenEmbedded. Důkazy putují spolu s cache CI, takže i balíčky obnovené z cache jsou započteny.

V tom je rozdíl oproti jiným nástrojům SBOM. Ty čtou lockfile nebo výstup buildu a dovozují, co do něj vstoupilo. CRACI vidí provoz, takže zaznamená i skryté závislosti, které žádný lockfile neuvádí: kód, který stahují instalační hooky npm, soubory, které build skripty v Rustu stahují během buildu, a vrstvy základního image při buildu kontejneru.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

Každý job a každá cache dostanou stav úplnosti, od Complete po Not recorded, takže víte, nakolik můžete SBOM, kterou vytvořily, důvěřovat. SBOM se exportují ve formátu CycloneDX nebo SPDX, včetně tranzitivních závislostí.

4. Průběžná bezpečnost dodavatelského řetězce: CRACI Attack Prevention

Stejná vrstva, která provoz zaznamenává, ho také řídí. Politika odchozího provozu (egress policy) určuje, ke kterým hostitelům se job smí připojit, s výchozím zákazem nebo výchozím povolením, vestavěnými presety pro běžné zdroje softwaru a vlastními pravidly pro vaše zdroje. Politiky se ověřují před spuštěním jobu a při selhání vše zablokují (fail-closed) a CRACI vás na porušení upozorní. Kompromitovaná závislost nebo nástroj buildu, který se pokusí spojit se svým serverem, je zastaven na runneru.

Protože politika povoluje jen to, co build potřebuje, místo aby hledala známé škodlivé hostitele, funguje i proti útoku, který dosud nikdo neviděl. Pokud se červ jako Shai-Hulud dostane do vašeho buildu jako první, jeho pokus odeslat vaše tajné klíče ven je přesto zablokován.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Průběžná reakce v dodavatelském řetězci: CRACI Vulnerability Analysis

Zaznamenané balíčky se porovnávají se známými zranitelnostmi a monitorované SBOM se průběžně znovu vyhodnocují, takže se k vám dostane i zranitelnost zveřejněná až po vydání. Pohledy na úrovni organizace ukazují, které buildy a repozitáře sdílejí zranitelnou závislost, a bezpečnostní týmy mohou u každého nálezu provést triáž a předat ho týmu, který za opravu odpovídá. Můžete také přidat SBOM od svých externích dodavatelů, takže nakupované komponenty jsou monitorovány spolu s těmi, které stahují vaše vlastní buildy.

Using SBOMs for improved cybersecurity

Jak se SBOM z doby buildu po vydání mění v monitorování zranitelností, což je práce, kterou dělá generování SBOM a sledování zranitelností v CRACI.

Petteri Pulkkinen a Erika Marttinen na akci Kubernetes Community Days Helsinki 2026, od 22:11 do 23:27 záznamu SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Dohledatelnost v dodavatelském řetězci: CRACI Digital Inventory

Každý build má svou SBOM a síťový záznam toho, k čemu se připojil, a API CRACI vrací SBOM, síťové záznamy a původ (provenance). Když se v médiích objeví nová zranitelnost nebo kompromitovaný balíček, zjistíte na jednom místě, kterých vašich buildů se týká.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Reporting dodavatelského řetězce: CRACI Compliance Reporting

Důkazy shromážděné po cestě míří k těm, kdo o ně žádají: k zákazníkům, dodavatelům a úřadům. SBOM se exportují ve formátu CycloneDX nebo SPDX, včetně zranitelností nalezených v jejich komponentách, API vrací SBOM, síťové záznamy a původ (provenance) a CRACI připravuje obsah oznámení o zranitelnostech podle CRA, která pak podáte vy.

Cyber Resilience Act je nejznámějším předpisem, který za tím stojí, ale ne jediným. Napříč rámci je požadavek stejný: vědět, co je ve vašem softwaru, a mít proces pro vyhledávání a řešení jeho zranitelností.

  • EU Cyber Resilience Act: SBOM a řešení zranitelností u produktů s digitálními prvky prodávaných v EU, s ohlašovacími povinnostmi od září 2026.
  • NIS2: bezpečnost dodavatelského řetězce a řešení a zveřejňování zranitelností pro základní a důležité subjekty.
  • ISO/IEC 27001: SBOM výslovně nezmiňuje, ale opatření z přílohy A vyžadují inventář aktiv (5.9), bezpečnost v dodavatelském řetězci ICT (5.21) a správu technických zranitelností (8.8). SBOM z doby buildu a průběžné monitorování slouží jako důkaz pro všechna tři. Podívejte se na SBOM jako důkaz souladu.
  • US FDA: SBOM v podáních před uvedením na trh u připojených zdravotnických prostředků a plán monitorování a řešení zranitelností po vydání.
  • US Executive Order 14028: SBOM pro každý produkt a proces zveřejňování zranitelností v pokynech k softwarovému dodavatelskému řetězci pro dodavatele, kteří prodávají federální vládě.

CRACI vám dává SBOM a průběžné monitorování zranitelností, které tyto rámce očekávají, i důkazy, o které se opírají vaše tvrzení o souladu. Splnění každého rámce zůstává vaším procesem; CRACI z něj automatizuje část týkající se důkazů.

8. Nasazení: staging a produkce

Co se dostane do stagingu a produkce, bylo sestaveno podle vaší síťové politiky, se SBOM zaznamenanou během buildu a monitorovanou po vydání kvůli novým zranitelnostem.

Jděte do hloubky

Vyzkoušejte CRACI na vlastní pipeline

Rezervujte si demo a společně projdeme vaše buildy, vaše SBOM a vaše důkazy o souladu.

Rezervujte si demo