O 124% więcej zgłoszonych CVE dziennie w 2026 niż przed rokiem.

Platforma

Jak działa CRACI

CRACI uruchamia Państwa buildy GitHub Actions i rejestruje, co każdy z nich pobiera. Wszystko inne, od śledzenia podatności po dowody zgodności z CRA, opiera się na tym zapisie.

Zaktualizowano

Przegląd platformy CRACI. Kod źródłowy w GitHub przepływa przez GitHub Actions do CRACI Secure Build Service. Build zasila CRACI Package Analytics, a następnie Vulnerability Analysis (która otrzymuje też dane od zewnętrznych dostawców), Digital Inventory i Compliance Reporting, które raportuje do stron trzecich, takich jak klienci, dostawcy i ENISA. Build zasila także CRACI Attack Prevention. Attack Prevention i Digital Inventory prowadzą do wdrożenia na środowisko stagingowe i produkcyjne.
Platforma CRACI, od lewej do prawej. Otwórz diagram w pełnym rozmiarze.

W skrócie

Większość narzędzi bezpieczeństwa analizuje kod lub manifesty po fakcie i wnioskuje, co build prawdopodobnie zawierał. CRACI jest runnerem buildu, więc widzi, co build faktycznie pobrał, w chwili pobrania. Ten zapis jest punktem wyjścia dla wszystkiego na diagramie: analizy pakietów, ochrony przed atakami, analizy podatności, identyfikowalności i raportowania zgodności.

Zachowują Państwo GitHub i GitHub Actions. Zmiana to jedna linia w każdym 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 po kroku

1. Kod źródłowy i CI/CD: GitHub i GitHub Actions

Państwa kod pozostaje w GitHub. Organizację łączy się, instalując CRACI GitHub App dla wszystkich repozytoriów lub tylko wybranych. Workflow nadal działają w GitHub Actions, a ich uruchomienia są widoczne w GitHub. Obecnie obsługiwaną integracją CI jest GitHub Actions; obsługa innych systemów CI/CD jest w planach rozwoju.

2. Build: CRACI Secure Build Service

Zadania działają na runnerach CRACI w odizolowanych maszynach wirtualnych. Runnery skalują się od 1 do 32 jednostek obliczeniowych (każda to 1 vCPU i 3 GB RAM), natywnie na x86-64 i ARM64, z obrazem Ubuntu zgodnym z GitHub lub odchudzonymi obrazami CRACI. Zużycie jest naliczane co sekundę.

Buildy na CRACI działają mniej więcej dwa razy szybciej niż na standardowych runnerach hostowanych przez GitHub. Każda minuta jest też tańsza: standardowy runner Linux z 2 vCPU kosztuje $0.004 za minutę wobec $0.006 w GitHub (około 33% mniej). Łącznie build, który w GitHub trwa 10 minut, na CRACI kończy się w około 5 minut i kosztuje około 67% mniej. CRACI rozlicza też co sekundę, zamiast zaokrąglać każde zadanie w górę do pełnej minuty, więc pipeline'y złożone z wielu krótkich zadań oszczędzają jeszcze więcej. Pełne porównanie z runnerami hostowanymi przez GitHub.

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. Wykrywanie łańcucha dostaw: CRACI Package Analytics

W trakcie zadania proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów i rejestruje każdą zewnętrzną zależność pobieraną przez build, z npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także z presetów pobierania Yocto i OpenEmbedded. Dowody przenoszone są razem z cache CI, więc pakiety przywrócone z cache również są uwzględnione.

Na tym polega różnica w stosunku do innych narzędzi SBOM. Odczytują one lockfile lub wynik buildu i wnioskują, co do niego trafiło. CRACI widzi ruch, więc rejestruje też ukryte zależności, których nie wymienia żaden lockfile: kod pobierany przez hooki instalacyjne npm, pliki pobierane przez skrypty buildu Rust w czasie buildu oraz warstwy obrazu bazowego w buildzie kontenera.

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żde zadanie i każdy cache otrzymują stan kompletności, od Complete do Not recorded, więc wiedzą Państwo, na ile można ufać wygenerowanemu SBOM. SBOM-y eksportuje się w formacie CycloneDX lub SPDX, łącznie z zależnościami przechodnimi.

4. Ciągłe bezpieczeństwo łańcucha dostaw: CRACI Attack Prevention

Ta sama warstwa, która rejestruje ruch, także go kontroluje. Polityka ruchu wychodzącego określa, z którymi hostami zadanie może się łączyć: domyślnie blokuj lub domyślnie zezwalaj, z wbudowanymi presetami dla popularnych źródeł oprogramowania i własnymi regułami dla Państwa źródeł. Polityki są weryfikowane przed startem zadania i w razie problemu blokują ruch (fail closed), a CRACI powiadamia o naruszeniach. Przejęta zależność lub narzędzie buildu, które próbuje połączyć się ze swoim serwerem, zostaje zatrzymane na runnerze.

Ponieważ polityka dopuszcza tylko to, czego build potrzebuje, zamiast szukać znanych złośliwych hostów, działa także przeciw atakowi, którego nikt wcześniej nie widział. Jeśli robak taki jak Shai-Hulud jako pierwszy dotrze do Państwa buildu, jego próba wysłania Państwa sekretów na zewnątrz i tak zostanie zablokowana.

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. Ciągła reakcja w łańcuchu dostaw: CRACI Vulnerability Analysis

Zarejestrowane pakiety są dopasowywane do znanych podatności, a monitorowane SBOM-y są stale ponownie oceniane, więc podatność ujawniona po wydaniu nadal do Państwa dotrze. Widoki na poziomie organizacji pokazują, które buildy i repozytoria mają wspólną podatną zależność, a zespoły bezpieczeństwa mogą przeanalizować każde znalezisko i przekazać je zespołowi odpowiedzialnemu za poprawkę. Mogą Państwo też dodać SBOM-y od zewnętrznych dostawców, aby kupowane komponenty były monitorowane razem z tymi, które pobierają Państwa własne buildy.

Using SBOMs for improved cybersecurity

Jak SBOM z czasu buildu zamienia się w monitorowanie podatności po wydaniu, czyli zadanie, które wykonują generowanie SBOM i śledzenie podatności w CRACI.

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

6. Śledzenie łańcucha dostaw: CRACI Digital Inventory

Każdy build ma swój SBOM i ślad sieciowy połączeń, a API CRACI zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. Gdy o nowej podatności lub przejętym pakiecie zaczyna być głośno, w jednym miejscu sprawdzą Państwo, których buildów to dotyczy.

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. Raportowanie łańcucha dostaw: CRACI Compliance Reporting

Dowody zebrane po drodze trafiają do tych, którzy o nie pytają: klientów, dostawców i organów. SBOM-y eksportuje się w formacie CycloneDX lub SPDX, łącznie z podatnościami znalezionymi w ich komponentach, API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu, a CRACI składa w Państwa imieniu zgłoszenia podatności wymagane przez CRA.

Cyber Resilience Act to najbardziej znany przepis, który za tym stoi, ale nie jedyny. We wszystkich ramach regulacyjnych wymóg jest ten sam: wiedzieć, co jest w oprogramowaniu, i mieć proces wykrywania i obsługi jego podatności.

  • EU Cyber Resilience Act: SBOM i obsługa podatności dla produktów z elementami cyfrowymi sprzedawanych w UE, z obowiązkami zgłaszania od września 2026.
  • NIS2: bezpieczeństwo łańcucha dostaw oraz obsługa i ujawnianie podatności dla podmiotów kluczowych i ważnych.
  • ISO/IEC 27001: nie wymienia SBOM, ale jej zabezpieczenia z załącznika A wymagają inwentaryzacji aktywów (5.9), bezpieczeństwa w łańcuchu dostaw ICT (5.21) i zarządzania podatnościami technicznymi (8.8). SBOM-y z czasu buildu i ciągłe monitorowanie są dowodem dla wszystkich trzech.
  • US FDA: SBOM we wnioskach przed wprowadzeniem do obrotu dla podłączonych wyrobów medycznych oraz plan monitorowania i usuwania podatności po wydaniu.
  • US Executive Order 14028: SBOM-y dla każdego produktu i proces ujawniania podatności w wytycznych dotyczących łańcucha dostaw oprogramowania dla dostawców sprzedających rządowi federalnemu.

CRACI zapewnia SBOM-y i ciągłe monitorowanie podatności, których oczekują te ramy, a także dowody na poparcie Państwa deklaracji zgodności. Spełnienie wymogów każdej z ram pozostaje Państwa procesem; CRACI sprawia, że część tego procesu związana z dowodami dzieje się automatycznie.

8. Wdrożenie: staging i produkcja

To, co trafia na staging i produkcję, zostało zbudowane zgodnie z Państwa polityką sieciową, z SBOM zarejestrowanym w trakcie buildu i monitorowanym po wydaniu pod kątem nowych podatności.

Więcej szczegółów

CRACI w Państwa własnym pipeline

Prosimy umówić demo, a wspólnie przejdziemy przez Państwa buildy, SBOM-y i dowody zgodności.

Umów demo