Automatyczna cyberodporność dla programistów i agentów

Niech każdy build będzie pierwszą linią obrony.

Bezpieczeństwo łańcucha dostaw w samym sercu Państwa oprogramowania dzięki szybkim, niezawodnym i tańszym runnerom.

Uruchom pierwszy build Zobacz, jak to działa

Bezpieczne runnery
SBOM-y z czasu buildu
Monitorowanie podatności
Reagowanie na podatności

Zarejestrowane pakiety: 185
Odrzucone połączenia: 6
SBOM kompletny
Naprawione w v2.4.1

Build

northwind-controls/web-portal

release.yml #1843 · 5d08e3b
runs-on: craci
size 2 · x86-64
Pakiety
Zarejestrowane pakiety: 185
- next 15.2.2
- react 19.0.0
- react-dom 19.0.0
- express 4.21.2
- tailwindcss 4.0.14
- typescript 5.8.2
Bramka polityki

Build #1843 zatrzymany
CVE-2025-29927 · Critical
Build #1844 przeszedł
Naprawione w next 15.2.3
Wydany artefakt

ghcr.io/northwind-controls/web-portal:2.4.1

sha256:e2b9…5c07
Wydany jako v2.4.1

Zespoły, które budują z CRACI

Podatności pojawiają się szybciej niż poprawki.

Atakującym wystarczy jedna droga do środka, a agenci pomagają im znaleźć ją szybciej niż kiedykolwiek. Państwa zespół musi zamknąć każdą lukę, głównie ręcznie.

2026 do tej pory

CVE publikowanych dziennie: 293; Średnio jeden co 5 min.
Więcej dziennie niż rok wcześniej: +124%; W porównaniu z dzienną liczbą z 2025.
Ocenionych jako High lub Critical, każdego dnia: 148; Na podstawie ocen CVSS.

CVE publikowane dziennie, według roku
Rok	CVE dziennie	High lub Critical dziennie
2020	39	7
2021	54	12
2022	68	20
2023	78	28
2024	109	48
2025	131	54
2026 do tej pory	293	148

Z publicznej listy CVE, odświeżanej codziennie. Proszę wybrać rok do porównania. Czytaj raport o CVE

Dlaczego teraz

Alerty stały się szumem.
Gdy setki znalezisk są pilne, żadne z nich nie jest. Zespoły przestają zarządzać ryzykiem i zaczynają liczyć alerty.
Skala przerasta każdy zespół.
Analiza i poprawki wciąż odbywają się ręcznie. Przy takiej skali zatrudnianie kolejnych osób nie zamyka luki.
Poprawki konkurują z funkcjami.
Zespoły produktowe są rozliczane z dostarczania funkcji, więc prace nad bezpieczeństwem czekają na spokojny sprint, który nigdy nie nadchodzi.
Skanery tylko szacują.
Lista odtworzona z plików po buildzie pomija to, co faktycznie do niego trafiło, a fałszywe poczucie pewności sprawia, że nikt nie sprawdza dalej.

Państwa oprogramowanie nabiera kształtu w trakcie buildu.

Lockfile przypina to, co powinno zostać zainstalowane. To build decyduje, co faktycznie trafia do środka. CRACI rejestruje każdy pakiet w chwili, gdy się pojawia, wraz z rozwiązaną wersją, źródłem i informacją, czy został przywrócony z cache CI.

package-lock.json Co Państwo przypięli

"packages": {
  …
  
  
  
  
  
  …
}

Zawiera tylko wersje, bez informacji, skąd pochodzi każdy pakiet i jak trafił do buildu.

Zapis buildu #1842 Zarejestrowane pakiety: 185

Pakiety zarejestrowane podczas przykładowego buildu #1842 repozytorium northwind-controls/web-portal, pogrupowane według drogi, którą trafiły do buildu.
Pakiet	Rozwiązana wersja	Droga	Źródło
Przez package.json
express przez package.json	4.21.2	package.json	registry.npmjs.org
next przez package.json Teraz dotknięty przez CVE-2025-29927 · Critical	15.2.2	package.json	registry.npmjs.org
react przez package.json · z cache CI	19.0.0	package.json	Cache CI
react-dom przez package.json · z cache CI	19.0.0	package.json	Cache CI
styled-jsx przez next	5.1.6	next	registry.npmjs.org
Przez skrypt buildu
tailwindcss przez skrypt buildu	4.0.14	skrypt buildu	registry.npmjs.org
typescript przez skrypt buildu	5.8.2	skrypt buildu	registry.npmjs.org
i jeszcze zarejestrowane pakiety: 178

Zarejestrowane pakiety: 185 · przywrócone z cache: 2

Bezpieczny build. Zarejestrowane zależności.

Państwa zadania działają na runnerach CRACI zamiast na runnerach hostowanych przez GitHub, dwa razy szybciej. Każdy pobierany pakiet jest rejestrowany z wersją, źródłem i licencją. Wszystko, co pochodzi ze źródła spoza Państwa polityki, zostaje odrzucone.

Secure Build Service

Każde zadanie działa we własnej, odizolowanej maszynie wirtualnej, za polityką ruchu wychodzącego sprawdzaną przed startem zadania.

Izolowana VM
Ruch wychodzący domyślnie blokowany
Blokada w razie awarii
Alert przy naruszeniu

Package Analytics

Proxy rozpoznające pakiety rejestruje każdy pakiet pobierany przez zadanie, z rozwiązaną wersją, źródłem i deklarowaną licencją.

npm
PyPI
RubyGems
Cargo
Go
Nix
OCI
Yocto
i więcej

Zdarzenie polityki Build #1842

time2025-03-14 09:13:07 UTC
jobrelease.yml #1842
stepnpm run build
policyDefault deny. Allowed: npm, GitHub, ghcr.io, Docker Hub, example.com
denied malicious.example:443
reasonHosta nie ma w polityce
actionZablokowano na runnerze

Połączenie odrzucone. Alert wysłany.

Graf zależności v2.4.0

Fragment SBOM CycloneDX 1.7 · JSON

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  …
  "components": [{
    "name": "next",
    "version": "15.2.2",
    "purl": "pkg:npm/[email protected]",
    "licenses": [
      { "license": { "id": "MIT" } }
    ]
  }, …]
}

Eksport w formacie CycloneDX lub SPDX, łącznie z zależnościami przechodnimi i podatnościami.

CRACI widzi ruch, którego skanery nie widzą.

Inne narzędzia SBOM odczytują lockfile lub wynik buildu i zgadują, co do niego trafiło. CRACI widzi, co faktycznie wchodzi do każdego buildu, łącznie z ukrytymi zależnościami pobieranymi przez hooki w czasie buildu, skrypty buildu i obrazy bazowe.

Skaner

Skaner konkurencji

Metoda: Odczytuje package-lock.json
Kiedy: Po buildzie
Co widzi: To, co wymienia lockfile

SBOM, który skaner tworzy z lockfile przykładowego buildu #1842.
Pakiet	Wersja	Licencja	Znaleziono w
next pkg:npm/[email protected]	15.2.2	MIT	package-lock.json
react pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
react-dom pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
express pkg:npm/[email protected]	4.21.2	MIT	package-lock.json
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	package-lock.json
Nie ma w żadnym lockfile, więc nie ma w SBOM
Nie ma w żadnym lockfile, więc nie ma w SBOM
Nie ma w żadnym lockfile, więc nie ma w SBOM

Wymienione pakiety: 142 Brakuje: 43

Zarejestrowany SBOM

Metoda: Widzi ruch buildu
Kiedy: W trakcie buildu
Co widzi: To, co build pobrał

SBOM, który CRACI rejestruje z ruchu przykładowego buildu #1842.
Pakiet	Wersja	Licencja	Pobrano z
next pkg:npm/[email protected]	15.2.2	MIT	registry.npmjs.org
react pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
react-dom pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
express pkg:npm/[email protected]	4.21.2	MIT	registry.npmjs.org
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	registry.npmjs.org
gotowy plik binarny ukryte przez hook postinstall · pkg:npm/hidden-package	—	—	registry.npmjs.org
2 pobrania skryptu buildu ukryte przez skrypt buildu · pkg:generic/[email protected]?download_url=example.com/tool	—	—	example.com
40 pakietów systemowych obrazu bazowego ukryte przez Dockerfile FROM · pkg:oci/ubuntu	—	—	registry.hub.docker.com

Zarejestrowane pakiety: 185 O 43 więcej, niż pokazuje lockfile

Przykładowy build. Jak działają SBOM-y z czasu buildu

Wskazanie potencjalnych podatności co do konkretnego wydania.

CRACI stale sprawdza zarejestrowane SBOM-y pod kątem nowych podatności. W tym poglądowym przykładzie krytyczna podatność zostaje ujawniona 7 dni po wydaniu. Proszę prześledzić zapis buildu od dotkniętego pakietu do poprawki zespołu.

Krok 1 z 4

Ujawniono CVE-2025-29927

next to zależność bezpośrednia, a build #1842 zarejestrował dokładną wersję.

Ważność: Critical 9.1
Pakiet: next
Dotknięte: od 15.0.0 do 15.2.2
Naprawione w: 15.2.3

Krok 2 z 4

Dotyczy to jednego wydania

CRACI dopasowuje podatność do zarejestrowanego SBOM.

Wydanie: web-portal v2.4.0
Dopasowanie: next 15.2.2, zależność bezpośrednia
SBOM: Complete

Krok 3 z 4

Wydanie dostarczono jako ten obraz

Wydanie, jego obraz i jego SBOM pozostają razem.

Obraz: ghcr.io/northwind-controls/web-portal:2.4.0
Wydanie: v2.4.0
SBOM: Śledzone

Krok 4 z 4

Poprawka ma właściciela

Analiza, przekazanie i śledzenie aż do wydania z poprawką.

Właściciel: Zespół platformy
Działanie: Zaktualizować next do 15.2.3 i przebudować
Naprawione w: web-portal v2.4.1, 2025-03-22

Odpowiedź dla każdego audytora, poparta dowodami.

Każdy build zostawia dowody: SBOM-y, zapisy podatności i informację, jak każda poprawka trafiła do wydania. Mogą je Państwo wykorzystać w procesach CRA, NIS2, ISO 27001 i SOC 2, tak by pytanie audytora wymagało jednego pobrania, a nie całego projektu.

Skład: SBOM z czasu buildu dla każdego wydania.

CycloneDX
SPDX
Zależności przechodnie
Podatności
Deklarowane licencje
Obsługa podatności: Zarejestrowane SBOM-y są stale ponownie oceniane.

Analiza
Poprawka
Zachowane z wydaniem
Zgłaszanie: CRACI składa zgłoszenia w Państwa imieniu.

Wczesne ostrzeżenie
Powiadomienie
Raport końcowy

Cyber Resilience Act

11 września 2026 Zaczynają obowiązywać wymogi zgłaszania
11 grudnia 2027 Rozporządzenie stosuje się w pełni

Czytaj przewodnik po CRA

Zgłoszenie podatności Fragment

web-portal v2.4.0

northwind-controls/web-portal · build #1842

SBOM: CycloneDX · Complete
Build: #1842 · commit 9f3c2e1
Podatność: CVE-2025-29927 · Critical
Komponent: next 15.2.2
Zgłaszane do: CSIRT i ENISA, przez CRA Single Reporting Platform

Przebieg obsługi

2025-03-14 Wydanie zbudowane, SBOM zarejestrowany
2025-03-21 Komunikat opublikowany i dopasowany do tego wydania
2025-03-21 Przeanalizowane przez: Bezpieczeństwo produktu, przypisane do: Zespół platformy
2025-03-22 Wydano v2.4.1 z next 15.2.3

Eksport SBOM jako CycloneDX lub SPDX

Pierwszy build w 5 minut.

W tym demo przeprowadzamy stronę TanStack Start od rejestracji do pierwszego uruchomienia na CRACI. Łączymy GitHub, kierujemy zadania za pomocą runs-on: craci i obserwujemy pierwsze uruchomienie. CRACI rejestruje każdą zewnętrzną zależność pobieraną przez build, oznacza znane podatności i wskazuje dla każdej z nich zadanie, które ją wprowadziło.

Jak CRACI wpisuje się w Państwa proces dostarczania.

CRACI zastępuje runner, a nie GitHub Actions. Państwa workflow, przeglądy i kroki wdrożenia pozostają bez zmian.

Połączenie aplikacji GitHub

Dla wszystkich repozytoriów lub tylko wybranych.
Zmiana runnera

W workflow wystarczy ustawić runs-on: craci. Nic więcej się nie zmienia.
Uruchomienie kolejnego buildu

Uruchomienia nadal widać w GitHub. Zapis buildu i SBOM pojawiają się w CRACI.

Runnery: Zarządzane runnery Linux na x86-64 i ARM64, na europejskiej infrastrukturze.
Buildy: Docker Engine, Buildx i Compose v2. Buildy Yocto i BitBake są opisane w dokumentacji.
Państwa kod i dane: CRACI przetwarza kod źródłowy w trakcie buildu i go nie przechowuje. Dane buildów są hostowane w Europie. Zawartość cache zależy od tego, co zapisują Państwa workflow. Czytaj stronę o bezpieczeństwie.
W planach rozwoju: GitLab, Jenkins i inne systemy CI, runnery Windows i macOS, runnery on-prem, Maven i Java.

Uruchom pierwszy build Zobacz, jak działa CRACI

Pytania, które zespoły zadają przed demo

Kompatybilność, konfiguracja, bezpieczeństwo i przetwarzanie danych.

Jakie środowiska CI i ekosystemy pakietów są obsługiwane?

Obecnie obsługiwaną integracją CI jest GitHub Actions, a inne systemy CI są w planach rozwoju. CRACI rejestruje pakiety z rejestrów npm, PyPI, RubyGems, Cargo, Go, Nix i OCI, z repozytoriów pakietów Debian, Ubuntu i Alpine oraz pobrania z Git i innych źródeł. Maven i Java są w planach rozwoju. Runnery działają na Linuksie na x86-64 i ARM64.

Czego wymaga konfiguracja?

Łączą Państwo CRACI GitHub App ze wszystkimi lub wybranymi repozytoriami i ustawiają runs-on: craci w workflow. CRACI zastępuje runner, a nie GitHub Actions, więc uruchomienia nadal są widoczne w GitHub.

Do jakich danych CRACI ma dostęp i gdzie są przechowywane?

Aplikacja GitHub odczytuje Państwa kod i uruchomienia Actions oraz zarządza runnerami, które rejestruje dla Państwa organizacji. CRACI przetwarza kod źródłowy w trakcie buildu i go nie przechowuje. Dane buildów, w tym metadane, dane pakietów, ślady sieciowe, SBOM-y, dane o pochodzeniu, cache i zapisy audytowe, są hostowane w Europie, z niestandardowym okresem przechowywania w planie Enterprise. Zawartość cache zależy od tego, co zapisują Państwa workflow. Więcej o bezpieczeństwie i przetwarzaniu danych.

Czy CRACI blokuje, czy alarmuje? Co dzieje się z buildem, który narusza politykę?

Polityka ruchu wychodzącego jest egzekwowana na runnerze. Jest weryfikowana przed startem zadania i w razie problemu blokuje ruch (fail closed), więc połączenie spoza polityki zostaje odrzucone, a Państwo otrzymują alert. Bramki polityk mogą też zatrzymać build w czasie rzeczywistym.

W jakich formatach mogę eksportować?

SBOM-y eksportuje się w formacie CycloneDX lub SPDX, łącznie z zależnościami przechodnimi, podatnościami i deklarowanymi licencjami.

Co jest dostępne dziś, a co jest w planach rozwoju?

Dostępne dziś: zarządzane runnery Linux dla GitHub Actions, SBOM-y z czasu buildu z podatnościami, polityka ruchu wychodzącego, ciągłe monitorowanie podatności z analizą oraz bramki polityk. W planach rozwoju: GitLab, Jenkins i inne systemy CI, runnery Windows i macOS oraz runnery on-prem.

Wspierają nas