CRACI i JFrog Artifactory

Dwa punkty obserwacji tego samego łańcucha dostaw

Wiele organizacji inżynierskich kieruje ruch pakietów przez JFrog Artifactory. Repozytorium zdalne działa jako buforujące proxy dla rejestru publicznego, takiego jak npm lub PyPI, pobierając pakiety na żądanie i zachowując kopię. Repozytoria wirtualne łączą kilka źródeł pod jednym adresem URL. Państwa własne wyniki buildów trafiają do repozytoriów lokalnych. Daje to jedno miejsce, w którym można widzieć to, co wchodzi do firmy, i tym zarządzać.

CRACI znajduje się gdzie indziej. To runner CI, na którym działają Państwa zadania GitHub Actions, a podczas działania każdego zadania rejestruje on pobierane zewnętrzne zależności. Artifactory odpowiada na pytanie, co przepłynęło przez Państwa repozytoria. CRACI odpowiada na pytanie, czego użył ten konkretny build i jaki artefakt z niego powstał.

Co Artifactory robi dobrze

Artifactory to dojrzały menedżer repozytoriów. Daje zespołom niezawodny, buforowany dostęp do pakietów z zewnątrz, miejsce na wewnętrzne artefakty i jeden punkt kontroli dla wielu typów pakietów. Platforma JFrog dodaje do tego więcej:

• Build-info. Za pomocą JFrog CLI dodają Państwo do poleceń nazwę i numer buildu oraz publikują zapis JSON z rozwiązanymi zależnościami, wytworzonymi artefaktami, zmiennymi środowiskowymi i szczegółami Git. Ten zapis wspiera śledzenie, promocję buildów i skanowanie Xray.
• Xray. Skanuje artefakty i buildy pod kątem podatności oraz eksportuje SBOM-y w formatach SPDX i CycloneDX. Macierz licencji JFrog wymienia Xray jako element subskrypcji Pro X, Enterprise X i Enterprise+ (stan na wrzesień 2026).
• Curation. Blokuje złośliwe lub podatne pakiety w repozytorium zdalnym, zanim dotrą do programistów, łącznie z pakietami znajdującymi się już w zdalnym cache.

Blokowanie na poziomie pakietów w rejestrze to prawdziwa zaleta. CRACI nie blokuje dziś pojedynczych pakietów; listy blokowanych pakietów dla całej organizacji są w planach rozwoju CRACI.

Co dodaje CRACI

Widoczność niezależna od trasowania

Artifactory widzi to, co przez niego przechodzi. Buildy nie zawsze współpracują. Zadanie może pobrać toolchain z wydania GitHub, zainstalować pakiety systemowe, pobrać obraz bazowy z rejestru publicznego lub uruchomić skrypt pobierający plik binarny. Własna dokumentacja JFrog zaznacza, że zależności pobierane przez inne narzędzia można rejestrować ręcznie przez build-add-dependencies, co oznacza, że ktoś musi o nich wiedzieć.

CRACI rejestruje na runnerze. Proxy rozpoznające pakiety obserwuje ruch do źródeł pakietów podczas zadania: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a także presetów pobierania. Jeśli instalacje npm lub PyPI przechodzą przez mirror Artifactory, to działa: CRACI rejestruje również te pakiety.

Dowody z każdego buildu bez dodatkowych kroków

Build-info jest wartościowe, ale trzeba je dodać do każdego pipeline'u. W CRACI zapis istnieje dla każdego zadania, ponieważ tworzy go runner. Dowody zależności przemieszczają się razem z cache CI, więc pakiet przywrócony z cache nadal jest uwzględniany. Każdy SBOM ma stan kompletności dla każdego zadania i każdego cache: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded. Gdy w zapisie jest luka, informuje o tym.

Buildy na zatwierdzonej ścieżce

Ponieważ CRACI uruchamia zadanie, mogą Państwo ustawić jego politykę ruchu wychodzącego. Polityki działają w trybie domyślnej odmowy lub domyślnego zezwolenia, z 24 wbudowanymi presetami źródeł oprogramowania, typowanymi źródłami niestandardowymi (npm, PyPI, apt, apk, proxy Go, Nix, Cargo, rejestry OCI i Git) oraz jawnymi regułami TLS, TCP, UDP i ICMP. Są walidowane przed startem zadania i w razie błędu blokują ruch. Polityka, która zezwala na host Artifactory i odmawia bezpośredniego dostępu do rejestrów publicznych, pomaga zapewnić, że buildy faktycznie korzystają z nadzorowanej trasy. CRACI powiadamia alertem, gdy zadanie naruszy swoją politykę.

Dowody z buildu obok Artifactory

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI nie podpisuje danych o pochodzeniu. Artefakt pozostaje w Artifactory tak jak dziś; zapis tego, co pobrał build, pochodzi z CRACI.

Dla zespołów objętych unijnym Cyber Resilience Act ten zapis zasila dowody na poziomie wydania. CRACI agreguje podatności z wielu buildów i repozytoriów, stale ponownie ocenia monitorowane SBOM-y i eksportuje je w formacie CycloneDX lub SPDX. Zob. dowody dla CRA i zgodność z CRA.

Inwentarz tego, co jest gdzie wdrożone

Widok inwentarza CRACI pokazuje dokładnie, które wersje oprogramowania są wdrożone w których produktach, na całym świecie. Gdy pojawia się nowa podatność, widzą Państwo, które produkty działają na podatnej wersji, zamiast składać to z informacji o wydaniach i arkuszy kalkulacyjnych.

Jak to się łączy

1. Artifactory pozostaje Państwa proxy pakietów, magazynem artefaktów i punktem dystrybucji wydań.
2. Zadania GitHub Actions przenoszą Państwo na CRACI, zmieniając runs-on na craci. Workflow pozostają takie same, a uruchomienia nadal są widoczne w interfejsie GitHub.
3. Instalacje npm i PyPI nadal kierują Państwo na mirrory Artifactory, tak jak dziś.
4. Polityka ruchu wychodzącego CRACI utrzymuje buildy na zatwierdzonych źródłach, łącznie z Artifactory.
5. SBOM, dane o pochodzeniu i ślad sieciowy CRACI z każdego buildu służą jako dowody dla każdego wydania.

Jeśli polegają dziś Państwo na JFrog build-info lub Curation, warto je zachować. CRACI obsługuje dziś tylko GitHub Actions (GitLab CI i Jenkins są w planach rozwoju), więc pipeline'y w innych systemach CI pozostają tam, gdzie są.

Jeśli zastępują Państwo samo Artifactory, proszę zobaczyć alternatywy dla JFrog Artifactory.

Częste pytania

Czy CRACI zastępuje Artifactory?

Nie. CRACI nie jest menedżerem repozytoriów. Nie przechowuje Państwa pakietów ani binariów wydań i ich nie dystrybuuje. Uruchamia Państwa buildy i rejestruje dotyczące ich dowody.

Czy CRACI pokrywa się z Xray?

Częściowo. Oba eksportują SBOM-y w formatach CycloneDX i SPDX i oba pomagają śledzić podatności. Różnica tkwi w danych wejściowych. Xray skanuje artefakty i buildy, o których wie JFrog. SBOM i widok podatności w CRACI pochodzą z tego, co każdy build pobrał podczas działania, z wielu buildów i repozytoriów. Jeśli Xray jest osadzony w Państwa procesie wydawniczym, warto go zachować, a zapis CRACI z każdego buildu traktować jako drugie, niezależne źródło.

Które typy repozytoriów Artifactory działają z CRACI?

Potwierdzono działanie mirrorów npm i PyPI w Artifactory z buildami CRACI. W przypadku innych typów pakietów prosimy o rozmowę o Państwa konfiguracji przed przeniesieniem tych pipeline'ów.